Bug#219459: NPTL breaks abort()
On Sun, Jan 25, 2004 at 02:15:25AM +0900, GOTO Masanori wrote:
> At Thu, 15 Jan 2004 23:23:53 -0500,
> Daniel Jacobowitz wrote:
> > On Fri, Jan 16, 2004 at 01:22:10PM +0900, GOTO Masanori wrote:
> > > At Thu, 6 Nov 2003 13:14:04 -0500,
> > > Daniel Jacobowitz wrote:
> > > >
> > > > On Thu, Nov 06, 2003 at 05:39:23PM +0000, Andrew Suffield wrote:
> > > > > Package: libc6
> > > > > Severity: important
> > > > >
> > > > > This may turn out to be a gdb bug, but let's start here...
> > > >
> > > > That just means GDB can't backtrace through abort. The compiler knows
> > > > that abort is a noreturn function, and is allowed to take all sorts of
> > > > liberties with the calling sequence - there's very little the debugger
> > > > can do.
> > > >
> > > > You won't be able to get a backtrace at least until GDB and your kernel
> > > > agree on how to dump the sysinfo DSO to a core dump and how to parse
> > > > it. The code's still being worked on.
> > >
> > > If so, how to handle this bug report? I think a core dump gotten
> > > throught abort() should also be enable to attach with gdb. Is this
> > > feature lack from gcc or gdb or nptl ?
> >
> > GDB and the kernel, IIRC. The most recent kernels probably do the
> > right thing. I need to recheck this and then I'll see about GDB
> > patches.
>
> Thanks! So... should this bug reassign to gdb?
I spent some time looking at this today. There are two problems.
Problem #1: GDB does not backtrace out of the vsyscall DSO correctly.
I have patches that solve this problem, part from Roland McGrath and
part cobbled together by me.
Problem #2: We do not have debug information for the TLS libc.so.6, and
GDB can not sort out the -fomit-frame-pointer prologues.
There are a number of things we could do about this. The easiest of
the bunch may be to leave unwind information in the binary by default.
Debug info is huge - for libc, about 25MB and slow to parse. But
.debug_frame is small - for libc, about 100K. We could leave it in the
-"stripped" libraries which we build using fomit-frame-pointer This
won't affect the size of udebs which only include the base libc.
Another alternative is to not use -fomit-frame-pointer.
Another alternative is to include minimal --only-keep-debug files in
libc6-dbg; I'd been resisting using --only-keep-debug because adding
the debugging information slows down GDB startup time dramatically, but
if we keep only unwind information (and not actual source-level debug
information) then it won't slow down GDB. This might be the best
option of all.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: