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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
