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
