Bug#219459: NPTL breaks abort()
On Sat, Jan 24, 2004 at 01:30:49PM -0500, Daniel Jacobowitz wrote:
> 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.
Whee! With a little help from CVS binutils, I got the third option to
work; and it works _beautifully_. Unfortunately it does not work using
the binutils from unstable. James, I -think- that the patches needed
will be confined to binutils/objcopy.c and thus not impact the
assembler/linker; if I'm right, do you think this is doable for sarge?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: