* gdb/dwarf-frame.c @ 2003-05-09 9:45 Roland McGrath 2003-05-09 13:41 ` gdb/dwarf-frame.c Daniel Jacobowitz 2003-05-09 19:36 ` gdb/dwarf-frame.c Mark Kettenis 0 siblings, 2 replies; 43+ messages in thread From: Roland McGrath @ 2003-05-09 9:45 UTC (permalink / raw) To: Mark Kettenis; +Cc: gdb (Hi Mark! It's been too long since we hacked together.) [Please note that I am not on the mailing list, so keep me CC'd directly.] I have been looking at the kettenis_i386newframe-20030419-branch gdb code. I've been told that the new dwarf-frame.c replaces the dwarf2cfi.c code that's on mainline. I don't know the guts of either or of DWARF2 itself well enough to compare them. What I have noticed is that dwarf-frame.c does not seem to handle the .eh_frame section, only the .debug_frame section. The dwarf2cfi.c code looks at both. As well as looking for the section, it needs to grok the "augmentation" values and different encodings used in .eh_frame, and I don't see any of that handled in the new code. Is this an intentional omission and if so what is the rationale? I think grokking .eh_frame sections in the absence of .debug_frame is a nice thing in general--it might give you at least some more helpful backtraces than otherwise when dealing with binaries without debugging info. But the particular reason it is of concern to me is that it's needed for unwinding PC values within the special kernel entrypoint page now being used in Linux on x86. glibc now uses this entrypoint code for every system call, and so any thread blocked in a system call (which most threads one looks at are when one starts looking) will have its PC inside this code and need to be able to unwind that frame-pointer-less leaf frame to produce a useful backtrace. This is magic kernel code for which there is never going to be debugging information, but for which we do have .eh_frame information we can get at. I am setting about attacking how we get at it in all the relevant cases, but I had been working from the assumption that upon locating some information in .eh_frame form (including "zR" augmentation and pcrel pointer encoding) it would plug easily into the DWARF2 unwinding machinery. If that's not so, it throws a monkey wrench into my plans. Thanks, Roland ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb/dwarf-frame.c 2003-05-09 9:45 gdb/dwarf-frame.c Roland McGrath @ 2003-05-09 13:41 ` Daniel Jacobowitz 2003-05-09 14:10 ` gdb/dwarf-frame.c Elena Zannoni 2003-05-09 20:32 ` gdb/dwarf-frame.c Roland McGrath 2003-05-09 19:36 ` gdb/dwarf-frame.c Mark Kettenis 1 sibling, 2 replies; 43+ messages in thread From: Daniel Jacobowitz @ 2003-05-09 13:41 UTC (permalink / raw) To: Roland McGrath; +Cc: Mark Kettenis, gdb On Fri, May 09, 2003 at 02:45:29AM -0700, Roland McGrath wrote: > (Hi Mark! It's been too long since we hacked together.) > [Please note that I am not on the mailing list, so keep me CC'd directly.] > > I have been looking at the kettenis_i386newframe-20030419-branch gdb code. > I've been told that the new dwarf-frame.c replaces the dwarf2cfi.c code > that's on mainline. I don't know the guts of either or of DWARF2 itself > well enough to compare them. > > What I have noticed is that dwarf-frame.c does not seem to handle the > .eh_frame section, only the .debug_frame section. The dwarf2cfi.c code > looks at both. As well as looking for the section, it needs to grok the > "augmentation" values and different encodings used in .eh_frame, and I > don't see any of that handled in the new code. Is this an intentional > omission and if so what is the rationale? My understanding from Mark's earlier post is that it is an intentional but probably temporary omission - since dwarf-frame is only a week or two old at this point. > I think grokking .eh_frame sections in the absence of .debug_frame is a > nice thing in general--it might give you at least some more helpful > backtraces than otherwise when dealing with binaries without debugging > info. But the particular reason it is of concern to me is that it's needed > for unwinding PC values within the special kernel entrypoint page now being > used in Linux on x86. glibc now uses this entrypoint code for every system > call, and so any thread blocked in a system call (which most threads one > looks at are when one starts looking) will have its PC inside this code and > need to be able to unwind that frame-pointer-less leaf frame to produce a > useful backtrace. This is magic kernel code for which there is never going > to be debugging information, but for which we do have .eh_frame information > we can get at. I am setting about attacking how we get at it in all the > relevant cases, but I had been working from the assumption that upon > locating some information in .eh_frame form (including "zR" augmentation > and pcrel pointer encoding) it would plug easily into the DWARF2 unwinding > machinery. If that's not so, it throws a monkey wrench into my plans. Should any work even be necessary? My understanding was that the kernel code would show up in the shared library list. Oh, I guess it is - we usually locate .eh_frame via BFD, which means section headers and an on-disk file. I see. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb/dwarf-frame.c 2003-05-09 13:41 ` gdb/dwarf-frame.c Daniel Jacobowitz @ 2003-05-09 14:10 ` Elena Zannoni 2003-05-09 14:56 ` NPTL thread support H. J. Lu 2003-05-09 17:01 ` gdb/dwarf-frame.c Andrew Cagney 2003-05-09 20:32 ` gdb/dwarf-frame.c Roland McGrath 1 sibling, 2 replies; 43+ messages in thread From: Elena Zannoni @ 2003-05-09 14:10 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Roland McGrath, Mark Kettenis, gdb Daniel Jacobowitz writes: > On Fri, May 09, 2003 at 02:45:29AM -0700, Roland McGrath wrote: > > (Hi Mark! It's been too long since we hacked together.) > > [Please note that I am not on the mailing list, so keep me CC'd directly.] > > > > I have been looking at the kettenis_i386newframe-20030419-branch gdb code. > > I've been told that the new dwarf-frame.c replaces the dwarf2cfi.c code > > that's on mainline. I don't know the guts of either or of DWARF2 itself > > well enough to compare them. > > > > What I have noticed is that dwarf-frame.c does not seem to handle the > > .eh_frame section, only the .debug_frame section. The dwarf2cfi.c code > > looks at both. As well as looking for the section, it needs to grok the > > "augmentation" values and different encodings used in .eh_frame, and I > > don't see any of that handled in the new code. Is this an intentional > > omission and if so what is the rationale? > > My understanding from Mark's earlier post is that it is an intentional > but probably temporary omission - since dwarf-frame is only a week or > two old at this point. > > > I think grokking .eh_frame sections in the absence of .debug_frame is a > > nice thing in general--it might give you at least some more helpful > > backtraces than otherwise when dealing with binaries without debugging > > info. But the particular reason it is of concern to me is that it's needed > > for unwinding PC values within the special kernel entrypoint page now being > > used in Linux on x86. glibc now uses this entrypoint code for every system > > call, and so any thread blocked in a system call (which most threads one > > looks at are when one starts looking) will have its PC inside this code and > > need to be able to unwind that frame-pointer-less leaf frame to produce a > > useful backtrace. This is magic kernel code for which there is never going > > to be debugging information, but for which we do have .eh_frame information > > we can get at. I am setting about attacking how we get at it in all the > > relevant cases, but I had been working from the assumption that upon > > locating some information in .eh_frame form (including "zR" augmentation > > and pcrel pointer encoding) it would plug easily into the DWARF2 unwinding > > machinery. If that's not so, it throws a monkey wrench into my plans. > > Should any work even be necessary? My understanding was that the > kernel code would show up in the shared library list. Oh, I guess it > is - we usually locate .eh_frame via BFD, which means section headers > and an on-disk file. I see. > Which reminds me that we should probably have the NPTL thread support patches integrated in gdb as well, since we are at this (and I have your attention). Can somebody (Daniel, Mark?) take a look at the patches? I can guarentee that they work, since they were shipped with RHL9's gdb. elena > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 43+ messages in thread
* NPTL thread support 2003-05-09 14:10 ` gdb/dwarf-frame.c Elena Zannoni @ 2003-05-09 14:56 ` H. J. Lu 2003-05-09 15:44 ` Elena Zannoni 2003-05-09 17:01 ` gdb/dwarf-frame.c Andrew Cagney 1 sibling, 1 reply; 43+ messages in thread From: H. J. Lu @ 2003-05-09 14:56 UTC (permalink / raw) To: Elena Zannoni; +Cc: Daniel Jacobowitz, Roland McGrath, Mark Kettenis, gdb On Fri, May 09, 2003 at 10:15:05AM -0400, Elena Zannoni wrote: > > Which reminds me that we should probably have the NPTL thread support > patches integrated in gdb as well, since we are at this (and I have > your attention). Can somebody (Daniel, Mark?) take a look at the > patches? I can guarentee that they work, since they were shipped with > RHL9's gdb. > Yes, please. I have to use gdb from cvs since the one RedHat 9 doesn't work too well for me. But I lose the NPTL support. H.J. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: NPTL thread support 2003-05-09 14:56 ` NPTL thread support H. J. Lu @ 2003-05-09 15:44 ` Elena Zannoni [not found] ` <20030509091522.A2960@lucon.org> 0 siblings, 1 reply; 43+ messages in thread From: Elena Zannoni @ 2003-05-09 15:44 UTC (permalink / raw) To: H. J. Lu Cc: Elena Zannoni, Daniel Jacobowitz, Roland McGrath, Mark Kettenis, gdb H. J. Lu writes: > On Fri, May 09, 2003 at 10:15:05AM -0400, Elena Zannoni wrote: > > > > Which reminds me that we should probably have the NPTL thread support > > patches integrated in gdb as well, since we are at this (and I have > > your attention). Can somebody (Daniel, Mark?) take a look at the > > patches? I can guarentee that they work, since they were shipped with > > RHL9's gdb. > > > > Yes, please. I have to use gdb from cvs since the one RedHat 9 doesn't > work too well for me. But I lose the NPTL support. > > > H.J. yes, catch 22. RHL9's gdb is based from a snapshot of November 2002, it doesn't have a lot of the new fixes. elena ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <20030509091522.A2960@lucon.org>]
[parent not found: <16059.55278.841645.134311@localhost.redhat.com>]
* Re: NPTL thread support [not found] ` <16059.55278.841645.134311@localhost.redhat.com> @ 2003-05-11 20:46 ` H. J. Lu 2003-05-12 19:24 ` J. Johnston 0 siblings, 1 reply; 43+ messages in thread From: H. J. Lu @ 2003-05-11 20:46 UTC (permalink / raw) To: Elena Zannoni; +Cc: GDB On Fri, May 09, 2003 at 12:31:42PM -0400, Elena Zannoni wrote: > > All the patches have been posted by Jeff Johnston to the gdb-patches list. > I think in the last 2 months or so. They should still apply cleanly. > > If you try them, could you post to the list how it went? > > elena > I tried those patches. Gdb compiled ok. But "make check" never finished under RedHat 9. I got FAIL: gdb.asm/asm-source.exp: x/i globalvar (memory read error) FAIL: gdb.base/selftest.exp: step into xmalloc call FAIL: gdb.java/jmisc.exp: setting breakpoint at jmisc.main FAIL: gdb.java/jmisc.exp: ptype jmisc FAIL: gdb.java/jmisc.exp: p args FAIL: gdb.java/jmisc.exp: p *args FAIL: gdb.java/jmisc1.exp: ptype jmisc FAIL: gdb.java/jmisc2.exp: ptype jmisc FAIL: gdb.mi/mi-var-display.exp: get children local variable weird FAIL: gdb.mi/mi1-var-display.exp: get children local variable weird FAIL: gdb.objc/basicclass.exp: breakpoint method FAIL: gdb.objc/basicclass.exp: breakpoint method with colon FAIL: gdb.objc/basicclass.exp: breakpoint class method with colon FAIL: gdb.objc/basicclass.exp: continue until method breakpoint FAIL: gdb.objc/basicclass.exp: resetting breakpoints when rerunning FAIL: gdb.objc/basicclass.exp: continue until method breakpoint FAIL: gdb.objc/basicclass.exp: print an ivar of self FAIL: gdb.objc/basicclass.exp: print self FAIL: gdb.objc/basicclass.exp: print contents of self FAIL: gdb.objc/basicclass.exp: breakpoint in category method FAIL: gdb.objc/basicclass.exp: continue until category method FAIL: gdb.objc/basicclass.exp: Call an Objective-C method with no arguments FAIL: gdb.objc/basicclass.exp: Call an Objective-C method with one argument FAIL: gdb.objc/basicclass.exp: Use of the print-object command FAIL: gdb.objc/basicclass.exp: Use of the po (print-object) command FAIL: gdb.threads/gcore-thread.exp: thread 2 is running (timeout) FAIL: gdb.threads/gcore-thread.exp: save a corefile (timeout) FAIL: gdb.threads/gcore-thread.exp: re-load generated corefile (file not found) FAIL: gdb.threads/killed.exp: GDB exits after multi-threaded program exits messily (timeout) FAIL: gdb.threads/linux-dp.exp: (timeout) create philosopher: 1 FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: about to create philosopher: 2 (timeout) FAIL: gdb.threads/linux-dp.exp: (timeout) create philosopher: 2 FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: about to create philosopher: 3 (timeout) FAIL: gdb.threads/linux-dp.exp: (timeout) create philosopher: 3 FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: about to create philosopher: 4 (timeout) FAIL: gdb.threads/linux-dp.exp: (timeout) create philosopher: 4 FAIL: gdb.threads/linux-dp.exp: list linux-dp.c:1,1 (timeout) FAIL: gdb.threads/linux-dp.exp: find line number containing "linuxthreads.exp: info threads 2" (timeout) FAIL: gdb.threads/linux-dp.exp: setting breakpoint at -1 (timeout) FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: main thread's sleep (timeout) FAIL: gdb.threads/linux-dp.exp: info threads 2 (timeout) FAIL: gdb.threads/linux-dp.exp: setting breakpoint at print_philosopher thread 5 (timeout) FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print (timeout) FAIL: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit (timeout) FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print, pass: 0 (timeout) FAIL: gdb.threads/linux-dp.exp: thread-specific breakpoint is thread-specific (timeout) FAIL: gdb.threads/linux-dp.exp: selected thread: 1 (timeout) FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 1 (timeout) FAIL: gdb.threads/linux-dp.exp: selected thread: 2 (timeout) FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 2 (timeout) FAIL: gdb.threads/linux-dp.exp: selected thread: 3 (timeout) FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 3 (timeout) FAIL: gdb.threads/linux-dp.exp: selected thread: 4 (timeout) FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 4 (timeout) FAIL: gdb.threads/linux-dp.exp: selected thread: 5 (timeout) FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 5 (timeout) FAIL: gdb.threads/linux-dp.exp: selected thread: 6 (timeout) FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 6 (timeout) FAIL: gdb.threads/linux-dp.exp: found an interesting thread FAIL: gdb.threads/print-threads.exp: Running threads (slow) (timeout) FAIL: gdb.threads/print-threads.exp: Running threads (slow with kill breakpoint) (timeout) FAIL: gdb.threads/pthreads.exp: Continue to creation of second thread (timeout) FAIL: gdb.threads/pthreads.exp: set var common_routine::hits=0 (timeout) FAIL: gdb.threads/pthreads.exp: set var common_routine::from_thread1=0 (timeout) FAIL: gdb.threads/pthreads.exp: set var common_routine::from_thread2=0 (timeout) FAIL: gdb.threads/pthreads.exp: set var common_routine::from_main=0 (timeout) FAIL: gdb.threads/pthreads.exp: set var common_routine::full_coverage=0 (timeout) FAIL: gdb.threads/pthreads.exp: disable (timeout) FAIL: gdb.threads/pthreads.exp: tbreak common_routine if hits >= 15 (timeout) FAIL: gdb.threads/pthreads.exp: continue until common routine run 15 times and the lat 2 lines in gdb.log are FAIL: gdb.threads/pthreads.exp: continue until common routine run 15 times PASS: gdb.threads/pthreads.exp: Continue with all threads running H.J. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: NPTL thread support 2003-05-11 20:46 ` H. J. Lu @ 2003-05-12 19:24 ` J. Johnston 2003-05-12 20:08 ` H. J. Lu 0 siblings, 1 reply; 43+ messages in thread From: J. Johnston @ 2003-05-12 19:24 UTC (permalink / raw) To: H. J. Lu; +Cc: Elena Zannoni, GDB H.J., Can you confirm that configuration set HAVE_TKILL_SYSCALL to 1 in config.h? Can you also confirm that the value: tkill_failed in lin-lwp.c is not set to true when running the debugger? -- Jeff J. H. J. Lu wrote: > On Fri, May 09, 2003 at 12:31:42PM -0400, Elena Zannoni wrote: > >>All the patches have been posted by Jeff Johnston to the gdb-patches list. >>I think in the last 2 months or so. They should still apply cleanly. >> >>If you try them, could you post to the list how it went? >> >>elena >> > > > I tried those patches. Gdb compiled ok. But "make check" never finished > under RedHat 9. I got > > FAIL: gdb.asm/asm-source.exp: x/i globalvar (memory read error) > FAIL: gdb.base/selftest.exp: step into xmalloc call > FAIL: gdb.java/jmisc.exp: setting breakpoint at jmisc.main > FAIL: gdb.java/jmisc.exp: ptype jmisc > FAIL: gdb.java/jmisc.exp: p args > FAIL: gdb.java/jmisc.exp: p *args > FAIL: gdb.java/jmisc1.exp: ptype jmisc > FAIL: gdb.java/jmisc2.exp: ptype jmisc > FAIL: gdb.mi/mi-var-display.exp: get children local variable weird > FAIL: gdb.mi/mi1-var-display.exp: get children local variable weird > FAIL: gdb.objc/basicclass.exp: breakpoint method > FAIL: gdb.objc/basicclass.exp: breakpoint method with colon > FAIL: gdb.objc/basicclass.exp: breakpoint class method with colon > FAIL: gdb.objc/basicclass.exp: continue until method breakpoint > FAIL: gdb.objc/basicclass.exp: resetting breakpoints when rerunning > FAIL: gdb.objc/basicclass.exp: continue until method breakpoint > FAIL: gdb.objc/basicclass.exp: print an ivar of self > FAIL: gdb.objc/basicclass.exp: print self > FAIL: gdb.objc/basicclass.exp: print contents of self > FAIL: gdb.objc/basicclass.exp: breakpoint in category method > FAIL: gdb.objc/basicclass.exp: continue until category method > FAIL: gdb.objc/basicclass.exp: Call an Objective-C method with no arguments > FAIL: gdb.objc/basicclass.exp: Call an Objective-C method with one argument > FAIL: gdb.objc/basicclass.exp: Use of the print-object command > FAIL: gdb.objc/basicclass.exp: Use of the po (print-object) command > FAIL: gdb.threads/gcore-thread.exp: thread 2 is running (timeout) > FAIL: gdb.threads/gcore-thread.exp: save a corefile (timeout) > FAIL: gdb.threads/gcore-thread.exp: re-load generated corefile (file not found) > FAIL: gdb.threads/killed.exp: GDB exits after multi-threaded program exits messily (timeout) > FAIL: gdb.threads/linux-dp.exp: (timeout) create philosopher: 1 > FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: about to create philosopher: 2 (timeout) > FAIL: gdb.threads/linux-dp.exp: (timeout) create philosopher: 2 > FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: about to create philosopher: 3 (timeout) > FAIL: gdb.threads/linux-dp.exp: (timeout) create philosopher: 3 > FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: about to create philosopher: 4 (timeout) > FAIL: gdb.threads/linux-dp.exp: (timeout) create philosopher: 4 > FAIL: gdb.threads/linux-dp.exp: list linux-dp.c:1,1 (timeout) > FAIL: gdb.threads/linux-dp.exp: find line number containing "linuxthreads.exp: info threads 2" (timeout) > FAIL: gdb.threads/linux-dp.exp: setting breakpoint at -1 (timeout) > FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: main thread's sleep (timeout) > FAIL: gdb.threads/linux-dp.exp: info threads 2 (timeout) > FAIL: gdb.threads/linux-dp.exp: setting breakpoint at print_philosopher thread 5 (timeout) > FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print (timeout) > FAIL: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit (timeout) > FAIL: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print, pass: 0 (timeout) > FAIL: gdb.threads/linux-dp.exp: thread-specific breakpoint is thread-specific (timeout) > FAIL: gdb.threads/linux-dp.exp: selected thread: 1 (timeout) > FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 1 (timeout) > FAIL: gdb.threads/linux-dp.exp: selected thread: 2 (timeout) > FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 2 (timeout) > FAIL: gdb.threads/linux-dp.exp: selected thread: 3 (timeout) > FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 3 (timeout) > FAIL: gdb.threads/linux-dp.exp: selected thread: 4 (timeout) > FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 4 (timeout) > FAIL: gdb.threads/linux-dp.exp: selected thread: 5 (timeout) > FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 5 (timeout) > FAIL: gdb.threads/linux-dp.exp: selected thread: 6 (timeout) > FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 6 (timeout) > FAIL: gdb.threads/linux-dp.exp: found an interesting thread > FAIL: gdb.threads/print-threads.exp: Running threads (slow) (timeout) > FAIL: gdb.threads/print-threads.exp: Running threads (slow with kill breakpoint) (timeout) > FAIL: gdb.threads/pthreads.exp: Continue to creation of second thread (timeout) > FAIL: gdb.threads/pthreads.exp: set var common_routine::hits=0 (timeout) > FAIL: gdb.threads/pthreads.exp: set var common_routine::from_thread1=0 (timeout) > FAIL: gdb.threads/pthreads.exp: set var common_routine::from_thread2=0 (timeout) > FAIL: gdb.threads/pthreads.exp: set var common_routine::from_main=0 (timeout) > FAIL: gdb.threads/pthreads.exp: set var common_routine::full_coverage=0 (timeout) > FAIL: gdb.threads/pthreads.exp: disable (timeout) > FAIL: gdb.threads/pthreads.exp: tbreak common_routine if hits >= 15 (timeout) > FAIL: gdb.threads/pthreads.exp: continue until common routine run 15 times > > and the lat 2 lines in gdb.log are > > FAIL: gdb.threads/pthreads.exp: continue until common routine run 15 times > PASS: gdb.threads/pthreads.exp: Continue with all threads running > > > > H.J. > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: NPTL thread support 2003-05-12 19:24 ` J. Johnston @ 2003-05-12 20:08 ` H. J. Lu 2003-05-12 20:15 ` David Carlton 2003-05-12 20:17 ` Elena Zannoni 0 siblings, 2 replies; 43+ messages in thread From: H. J. Lu @ 2003-05-12 20:08 UTC (permalink / raw) To: J. Johnston; +Cc: Elena Zannoni, GDB On Mon, May 12, 2003 at 03:20:13PM -0400, J. Johnston wrote: > H.J., > > Can you confirm that configuration set HAVE_TKILL_SYSCALL to 1 > in config.h? Can you also confirm that the value: tkill_failed in > lin-lwp.c is not set to true when running the debugger? > It was a pilot error. The "make check" hang is gone. Here are the failures in today's cvs on RedHat 9. H.J. ---- FAIL: gdb.asm/asm-source.exp: x/i globalvar (memory read error) FAIL: gdb.base/selftest.exp: step into xmalloc call FAIL: gdb.java/jmisc.exp: setting breakpoint at jmisc.main FAIL: gdb.java/jmisc.exp: ptype jmisc FAIL: gdb.java/jmisc.exp: p args FAIL: gdb.java/jmisc.exp: p *args FAIL: gdb.java/jmisc1.exp: ptype jmisc FAIL: gdb.java/jmisc2.exp: ptype jmisc FAIL: gdb.mi/mi-var-display.exp: get children local variable weird FAIL: gdb.mi/mi1-var-display.exp: get children local variable weird FAIL: gdb.objc/basicclass.exp: breakpoint method FAIL: gdb.objc/basicclass.exp: breakpoint method with colon FAIL: gdb.objc/basicclass.exp: breakpoint class method with colon FAIL: gdb.objc/basicclass.exp: continue until method breakpoint FAIL: gdb.objc/basicclass.exp: resetting breakpoints when rerunning FAIL: gdb.objc/basicclass.exp: continue until method breakpoint FAIL: gdb.objc/basicclass.exp: print an ivar of self FAIL: gdb.objc/basicclass.exp: print self FAIL: gdb.objc/basicclass.exp: print contents of self FAIL: gdb.objc/basicclass.exp: breakpoint in category method FAIL: gdb.objc/basicclass.exp: continue until category method FAIL: gdb.objc/basicclass.exp: Call an Objective-C method with no arguments FAIL: gdb.objc/basicclass.exp: Call an Objective-C method with one argument FAIL: gdb.objc/basicclass.exp: Use of the print-object command FAIL: gdb.objc/basicclass.exp: Use of the po (print-object) command FAIL: gdb.threads/killed.exp: GDB exits after multi-threaded program exits messily (timeout) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: NPTL thread support 2003-05-12 20:08 ` H. J. Lu @ 2003-05-12 20:15 ` David Carlton 2003-05-12 21:09 ` Andrew Cagney 2003-05-12 20:17 ` Elena Zannoni 1 sibling, 1 reply; 43+ messages in thread From: David Carlton @ 2003-05-12 20:15 UTC (permalink / raw) To: H. J. Lu; +Cc: J. Johnston, Elena Zannoni, GDB On Mon, 12 May 2003 13:08:39 -0700, "H. J. Lu" <hjl@lucon.org> said: > It was a pilot error. The "make check" hang is gone. Here are the > failures in today's cvs on RedHat 9. > FAIL: gdb.asm/asm-source.exp: x/i globalvar (memory read error) > FAIL: gdb.base/selftest.exp: step into xmalloc call > FAIL: gdb.java/jmisc.exp: setting breakpoint at jmisc.main > FAIL: gdb.java/jmisc.exp: ptype jmisc > FAIL: gdb.java/jmisc.exp: p args > FAIL: gdb.java/jmisc.exp: p *args > FAIL: gdb.java/jmisc1.exp: ptype jmisc > FAIL: gdb.java/jmisc2.exp: ptype jmisc > FAIL: gdb.mi/mi-var-display.exp: get children local variable weird > FAIL: gdb.mi/mi1-var-display.exp: get children local variable weird These are all normal. (I can't speak about the gdb.objc ones.) David Carlton carlton@math.stanford.edu ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: NPTL thread support 2003-05-12 20:15 ` David Carlton @ 2003-05-12 21:09 ` Andrew Cagney 2003-05-12 21:18 ` David Carlton 0 siblings, 1 reply; 43+ messages in thread From: Andrew Cagney @ 2003-05-12 21:09 UTC (permalink / raw) To: David Carlton; +Cc: H. J. Lu, J. Johnston, Elena Zannoni, GDB > On Mon, 12 May 2003 13:08:39 -0700, "H. J. Lu" <hjl@lucon.org> said: > > >> It was a pilot error. The "make check" hang is gone. Here are the >> failures in today's cvs on RedHat 9. > > >> FAIL: gdb.asm/asm-source.exp: x/i globalvar (memory read error) >> FAIL: gdb.base/selftest.exp: step into xmalloc call >> FAIL: gdb.java/jmisc.exp: setting breakpoint at jmisc.main >> FAIL: gdb.java/jmisc.exp: ptype jmisc >> FAIL: gdb.java/jmisc.exp: p args >> FAIL: gdb.java/jmisc.exp: p *args >> FAIL: gdb.java/jmisc1.exp: ptype jmisc >> FAIL: gdb.java/jmisc2.exp: ptype jmisc >> FAIL: gdb.mi/mi-var-display.exp: get children local variable weird >> FAIL: gdb.mi/mi1-var-display.exp: get children local variable weird > > > These are all normal. (I can't speak about the gdb.objc ones.) Unless you've got ObjC installed, those are normal as well (it should probably be tweaked too, like threads, just fail when the compiler dies). Andrew ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: NPTL thread support 2003-05-12 21:09 ` Andrew Cagney @ 2003-05-12 21:18 ` David Carlton 2003-05-12 21:23 ` Daniel Jacobowitz 0 siblings, 1 reply; 43+ messages in thread From: David Carlton @ 2003-05-12 21:18 UTC (permalink / raw) To: Andrew Cagney; +Cc: H. J. Lu, J. Johnston, Elena Zannoni, GDB On Mon, 12 May 2003 17:09:32 -0400, Andrew Cagney <ac131313@redhat.com> said: >> These are all normal. (I can't speak about the gdb.objc ones.) > Unless you've got ObjC installed, those are normal as well (it > should probably be tweaked too, like threads, just fail when the > compiler dies). Whoops, you're right: I thought I was seeing different messages, but I was seeing those FAILs as well. I agree that the current failure mode for gdb.objc is suboptimal. Though calling gdb_suppress_entire_file sounds reasonable to me; is there no way to fix it to actually end the file instead of trying and failing to suppress the tests in the file? David Carlton carlton@math.stanford.edu ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: NPTL thread support 2003-05-12 21:18 ` David Carlton @ 2003-05-12 21:23 ` Daniel Jacobowitz 0 siblings, 0 replies; 43+ messages in thread From: Daniel Jacobowitz @ 2003-05-12 21:23 UTC (permalink / raw) To: David Carlton; +Cc: Andrew Cagney, H. J. Lu, J. Johnston, Elena Zannoni, GDB On Mon, May 12, 2003 at 02:18:30PM -0700, David Carlton wrote: > On Mon, 12 May 2003 17:09:32 -0400, Andrew Cagney <ac131313@redhat.com> said: > > >> These are all normal. (I can't speak about the gdb.objc ones.) > > > Unless you've got ObjC installed, those are normal as well (it > > should probably be tweaked too, like threads, just fail when the > > compiler dies). > > Whoops, you're right: I thought I was seeing different messages, but I > was seeing those FAILs as well. I agree that the current failure mode > for gdb.objc is suboptimal. Though calling gdb_suppress_entire_file > sounds reasonable to me; is there no way to fix it to actually end the > file instead of trying and failing to suppress the tests in the file? Just say "return 0"? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: NPTL thread support 2003-05-12 20:08 ` H. J. Lu 2003-05-12 20:15 ` David Carlton @ 2003-05-12 20:17 ` Elena Zannoni 1 sibling, 0 replies; 43+ messages in thread From: Elena Zannoni @ 2003-05-12 20:17 UTC (permalink / raw) To: H. J. Lu; +Cc: J. Johnston, Elena Zannoni, GDB H. J. Lu writes: > On Mon, May 12, 2003 at 03:20:13PM -0400, J. Johnston wrote: > > H.J., > > > > Can you confirm that configuration set HAVE_TKILL_SYSCALL to 1 > > in config.h? Can you also confirm that the value: tkill_failed in > > lin-lwp.c is not set to true when running the debugger? > > > > It was a pilot error. The "make check" hang is gone. Here are the > failures in today's cvs on RedHat 9. thanks, that's more reasonable. (I still have a rewrite of the TLS tests to resubmit...) elena > > H.J. > ---- > FAIL: gdb.asm/asm-source.exp: x/i globalvar (memory read error) > FAIL: gdb.base/selftest.exp: step into xmalloc call > FAIL: gdb.java/jmisc.exp: setting breakpoint at jmisc.main > FAIL: gdb.java/jmisc.exp: ptype jmisc > FAIL: gdb.java/jmisc.exp: p args > FAIL: gdb.java/jmisc.exp: p *args > FAIL: gdb.java/jmisc1.exp: ptype jmisc > FAIL: gdb.java/jmisc2.exp: ptype jmisc > FAIL: gdb.mi/mi-var-display.exp: get children local variable weird > FAIL: gdb.mi/mi1-var-display.exp: get children local variable weird > FAIL: gdb.objc/basicclass.exp: breakpoint method > FAIL: gdb.objc/basicclass.exp: breakpoint method with colon > FAIL: gdb.objc/basicclass.exp: breakpoint class method with colon > FAIL: gdb.objc/basicclass.exp: continue until method breakpoint > FAIL: gdb.objc/basicclass.exp: resetting breakpoints when rerunning > FAIL: gdb.objc/basicclass.exp: continue until method breakpoint > FAIL: gdb.objc/basicclass.exp: print an ivar of self > FAIL: gdb.objc/basicclass.exp: print self > FAIL: gdb.objc/basicclass.exp: print contents of self > FAIL: gdb.objc/basicclass.exp: breakpoint in category method > FAIL: gdb.objc/basicclass.exp: continue until category method > FAIL: gdb.objc/basicclass.exp: Call an Objective-C method with no arguments > FAIL: gdb.objc/basicclass.exp: Call an Objective-C method with one argument > FAIL: gdb.objc/basicclass.exp: Use of the print-object command > FAIL: gdb.objc/basicclass.exp: Use of the po (print-object) command > FAIL: gdb.threads/killed.exp: GDB exits after multi-threaded program exits messily (timeout) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb/dwarf-frame.c 2003-05-09 14:10 ` gdb/dwarf-frame.c Elena Zannoni 2003-05-09 14:56 ` NPTL thread support H. J. Lu @ 2003-05-09 17:01 ` Andrew Cagney 2003-05-09 17:08 ` gdb/dwarf-frame.c Elena Zannoni 2003-05-09 19:43 ` gdb/dwarf-frame.c Mark Kettenis 1 sibling, 2 replies; 43+ messages in thread From: Andrew Cagney @ 2003-05-09 17:01 UTC (permalink / raw) To: Elena Zannoni, Michael Snyder Cc: Daniel Jacobowitz, Roland McGrath, Mark Kettenis, gdb > Which reminds me that we should probably have the NPTL thread support > patches integrated in gdb as well, since we are at this (and I have > your attention). Can somebody (Daniel, Mark?) take a look at the > patches? I can guarentee that they work, since they were shipped with > RHL9's gdb. Just FYI, Michael or Mark. I don't think Mark is exactly comfortable with the Linux thread stuff so ... Michael? Daniel's ``thumbs up'' would be very helpful though. Andrew ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb/dwarf-frame.c 2003-05-09 17:01 ` gdb/dwarf-frame.c Andrew Cagney @ 2003-05-09 17:08 ` Elena Zannoni 2003-05-09 19:43 ` gdb/dwarf-frame.c Mark Kettenis 1 sibling, 0 replies; 43+ messages in thread From: Elena Zannoni @ 2003-05-09 17:08 UTC (permalink / raw) To: Andrew Cagney Cc: Elena Zannoni, Michael Snyder, Daniel Jacobowitz, Roland McGrath, Mark Kettenis, gdb Andrew Cagney writes: > > > Which reminds me that we should probably have the NPTL thread support > > patches integrated in gdb as well, since we are at this (and I have > > your attention). Can somebody (Daniel, Mark?) take a look at the > > patches? I can guarentee that they work, since they were shipped with > > RHL9's gdb. > > Just FYI, Michael or Mark. I don't think Mark is exactly comfortable > with the Linux thread stuff so ... > > Michael? > > Daniel's ``thumbs up'' would be very helpful though. > And HJ's. elena > Andrew > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb/dwarf-frame.c 2003-05-09 17:01 ` gdb/dwarf-frame.c Andrew Cagney 2003-05-09 17:08 ` gdb/dwarf-frame.c Elena Zannoni @ 2003-05-09 19:43 ` Mark Kettenis 2003-05-09 21:19 ` gdb/dwarf-frame.c Roland McGrath 2003-05-09 22:28 ` gdb/dwarf-frame.c Andrew Cagney 1 sibling, 2 replies; 43+ messages in thread From: Mark Kettenis @ 2003-05-09 19:43 UTC (permalink / raw) To: ac131313; +Cc: ezannoni, msnyder, drow, roland, gdb Date: Fri, 09 May 2003 13:00:54 -0400 From: Andrew Cagney <ac131313@redhat.com> > Which reminds me that we should probably have the NPTL thread support > patches integrated in gdb as well, since we are at this (and I have > your attention). Can somebody (Daniel, Mark?) take a look at the > patches? I can guarentee that they work, since they were shipped with > RHL9's gdb. Just FYI, Michael or Mark. I don't think Mark is exactly comfortable with the Linux thread stuff so ... Yes indeed. I mostly use FreeBSD instead of Linux nowadays, so I haven't tracked what's been happening on the Linux thread front too closely. I get the feeling though that trying to support both the old and the new threading model in the same code isn't a good idea :-(. Mark ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb/dwarf-frame.c 2003-05-09 19:43 ` gdb/dwarf-frame.c Mark Kettenis @ 2003-05-09 21:19 ` Roland McGrath 2003-05-09 21:48 ` gdb/dwarf-frame.c Elena Zannoni ` (2 more replies) 2003-05-09 22:28 ` gdb/dwarf-frame.c Andrew Cagney 1 sibling, 3 replies; 43+ messages in thread From: Roland McGrath @ 2003-05-09 21:19 UTC (permalink / raw) To: Mark Kettenis; +Cc: gdb [I trimmed the CC because I think everyone else is on the mailing list.] > Yes indeed. I mostly use FreeBSD instead of Linux nowadays, so I > haven't tracked what's been happening on the Linux thread front too > closely. I get the feeling though that trying to support both the old > and the new threading model in the same code isn't a good idea :-(. Can you be specific in your criticism? The rigamarole to get sibling threads stopped and started is a bit unsightly, but not too horrible I didn't think. I think trying to have separate backend implementations for linuxthreads and nptl and switching among them (whether two target modules or one with internal state flags) would be worse than any moderate amount of kludgery in the one backend. The situation in lin-lwp.c can be much cleaner if Dan and I ever implement the enhancements to ptrace in Linux 2.5 that we have discussed in detail privately in the past. That would let thread tracing at the kernel level work in a sane fashion with either kind of threads on a new kernel, and make it easy to detect an old kernel lacking the new ptrace features and fall back to the existing code that only supports linuxthreads. We can probably be spurred to do this, though it has heretofore fallen off the end of our queues of wonderful things that ought to be done real soon now. That doesn't help debugging NPTL on extant 2.5 kernels or on modified 2.4 kernels that support NPTL like those in RHL9. But personally I am ok with such support not going into mainline gdb if cleaner support for newer kernels is there. (However I don't speak for my RH colleagues who will have to maintain private patches as necessary.) Thanks, Roland ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb/dwarf-frame.c 2003-05-09 21:19 ` gdb/dwarf-frame.c Roland McGrath @ 2003-05-09 21:48 ` Elena Zannoni 2003-05-09 22:17 ` gdb/dwarf-frame.c Roland McGrath 2003-05-09 21:54 ` gdb/dwarf-frame.c Andrew Cagney 2003-05-09 21:58 ` gdb/dwarf-frame.c Daniel Jacobowitz 2 siblings, 1 reply; 43+ messages in thread From: Elena Zannoni @ 2003-05-09 21:48 UTC (permalink / raw) To: Roland McGrath; +Cc: Mark Kettenis, gdb Roland McGrath writes: > [I trimmed the CC because I think everyone else is on the mailing list.] > > > Yes indeed. I mostly use FreeBSD instead of Linux nowadays, so I > > haven't tracked what's been happening on the Linux thread front too > > closely. I get the feeling though that trying to support both the old > > and the new threading model in the same code isn't a good idea :-(. > > Can you be specific in your criticism? The rigamarole to get sibling > threads stopped and started is a bit unsightly, but not too horrible I > didn't think. I think trying to have separate backend implementations for > linuxthreads and nptl and switching among them (whether two target modules > or one with internal state flags) would be worse than any moderate amount > of kludgery in the one backend. > > The situation in lin-lwp.c can be much cleaner if Dan and I ever implement > the enhancements to ptrace in Linux 2.5 that we have discussed in detail > privately in the past. That would let thread tracing at the kernel level > work in a sane fashion with either kind of threads on a new kernel, and > make it easy to detect an old kernel lacking the new ptrace features and > fall back to the existing code that only supports linuxthreads. We can > probably be spurred to do this, though it has heretofore fallen off the end > of our queues of wonderful things that ought to be done real soon now. > > That doesn't help debugging NPTL on extant 2.5 kernels or on modified 2.4 > kernels that support NPTL like those in RHL9. But personally I am ok with > such support not going into mainline gdb if cleaner support for newer > kernels is there. (However I don't speak for my RH colleagues who will > have to maintain private patches as necessary.) > <FSF hat> I don't think it is a good idea for gdb6 to be broken on the most recent linux kernels. elena > > Thanks, > Roland ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb/dwarf-frame.c 2003-05-09 21:48 ` gdb/dwarf-frame.c Elena Zannoni @ 2003-05-09 22:17 ` Roland McGrath 0 siblings, 0 replies; 43+ messages in thread From: Roland McGrath @ 2003-05-09 22:17 UTC (permalink / raw) To: gdb > <FSF hat> > > I don't think it is a good idea for gdb6 to be broken on the most > recent linux kernels. Last I knew the GNU notion was to worry about "mainstream" kernels, which means vanilla released Linux 2.4.x and bleeding edge Linux 2.5.x (which changes its interfaces incompatibly between x's, since it's an experimental development version). > Roland, > > You can't seriously suggest that GDB should intentionally allow itself > to remain broken on very mainstream and released GNU/Linux systems (such > as Red Hat 9). > > Andrew Actually, I was saying that I wouldn't be arguing for code considered ugly (and that is just my impression of how Mark's opinion was charcterized from what I saw being said, not anything to be taken as meaning anything) to be in mainline gdb for the support RHL-modified kernels versions. I didn't say I would argue against it, either. That's up to the people who have gdb hats not made of flash paper like mine is. > I'd rather support it. I think we can, too. > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer Well, good! I know we can. I and everyone else at RH would surely prefer it if we did. I'm glad to hear that other people want to. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb/dwarf-frame.c 2003-05-09 21:19 ` gdb/dwarf-frame.c Roland McGrath 2003-05-09 21:48 ` gdb/dwarf-frame.c Elena Zannoni @ 2003-05-09 21:54 ` Andrew Cagney 2003-05-09 21:58 ` gdb/dwarf-frame.c Daniel Jacobowitz 2 siblings, 0 replies; 43+ messages in thread From: Andrew Cagney @ 2003-05-09 21:54 UTC (permalink / raw) To: Roland McGrath; +Cc: Mark Kettenis, gdb Roland, You can't seriously suggest that GDB should intentionally allow itself to remain broken on very mainstream and released GNU/Linux systems (such as Red Hat 9). Andrew ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb/dwarf-frame.c 2003-05-09 21:19 ` gdb/dwarf-frame.c Roland McGrath 2003-05-09 21:48 ` gdb/dwarf-frame.c Elena Zannoni 2003-05-09 21:54 ` gdb/dwarf-frame.c Andrew Cagney @ 2003-05-09 21:58 ` Daniel Jacobowitz 2003-05-09 22:18 ` gdb/dwarf-frame.c Roland McGrath 2 siblings, 1 reply; 43+ messages in thread From: Daniel Jacobowitz @ 2003-05-09 21:58 UTC (permalink / raw) To: Roland McGrath; +Cc: Mark Kettenis, gdb On Fri, May 09, 2003 at 02:19:31PM -0700, Roland McGrath wrote: > [I trimmed the CC because I think everyone else is on the mailing list.] > > > Yes indeed. I mostly use FreeBSD instead of Linux nowadays, so I > > haven't tracked what's been happening on the Linux thread front too > > closely. I get the feeling though that trying to support both the old > > and the new threading model in the same code isn't a good idea :-(. > > Can you be specific in your criticism? The rigamarole to get sibling > threads stopped and started is a bit unsightly, but not too horrible I > didn't think. I think trying to have separate backend implementations for > linuxthreads and nptl and switching among them (whether two target modules > or one with internal state flags) would be worse than any moderate amount > of kludgery in the one backend. > > The situation in lin-lwp.c can be much cleaner if Dan and I ever implement > the enhancements to ptrace in Linux 2.5 that we have discussed in detail > privately in the past. That would let thread tracing at the kernel level > work in a sane fashion with either kind of threads on a new kernel, and > make it easy to detect an old kernel lacking the new ptrace features and > fall back to the existing code that only supports linuxthreads. We can > probably be spurred to do this, though it has heretofore fallen off the end > of our queues of wonderful things that ought to be done real soon now. Coincidentally, I'm working on this this weekend. Or I was going to. The NPTL gdb patches do _not_ work on 2.5.69. The message about this is stuck in my outbox; I'm trying to get GDB to give me a backtrace but it's been chugging for an hour now with no luck (160K frames and counting!) > That doesn't help debugging NPTL on extant 2.5 kernels or on modified 2.4 > kernels that support NPTL like those in RHL9. But personally I am ok with > such support not going into mainline gdb if cleaner support for newer > kernels is there. (However I don't speak for my RH colleagues who will > have to maintain private patches as necessary.) I'd rather support it. I think we can, too. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb/dwarf-frame.c 2003-05-09 21:58 ` gdb/dwarf-frame.c Daniel Jacobowitz @ 2003-05-09 22:18 ` Roland McGrath 0 siblings, 0 replies; 43+ messages in thread From: Roland McGrath @ 2003-05-09 22:18 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Mark Kettenis, gdb > Coincidentally, I'm working on this this weekend. Or I was going to. > The NPTL gdb patches do _not_ work on 2.5.69. The message about this > is stuck in my outbox; I'm trying to get GDB to give me a backtrace but > it's been chugging for an hour now with no luck (160K frames and > counting!) Ok, I can hack on this. Post whatever details you have and I'll get started. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb/dwarf-frame.c 2003-05-09 19:43 ` gdb/dwarf-frame.c Mark Kettenis 2003-05-09 21:19 ` gdb/dwarf-frame.c Roland McGrath @ 2003-05-09 22:28 ` Andrew Cagney 2003-05-09 22:33 ` gdb/dwarf-frame.c Roland McGrath 1 sibling, 1 reply; 43+ messages in thread From: Andrew Cagney @ 2003-05-09 22:28 UTC (permalink / raw) To: Mark Kettenis; +Cc: ezannoni, msnyder, drow, roland, gdb > Date: Fri, 09 May 2003 13:00:54 -0400 > From: Andrew Cagney <ac131313@redhat.com> > > > Which reminds me that we should probably have the NPTL thread support > > patches integrated in gdb as well, since we are at this (and I have > > your attention). Can somebody (Daniel, Mark?) take a look at the > > patches? I can guarentee that they work, since they were shipped with > > RHL9's gdb. > > Just FYI, Michael or Mark. I don't think Mark is exactly comfortable > with the Linux thread stuff so ... > > Yes indeed. I mostly use FreeBSD instead of Linux nowadays, so I > haven't tracked what's been happening on the Linux thread front too > closely. I get the feeling though that trying to support both the old > and the new threading model in the same code isn't a good idea :-(. There is apparently a story here. I'm told that some people were arguing that GDB would need a complete rewrite if it were to ever support NPTL. Turned out to effectively be the oposite. Andrew ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb/dwarf-frame.c 2003-05-09 22:28 ` gdb/dwarf-frame.c Andrew Cagney @ 2003-05-09 22:33 ` Roland McGrath 0 siblings, 0 replies; 43+ messages in thread From: Roland McGrath @ 2003-05-09 22:33 UTC (permalink / raw) To: Andrew Cagney; +Cc: Mark Kettenis, ezannoni, msnyder, drow, gdb > There is apparently a story here. I'm told that some people were > arguing that GDB would need a complete rewrite if it were to ever > support NPTL. Turned out to effectively be the oposite. If you mean that the Linux kernel's ptrace implementation needed to be majorly overhauled to support its new kernel threads implementation even a little bit sensically, tnen yes. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb/dwarf-frame.c 2003-05-09 13:41 ` gdb/dwarf-frame.c Daniel Jacobowitz 2003-05-09 14:10 ` gdb/dwarf-frame.c Elena Zannoni @ 2003-05-09 20:32 ` Roland McGrath 1 sibling, 0 replies; 43+ messages in thread From: Roland McGrath @ 2003-05-09 20:32 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Mark Kettenis, gdb > My understanding from Mark's earlier post is that it is an intentional > but probably temporary omission - since dwarf-frame is only a week or > two old at this point. I want it all and I want it now, dammit! No, wait, wrong attitude module. That's what I was hoping to hear. Perhaps I can lend a hand to speed up the process of implementing the rest of it. > Should any work even be necessary? My understanding was that the > kernel code would show up in the shared library list. Oh, I guess it > is - we usually locate .eh_frame via BFD, which means section headers > and an on-disk file. I see. Indeedy. Thanks, Roland ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb/dwarf-frame.c 2003-05-09 9:45 gdb/dwarf-frame.c Roland McGrath 2003-05-09 13:41 ` gdb/dwarf-frame.c Daniel Jacobowitz @ 2003-05-09 19:36 ` Mark Kettenis 2003-05-09 21:34 ` gdb/dwarf-frame.c Roland McGrath 2003-05-10 7:07 ` gdb support for Linux vsyscall DSO Roland McGrath 1 sibling, 2 replies; 43+ messages in thread From: Mark Kettenis @ 2003-05-09 19:36 UTC (permalink / raw) To: roland; +Cc: gdb Date: Fri, 9 May 2003 02:45:29 -0700 From: Roland McGrath <roland@redhat.com> (Hi Mark! It's been too long since we hacked together.) (Hi Roland! I've drifted away a bit from glibc and the Hurd :-(.) [Please note that I am not on the mailing list, so keep me CC'd directly.] I have been looking at the kettenis_i386newframe-20030419-branch gdb code. I've been told that the new dwarf-frame.c replaces the dwarf2cfi.c code that's on mainline. I don't know the guts of either or of DWARF2 itself well enough to compare them. dwarf2cfi.c currently has more complete support for DWARF CFI, but suffers from some design flaws, which probably makes it unusable for debugging any serious project. What I have noticed is that dwarf-frame.c does not seem to handle the .eh_frame section, only the .debug_frame section. The dwarf2cfi.c code looks at both. As well as looking for the section, it needs to grok the "augmentation" values and different encodings used in .eh_frame, and I don't see any of that handled in the new code. Is this an intentional omission and if so what is the rationale? Daniel is right here. I'm busy writting the support for .eh_frame sections. I just left them out since they complicate matters quite a bit. I think grokking .eh_frame sections in the absence of .debug_frame is a nice thing in general--it might give you at least some more helpful backtraces than otherwise when dealing with binaries without debugging info. But the particular reason it is of concern to me is that it's needed for unwinding PC values within the special kernel entrypoint page now being used in Linux on x86. glibc now uses this entrypoint code for every system call, and so any thread blocked in a system call (which most threads one looks at are when one starts looking) will have its PC inside this code and need to be able to unwind that frame-pointer-less leaf frame to produce a useful backtrace. This is magic kernel code for which there is never going to be debugging information, but for which we do have .eh_frame information we can get at. I am setting about attacking how we get at it in all the relevant cases, but I had been working from the assumption that upon locating some information in .eh_frame form (including "zR" augmentation and pcrel pointer encoding) it would plug easily into the DWARF2 unwinding machinery. If that's not so, it throws a monkey wrench into my plans. It certainly is my intention to make it possible, although It's not clear how things should be glued together. I've seen your kernel patches and it seems as if there are two possibilities: 1. Reading the complete DSO from target memory, and somehow turning it in a bfd. That would make it possible to use the existing symbol reading machinere to read symbols and .eh_frame info. 2. Write a symbol reader that uses the run-tume dynamic linker (struct r_debug, struct link_map) to locate the dynamic section of the shared object, and uses it to read the relevant loaded sections of the DSO from the target and interpret those bits. If I'm not mistaken, the latter would also allow us to construct a minimal symbol table for DSO's even if the we don't have access to an on-disk file. We'll probably need some serious hacking on GDB's shared library support to make this all possible. Mark ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb/dwarf-frame.c 2003-05-09 19:36 ` gdb/dwarf-frame.c Mark Kettenis @ 2003-05-09 21:34 ` Roland McGrath 2003-05-09 21:46 ` gdb/dwarf-frame.c Elena Zannoni 2003-05-10 7:07 ` gdb support for Linux vsyscall DSO Roland McGrath 1 sibling, 1 reply; 43+ messages in thread From: Roland McGrath @ 2003-05-09 21:34 UTC (permalink / raw) To: Mark Kettenis; +Cc: gdb > Daniel is right here. I'm busy writting the support for .eh_frame > sections. I just left them out since they complicate matters quite a > bit. Great! Anything you can tell me about your progress on that code is much appreciated. I would be happy to help test and debug unfinished changes. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb/dwarf-frame.c 2003-05-09 21:34 ` gdb/dwarf-frame.c Roland McGrath @ 2003-05-09 21:46 ` Elena Zannoni 0 siblings, 0 replies; 43+ messages in thread From: Elena Zannoni @ 2003-05-09 21:46 UTC (permalink / raw) To: Roland McGrath; +Cc: Mark Kettenis, gdb Roland McGrath writes: > > Daniel is right here. I'm busy writting the support for .eh_frame > > sections. I just left them out since they complicate matters quite a > > bit. > > Great! Anything you can tell me about your progress on that code is much > appreciated. I would be happy to help test and debug unfinished changes. Going back to the original reason of the posting, Roland, do you have some particular design in mind as to the interface to retrieve the DSO information? elena ^ permalink raw reply [flat|nested] 43+ messages in thread
* gdb support for Linux vsyscall DSO 2003-05-09 19:36 ` gdb/dwarf-frame.c Mark Kettenis 2003-05-09 21:34 ` gdb/dwarf-frame.c Roland McGrath @ 2003-05-10 7:07 ` Roland McGrath 2003-05-10 17:24 ` Andrew Cagney 2003-05-10 17:55 ` Mark Kettenis 1 sibling, 2 replies; 43+ messages in thread From: Roland McGrath @ 2003-05-10 7:07 UTC (permalink / raw) To: Mark Kettenis; +Cc: gdb [I changed the subject of the thread to distinguish this part of the discussion from the state of DWARF CFI, which is a prerequisite but independent.] It's notable that I didn't say i386 in the subject. I am helping David Mosberger implement the same concept on ia64 in Linux 2.5 as well. When glibc starts using those entry points on Linux/ia64 (it doesn't yet), then there will be the same issues for getting at the unwind info. The vsyscall DSO plan will be the same, so getting at the ELF sections is addressed the same way (more on that below). In the ia64 case, the unwind info is ia64's flavor rather than DWARF2 flavor, but the use of ELF phdrs and sections to locate it is precisely analogous. > It certainly is my intention to make it possible, although It's not > clear how things should be glued together. As you might imagine, I had thought through most of the details of what gdb needs to do when I made the kernel changes (whose main purpose for me was to make the gdb support possible). There are two cases that need to be addressed. You've brought up the case of live processes. There is also the case of core dumps. > I've seen your kernel patches and it seems as if there are two > possibilities: You omitted possibility #0, which I had intended to preemptively describe and explain why I rejected it. That is, to have some file that gdb can read. It would be simple to have a /proc file that gives you the DSO image as a virtual file, and have the dynamic linker's shlib list refer to this file name. Then gdb might not need any change at all. However, this sucks rocks for remote debugging. It also doesn't sit right with me because the vsyscall DSO is actually there and your PC might be in it, even if you are not using the dynamic linker or glibc at all and have no "info shared" list. > 1. Reading the complete DSO from target memory, and somehow turning it > in a bfd. That would make it possible to use the existing symbol > reading machinere to read symbols and .eh_frame info. This is what I had anticipated doing, at least the first cut. Given some true assumptions about the vsyscall DSO, it is trivial to compute the total file size from the ELF headers and recover the byte image of the file exactly. It can't be too hard to fake up a bfd in memory as if the contents had been read from a file. Having a bfd of the DSO file makes it simple to plug it into the existing code that looks for the sections by name. I do have one minor concern about that. An ELF stripping utility is well within its rights to remove the section headers entirely from a DSO, and such DSOs work fine. The binutils and elfutils strip do not do this (nor ld -s, nor anything else using bfd), but they could one day. If the kernel people decide to shave off 149 bytes from the image by getting rid of the section headers and .shstrtab, it's hard for me to argue that they really shouldn't do that. And any stripped ELF DSO could reasonably have its section headers removed for whatever reason. I think this would be addressed adequately by having bfd do the same faking of sections based on ELF phdrs that it does for core files, on any ELF file that has no section headers but does have phdrs. But that is not an immediate concern, just something to air. Let's assume we can fake a bfd containing the DSO file contents by finding its ELF header in the inferior's memory. Right now it would be a digression to go into how we know where to look; I will get into that at the end. At this point it seems apropos to describe the core file situation before getting to your #2. Core files are sectionless ELF files that have ELF program headers. In the vsyscall DSO changes, I made Linux core dumps include the DSO image as part of the memory dump (just as it appeared in memory) and also copy the DSO's special phdrs to the core file, with adjusted file offsets. Hence a new Linux core dump has both a PT_GNU_EH_FRAME pointing at the DSO's .eh_frame_hdr section and a PT_DYNAMIC pointing at its .dynamic section. In these phdrs, p_vaddr and other fields match those phdrs in the DSO, but p_offset gives the position in the core dump file where that section within the DSO file image appears. This means that the existing section-faking code for ELF core files (including my recent change to it) will give a core file bfd sections called "eh_frame_hdr13" and "dynamic12" or suchlike. I made simple changes to dwarf2read.c to match sections named "eh_frame_hdr*" as it matches ".eh_frame", and to dwarf2cfi.c to grok the .eh_frame_hdr format to locate .eh_frame within some other memory section (it will be in "load11" or something). The same changes are trivial to make to new code given the machinery for grokking .eh_frame format and its pointer encodings. With that, I think that finding vsyscall unwind info from core dumps is accomplished just by making an objfile for the core file bfd and plugging it into the unwind info grokking hooks or making it a symfile or something. The part I don't know off hand how to do is making sure the objfile/symfile comes and goes appropriately with attaching/detaching from a core dump. I presume that is straightforward for those better versed in gdb. As it stands now, the vsyscall DSO has normal section headers. So matching ".eh_frame" or ".eh_frame_hdr" by name in that special bfd is adequate. If it (or other DSOs) were fully stripped, then having bfd fake named sections for these bfds as it does for ELF core file bfds would be sufficient to trivially handle those as well. > 2. Write a symbol reader that uses the run-tume dynamic linker (struct > r_debug, struct link_map) to locate the dynamic section of the > shared object, and uses it to read the relevant loaded sections of > the DSO from the target and interpret those bits. > > If I'm not mistaken, the latter would also allow us to construct a > minimal symbol table for DSO's even if the we don't have access to an > on-disk file. Indeed so! Or even if you just have a completely stripped ELF DSO on disk. (Or even if you just get so tired of turning off auto-solib-add and using add-symbol-file, and cursing its inability to add .text's vma to the loadbase itself so you don't have to run objdump -h every damn time, umpty-ump times a day debugging subhurds, that you just break down and implement solib-absolute-prefix and become a compulsive maniac to keep development and test filesystems synchronized! Oh, I guess that won't exactly be happening to anyone else in the future. ;-) This is roughly the same as what I had thought would be the better long-term plan than the above section-matching. However, I would separate it into two pieces. I would still advocate using a special case mechanism to find the vsyscall DSO's ELF header and locate its guts from there. That works even if the run-tomb dynamic linker's data structures are mangled or missing. But it is cleaner for the reasons above if that works from the phdrs out (thence quickly to .dynamic) only, and doesn't rely on finding section headers in the DSO. Whether you use dynamic linker data structures or other magic to locate a DSO's .dynamic section in memory, from there the procedure is the same to locate its dynamic symbol table. > We'll probably need some serious hacking on GDB's shared library support > to make this all possible. Not necessarily. It's straightforward to locate the dynamic symbol table and its string table by reading the .dynamic section, then copy them out of the inferior and interpret the ELF symbol table format as we already do. There are two ways to attack it. One is to read the symbol and string tables and then poke them directly into gdb symbol table form. The other approach is to fake a bfd containing .dynsym and .dynstr sections, plug that in as an implicit symfile something like how separate debug info files are attached along with the stripped objfiles they correspond to, and let the existing infrastructure go to town. To support everything we have mentioned, these are the steps I would take: * Soup up the section-faking code now applied to core dumps so that it not only creates the dynamic* section but reads its contents to locate and fake sections called .dynsym et al. Then if we treat a core dump as a symfile, it will provide the vsyscall DSO's symbols. If we apply this section-faking code to all sectionless ELF files, then fully-stripped DSOs will be supported just as DSO's from binutils strip are now. * For the vsyscall DSO, we read its ELF header from the inferior. If it has section headers as it does now, we can calculate the total file image size to include those, fake a bfd containing the whole image, and all the existing support for an ELF DSO works (symbols and all). If it doesn't have section headers, or we decide to ignore them, then we use only the file's PT_LOAD phdr to read the runtime memory image. In that case, the section-faking code needs to apply to this synthesized bfd both to find .eh_frame_hdr via PT_GNU_EH_FRAME (or .IA64_unwind via PT_IA_64_UNWIND) and to find dynamic symbols via PT_DYNAMIC. * For normal DSOs when you can't find the file on disk (or don't want to use it; there should probably be a new variant of auto-solib-add to control reading symbols from the inferior image as well as disk files), you can straightforwardly get the .dynamic section's address from the dynamic linker. You can copy that from the inferior and from it know the locations of the .dynsym and .dynstr sections and copy them as well, putting it all into a synthesized bfd with those section names faked. There is no "proper" way to locate the phdrs, which you need to find the .eh_frame information. However, in practice you can often assume that the loadbase (l_addr) points at the shared object's ELF header, and you can verify this by reading that memory and sanity-checking the ELF header format. If you do that, you have all the phdrs and can use the PT_LOAD headers to fill out the solib bounds normally gotten from the disk file. However, prelinked DSOs may not make it easy to find the ELF header (l_addr is zero). These latter ideas (everything from the quoted #2 on) are of secondary concern. I went into complete detail about them now only because you brought it up. Symbols from the vsyscall DSO in a core dump are nice, but not essential. Getting details from normal DSOs without using disk files is a new feature that is very nice but not necessary, nor related except in implementation details, to supporting vsyscall stuff. The steps above are not part of my immediate goals. The essential need is to get .eh_frame information from the vsyscall DSO in both live processes and core dumps. The section-faking code already suffices for core dumps. For the time being, the image provided by the kernel does have section headers, so it suffices just to synthesize a bfd containing the whole file image read out of a live inferior's memory. My immediate goal is to get things working just using this. Other things we can see about later. For this immediate goal, I would take these steps: 1. Make dwarf-frame.c work with .eh_frame info. Mark is working on this, so I will wait for him or help with getting it done. 2. Make dwarf-frame.c locate .eh_frame via .eh_frame_hdr, matching a section named "eh_frame_hdrNN" as core dumps now have. This is pretty trivial after step 1. 3. Modify corelow.c to do something like symbol_add_file with the core bfd. If that barfs on some backends, it could be done just for ELF cores. I don't think it needs to be put into a Linux-specific module; if any other ELF core files contain useful phdrs they will work the same way. It also needs to remove the objfile/symfile again when the core file is detached. On this I could use advice from those more expert on gdb. I think it may suffice to call symbol_file_add on the core file name in place of opening the bfd directly, store the objfile pointer somewhere, and call free_objfile in core_detach. But that is only a guess. I can write this bit and observe internally that it works independent of the steps above that make it useful, so immediate implementation advice is solicited. 4. Write a function that creates an in-memory bfd by reading an ELF header and the information it points to from inferior memory. I'll take a whack at this soon. 5. Write Linux backend code to locate the vsyscall DSO's ELF header, use that function to synthesize a bfd, and so something like symbol_add_file with it. I'm not sure where this belongs. It will be Linux-specific but not necessarily machine-dependent. Where it belongs exactly probably depends on how exactly the locating is done. The need to attach and detach the synthesized objfile is similar to the core file case. Heretofore I have avoided mentioning how we locate the vsyscall DSO's ELF header in the inferior's address space. It's an unresolved question that needs discussion, but it's a minor and boring detail among all the issues involved here. I saved it for those with the proven stamina to get through the first 200 lines of my ranting. The kernel tells the running process itself where to find the vsyscall DSO image with an ElfNN_auxv_t element of type AT_SYSINFO_EHDR in the aux vector it writes at the base of the stack at process startup. For gdb to determine this value, there are several approaches possible. * Add a ptrace request just for it, i.e. PTRACE_GETSYSINFO_EHDR or something. That is trivial to add on the kernel side, and easy for native Linux backend code to use. It just seems sort of unsightly. A way to get that address from some /proc/PID file would be equivalent. * Locate the address of the aux vector and read it out the inferior's stack. The aux vector is placed on the stack just past the environment pointers. AFAIK, gdb doesn't already have a way to know this stack address. It's simple to record it in the kernel without significant new overhead, and have a way via either ptrace or /proc to get this address. I raise this suggestion because it may be most acceptable to the Linux kernel folks to add something with so little kernel work involved. The problem with this is that the program might have clobbered its stack. glibc doesn't ordinarily modify it, but a buggy program might clobber it by random accident, and any program is within its rights to reuse that part of the stack. It won't have done so at program startup, but if you attach to a live process that has clobbered this part of its stack then you won't find the vsyscall info so as to unwind from those PCs properly. I am curious what gdb hackers' opinions on this danger are. * Add a way to get the original contents of the aux vector, like /proc/PID/auxv on Solaris. That could be /proc/PID/auxv, or new ptrace requests that act like the old PIOCNAUXV and PIOCAUXV. On Solaris, /proc/PID/auxv's contents are not affected by PID clobbering the auxv on its stack. In Linux, about half of the auxv entries are constants the kernel can easily fill in anew on the fly, but the other half are specific bits about the executable that are not easy to recover later from other saved information. Though AT_SYSINFO_EHDR is all we need, a general interface like this really should give the complete set that was given to the process. By far the simplest way to implement that is simply to save the array in the kernel. As the kernel code is now, I can do that without any additional copying overhead, but it does add at least 34 words to the process data structure, which Linux kernel people might well reject. Of these three options, this one is my preference on aesthetic grounds but I don't know whether it will happen on the kernel side. I have not been able to imagine any way to get this magic address (the vsyscall DSO loadbase) directly from the system that does not require a special backend call and therefore cause some kind of new headache for remote debugging. I don't know what people's thinking is on trying to translate this kind of thing across the remote protocol. There is also the option to punt trying to find it directly from the system, and rely on the dynamic linker's data structures to locate it. As mentioned above, I don't like relying on the inferior's data structures not being frotzed, nor relying on there being a normal dynamic linker to be able know about the vsyscall DSO. Furthermore, the normal dynamic linker report of l_addr is not helpful because that "loadbase" is the bias relative to the addresses in the DSO's phdrs, which is 0 for the vsyscall DSO since it is effectively prelinked. The only address directly available is l_ld, the address of its .dynamic section. There is no proper way from that to locate the phdrs or ELF file header, so it would have to be some kludge rounding down or searching back from there or something. The only thing favoring this approach is that it requires no new target interfaces and no new remote debugging complications. I think this question is pretty open, though not all that exciting. My inclination is to implement /proc/PID/auxv (with storage overhead) and see what the Linux kernel hackers' reaction to that is. They may suggest that it work by reading out of the process stack (which is what /proc/PID/cmdline and /proc/PID/environ do). I would like to know opinions from the gdb camp on how bad a thing to do that might be. Second choice is ot make /proc/PID/maps list the vsyscall DSO mapping in a recognizable way; that is likely to go over well enough with the kernel hackers. I would be all for an entirely different solution that is both robust (not relying on the inferior's own fungible memory) and remote-friendly, if anyone thinks of one. I have raised a lot of crapola in this message. I hope I have been clear in specifying the details on which I need some assistance and direction. Aside from the DWARF2 CFI stuff per se, I am prepared to write all the necessary code myself and am only soliciting for advice, not for anyone else to implement it. Thanks, Roland ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb support for Linux vsyscall DSO 2003-05-10 7:07 ` gdb support for Linux vsyscall DSO Roland McGrath @ 2003-05-10 17:24 ` Andrew Cagney 2003-05-10 18:13 ` Daniel Jacobowitz 2003-05-10 21:28 ` Roland McGrath 2003-05-10 17:55 ` Mark Kettenis 1 sibling, 2 replies; 43+ messages in thread From: Andrew Cagney @ 2003-05-10 17:24 UTC (permalink / raw) To: Roland McGrath; +Cc: Mark Kettenis, gdb Roland, How exactly does this vsyscall memory region(1) come to be? For instance, how does GLIBC come to know where it is - GLIBC would need the region's address to perform a syscall to find the regions address. If the underlying mechanism is explained (this is far from a tranditional lib*.so), GDB developers will be in a better position to judge the best way of handling this. Is there, for instance, anything to prevent GDB locating the symbol (in GLIBC) that points at the vsyscall area and then using that? Similar for any mapped in eh_frame region. Assuming that GDB has a well defined trigger point for knowing when the symbol can be referenced - but GDB would need that anyway. This would eliminate the need to store all this elf header stuff in the Kernel, let GDB confine any changes to a single linux-tdep.c file, and even work remotely or with a core file. However, before anyone tries to run with such ideas, what's really going on? enjoy, Andrew ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb support for Linux vsyscall DSO 2003-05-10 17:24 ` Andrew Cagney @ 2003-05-10 18:13 ` Daniel Jacobowitz 2003-05-10 19:42 ` Roland McGrath 2003-05-10 21:28 ` Roland McGrath 1 sibling, 1 reply; 43+ messages in thread From: Daniel Jacobowitz @ 2003-05-10 18:13 UTC (permalink / raw) To: Andrew Cagney; +Cc: Roland McGrath, Mark Kettenis, gdb On Sat, May 10, 2003 at 01:24:39PM -0400, Andrew Cagney wrote: > Roland, > > How exactly does this vsyscall memory region(1) come to be? For > instance, how does GLIBC come to know where it is - GLIBC would need the > region's address to perform a syscall to find the regions address. If > the underlying mechanism is explained (this is far from a tranditional > lib*.so), GDB developers will be in a better position to judge the best > way of handling this. It's created initially by the kernel, and its address is passed via the auxilliary vector on the stack, and read by ld.so. Roland explained later in his essay about some ways to get at the aux vector. > Is there, for instance, anything to prevent GDB locating the symbol (in > GLIBC) that points at the vsyscall area and then using that? Similar > for any mapped in eh_frame region. Assuming that GDB has a well defined > trigger point for knowing when the symbol can be referenced - but GDB > would need that anyway. > > This would eliminate the need to store all this elf header stuff in the > Kernel, let GDB confine any changes to a single linux-tdep.c file, and > even work remotely or with a core file. The down side is that this is then glibc specific... the mechanism isn't glibc's. I think that's Roland's intention at least. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb support for Linux vsyscall DSO 2003-05-10 18:13 ` Daniel Jacobowitz @ 2003-05-10 19:42 ` Roland McGrath 2003-05-10 21:49 ` Andrew Cagney 0 siblings, 1 reply; 43+ messages in thread From: Roland McGrath @ 2003-05-10 19:42 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb For some reason I didn't see Andrew's message in my mailbox, though I see it in the mailing list archives (I'm not on the mailing list myself). > On Sat, May 10, 2003 at 01:24:39PM -0400, Andrew Cagney wrote: > > Roland, > > > > How exactly does this vsyscall memory region(1) come to be? For > > instance, how does GLIBC come to know where it is - GLIBC would need the > > region's address to perform a syscall to find the regions address. If > > the underlying mechanism is explained (this is far from a tranditional > > lib*.so), GDB developers will be in a better position to judge the best > > way of handling this. > > It's created initially by the kernel, and its address is passed via the > auxilliary vector on the stack, and read by ld.so. Roland explained > later in his essay about some ways to get at the aux vector. The memory is always there. As I explained near the end of my long message, the kernel tells the program where to find it with the AT_SYSINFO_EHDR (and AT_SYSINFO, which is now redundant) elements in the aux vector on the stack at at startup. The glibc dynamic linker code sets up its own data structures for the vsyscall DSO as if it had been mapped itself. There is no special case in glibc that points at the eh_frame info. Exception handling in libgcc already uses a dynamic linker callback to see the phdrs of all DSOs in core and follow their PT_GNU_EH_FRAME pointers. The vsyscall DSO's eh_frame info is found by this mechanism like other DSOs' are. > > Is there, for instance, anything to prevent GDB locating the symbol (in > > GLIBC) that points at the vsyscall area and then using that? Similar > > for any mapped in eh_frame region. Assuming that GDB has a well defined > > trigger point for knowing when the symbol can be referenced - but GDB > > would need that anyway. Nothing prevents it but class. The vsyscall DSO is a Linux kernel feature, not a glibc feature. It isn't proper layering for the support for it to depend on glibc internals. There are any number of things that could be done simpler by presuming the form of glibc internals and requiring they be there. That doesn't make them the right things to do. I said "the purpose of the vsyscall DSO for me is to make the gdb support possible". Perhaps that gave the wrong impression. The gdb issue is what made me personally really interested in implementing it, but was only one of many factors leading to the choice of having an ELF DSO image provided by the kernel. The DSO plan is here to stay and does not exist solely for the benefit of gdb. Thanks, Roland ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb support for Linux vsyscall DSO 2003-05-10 19:42 ` Roland McGrath @ 2003-05-10 21:49 ` Andrew Cagney 2003-05-12 19:23 ` Andrew Cagney 0 siblings, 1 reply; 43+ messages in thread From: Andrew Cagney @ 2003-05-10 21:49 UTC (permalink / raw) To: Roland McGrath; +Cc: gdb >> On Sat, May 10, 2003 at 01:24:39PM -0400, Andrew Cagney wrote: > >> > Roland, >> > >> > How exactly does this vsyscall memory region(1) come to be? For >> > instance, how does GLIBC come to know where it is - GLIBC would need the >> > region's address to perform a syscall to find the regions address. If >> > the underlying mechanism is explained (this is far from a tranditional >> > lib*.so), GDB developers will be in a better position to judge the best >> > way of handling this. > >> >> It's created initially by the kernel, and its address is passed via the >> auxilliary vector on the stack, and read by ld.so. Roland explained >> later in his essay about some ways to get at the aux vector. > > > The memory is always there. As I explained near the end of my long > message, the kernel tells the program where to find it with the > AT_SYSINFO_EHDR (and AT_SYSINFO, which is now redundant) elements in the > aux vector on the stack at at startup. > > The glibc dynamic linker code sets up its own data structures for the > vsyscall DSO as if it had been mapped itself. There is no special case in > glibc that points at the eh_frame info. Exception handling in libgcc > already uses a dynamic linker callback to see the phdrs of all DSOs in core > and follow their PT_GNU_EH_FRAME pointers. The vsyscall DSO's eh_frame > info is found by this mechanism like other DSOs' are. > > >> > Is there, for instance, anything to prevent GDB locating the symbol (in >> > GLIBC) that points at the vsyscall area and then using that? Similar >> > for any mapped in eh_frame region. Assuming that GDB has a well defined >> > trigger point for knowing when the symbol can be referenced - but GDB >> > would need that anyway. > > > Nothing prevents it but class. The vsyscall DSO is a Linux kernel feature, > not a glibc feature. It isn't proper layering for the support for it to > depend on glibc internals. There are any number of things that could be > done simpler by presuming the form of glibc internals and requiring they be > there. That doesn't make them the right things to do. It doesn't make it the wrong thing to do either. As they say, keep it simple. What was posted was a worryingly long list of changes for something that should be relatively straight forward - find the eh-frame stuff and use it. Any way, re-reading your post yes, the info is in there. If the address is known, GDB can pull the contents out of memory. Given the list of targets: - core - native attach - native run - remote - ?more? I believe the choices are: - find a way of determing that address across all of these targets :-/ - implement per-target custom mechanisms for pulling out this information (creating a need to test/implement each target separatly - vis the corefile + dwarf2 changes) :-// So, it possible to find the address (symbol?, /proc, shlib load table, ...?) for all targets? /proc/PID/map, on a remote, is a possability. A remote version of find_memory_regions() would be useful anyway - clean up gcore a bit. However, the down side is that a system with no /proc mounted wouldn't debug very well :-/ Andrew ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb support for Linux vsyscall DSO 2003-05-10 21:49 ` Andrew Cagney @ 2003-05-12 19:23 ` Andrew Cagney 2003-05-13 2:29 ` Roland McGrath 0 siblings, 1 reply; 43+ messages in thread From: Andrew Cagney @ 2003-05-12 19:23 UTC (permalink / raw) To: Roland McGrath, Daniel Jacobowitz; +Cc: gdb > Any way, re-reading your post yes, the info is in there. If the address is known, GDB can pull the contents out of memory. Given the list of targets: > > - core > - native attach > - native run > - remote > - ?more? > > I believe the choices are: > > - find a way of determing that address across all of these targets :-/ > - implement per-target custom mechanisms for pulling out this information (creating a need to test/implement each target separatly - vis the corefile + dwarf2 changes) :-// > > So, it possible to find the address (symbol?, /proc, shlib load table, ...?) for all targets? > > /proc/PID/map, on a remote, is a possability. A remote version of find_memory_regions() would be useful anyway - clean up gcore a bit. However, the down side is that a system with no /proc mounted wouldn't debug very well :-/ To follow up my own e-mail. On Solaris, there is: /proc/PID/auxv and the corresponding core file includes a .note section that contains (man core.4): auxv_t array n_type: NT_AUXV. This entry contains the array of auxv_t structures that was passed by the operating system as startup information to the dynamic linker. Auxiliary vector information is defined in <sys/auxv.h>. So the /proc solution even as ``prior art''. As for the remote case, I think GDB's remote protocol (via the target vector) should allow access to the remote file system (lib*.so, /proc, ....) anyway. Doing that would let the OS dependant code access the remote /proc/PID/aux. All sorts of useful things would suddenly ``just work''. To me this looks like the simplest and cleanest way of solving the problem. A conistent mechanism to find the address, and a single technique for accessing the .eh_frame info. That has to be better than approaches that require per-target custom modifications for what is a Linux specific problem. Andrew ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb support for Linux vsyscall DSO 2003-05-12 19:23 ` Andrew Cagney @ 2003-05-13 2:29 ` Roland McGrath 2003-05-13 16:03 ` Andrew Cagney 0 siblings, 1 reply; 43+ messages in thread From: Roland McGrath @ 2003-05-13 2:29 UTC (permalink / raw) To: Andrew Cagney; +Cc: Daniel Jacobowitz, gdb > To follow up my own e-mail. On Solaris, there is: > > /proc/PID/auxv [...] > So the /proc solution even as ``prior art''. Indeed. When I said, "like /proc/PID/auxv on Solaris", I was in fact citing the existing Solaris interface as exactly what we might do. However, as I said and for reasons I explained, we might not get buy-in from kernel maintainers for supporting that. I don't think that the prior art of Solaris interfaces is something they find particularly compelling. I'm not saying this feature won't happen--I certainly like it fine. My intent in starting the thread about the various possible sorts of kernel interface was to flesh out the full range of acceptable options and their preference ordering from the gdb perspective, to have on hand when I go and argue for whichever of them we can get from the kernel maintainers. > and the corresponding core file includes a .note section that contains I'm aware of the Solaris formats (which are all pretty reasonable). If Linux kernel maintainers accept the /proc/PID/auxv implementation, then I am quite sure they will also accept NT_AUXV note writing (the kernel support required is the same for both). However, the core note does not provide any new magic bullet. There would still be new code required to grok it; that code is straightforward, but both a bit more complex and a bit more costly than the core phdr support that is already there now. > As for the remote case, I think GDB's remote protocol (via the target > vector) should allow access to the remote file system (lib*.so, /proc, > ....) anyway. Doing that would let the OS dependant code access the > remote /proc/PID/aux. All sorts of useful things would suddenly ``just > work''. I have nothing against that. It obviously makes any /proc-based solution work for remote (requiring /proc be mounted is an issue for both native and remote). I assume then that linux-proc.c would be made to use some new target interface for the file-reading and thus start working via remote. Then the support for reading either /proc/PID/auxv or /proc/PID/maps to discern the vsyscall DSO address naturally fits there, machine-independent. > To me this looks like the simplest and cleanest way of solving the > problem. A conistent mechanism to find the address, and a single > technique for accessing the .eh_frame info. That has to be better than > approaches that require per-target custom modifications for what is a > Linux specific problem. As I said before, I am certainly happiest with someplace to put the kernel-specific support that is not machine-specific. The support for using core file phdrs (to sort of treat the core file as if it were the DSO) is so simple (and already works), that I am inclined to leave that rather than reading the vsyscall DSO image out of the core file memory dump after using the NT_AUXV note to locate it. The code for making a bfd from the in-memory DSO image is already needed for the live case, so that's not extra work. But as well as it being more efficient to use the core file bfd directly rather than read part of the file into memory and make that into a separate bfd, it's also simpler, slightly more efficient, and already done(!), to use the core file's PT_GNU_EH_FRAME (and then you've got it right there) than to even to look for an NT_AUXV note and the AT_SYSINFO_EHDR element within it before you can fake up the bfd and search it for eh_frame. Thanks, Roland ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb support for Linux vsyscall DSO 2003-05-13 2:29 ` Roland McGrath @ 2003-05-13 16:03 ` Andrew Cagney 0 siblings, 0 replies; 43+ messages in thread From: Andrew Cagney @ 2003-05-13 16:03 UTC (permalink / raw) To: Roland McGrath; +Cc: Daniel Jacobowitz, gdb Roland, There is no silver bullet. However, there are designs that [I think] provide both GDB and the kernel the best of possible worlds. If the kernel simply dumps out its raw information (instead of cooking it in a way it thinks will be useful to debuggers) then GDB can pick and choose what it really needs. This also means that the core file and live process are both furnishing GDB with identical data. Might even make the kernel cleaner. Andrew ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb support for Linux vsyscall DSO 2003-05-10 17:24 ` Andrew Cagney 2003-05-10 18:13 ` Daniel Jacobowitz @ 2003-05-10 21:28 ` Roland McGrath 1 sibling, 0 replies; 43+ messages in thread From: Roland McGrath @ 2003-05-10 21:28 UTC (permalink / raw) To: Andrew Cagney; +Cc: Mark Kettenis, gdb Btw, I did get this msg from Andrew, just delayed a few hours. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb support for Linux vsyscall DSO 2003-05-10 7:07 ` gdb support for Linux vsyscall DSO Roland McGrath 2003-05-10 17:24 ` Andrew Cagney @ 2003-05-10 17:55 ` Mark Kettenis 2003-05-10 20:27 ` Roland McGrath 1 sibling, 1 reply; 43+ messages in thread From: Mark Kettenis @ 2003-05-10 17:55 UTC (permalink / raw) To: roland; +Cc: gdb Date: Sat, 10 May 2003 00:07:07 -0700 From: Roland McGrath <roland@redhat.com> It's notable that I didn't say i386 in the subject. I am helping David Mosberger implement the same concept on ia64 in Linux 2.5 as well. When glibc starts using those entry points on Linux/ia64 (it doesn't yet), then there will be the same issues for getting at the unwind info. The vsyscall DSO plan will be the same, so getting at the ELF sections is addressed the same way (more on that below). In the ia64 case, the unwind info is ia64's flavor rather than DWARF2 flavor, but the use of ELF phdrs and sections to locate it is precisely analogous. Thanks for your detailed explanation. No work has yet been done to convert GDB's ia64 target to make it use the new frame unwinder framework. Andrew's idea was that it should be possible to just hook the frame unwind methods into an existing target, but that hasn't been tested yet. > It certainly is my intention to make it possible, although It's not > clear how things should be glued together. As you might imagine, I had thought through most of the details of what gdb needs to do when I made the kernel changes (whose main purpose for me was to make the gdb support possible). There are two cases that need to be addressed. You've brought up the case of live processes. There is also the case of core dumps. > I've seen your kernel patches and it seems as if there are two > possibilities: You omitted possibility #0, which I had intended to preemptively describe and explain why I rejected it. That is, to have some file that gdb can read. It would be simple to have a /proc file that gives you the DSO image as a virtual file, and have the dynamic linker's shlib list refer to this file name. Then gdb might not need any change at all. However, this sucks rocks for remote debugging. It also doesn't sit right with me because the vsyscall DSO is actually there and your PC might be in it, even if you are not using the dynamic linker or glibc at all and have no "info shared" list. Yup, that's why I didn't mention it :-). > 1. Reading the complete DSO from target memory, and somehow turning it > in a bfd. That would make it possible to use the existing symbol > reading machinere to read symbols and .eh_frame info. This is what I had anticipated doing, at least the first cut. Given some true assumptions about the vsyscall DSO, it is trivial to compute the total file size from the ELF headers and recover the byte image of the file exactly. It can't be too hard to fake up a bfd in memory as if the contents had been read from a file. Fair enough. [...] > 2. Write a symbol reader that uses the run-tume dynamic linker (struct > r_debug, struct link_map) to locate the dynamic section of the > shared object, and uses it to read the relevant loaded sections of > the DSO from the target and interpret those bits. > > If I'm not mistaken, the latter would also allow us to construct a > minimal symbol table for DSO's even if the we don't have access to an > on-disk file. Indeed so! Or even if you just have a completely stripped ELF DSO on disk. (Or even if you just get so tired of turning off auto-solib-add and using add-symbol-file, and cursing its inability to add .text's vma to the loadbase itself so you don't have to run objdump -h every damn time, umpty-ump times a day debugging subhurds, that you just break down and implement solib-absolute-prefix and become a compulsive maniac to keep development and test filesystems synchronized! Oh, I guess that won't exactly be happening to anyone else in the future. ;-) This is roughly the same as what I had thought would be the better long-term plan than the above section-matching. However, I would separate it into two pieces. I would still advocate using a special case mechanism to find the vsyscall DSO's ELF header and locate its guts from there. That works even if the run-tomb dynamic linker's data structures are mangled or missing. But it is cleaner for the reasons above if that works from the phdrs out (thence quickly to .dynamic) only, and doesn't rely on finding section headers in the DSO. The run-time dynamic linker's data structures usually are intact, but a fall-back mechanism wouldn't hurt I guess. [...] These latter ideas (everything from the quoted #2 on) are of secondary concern. I went into complete detail about them now only because you brought it up. Symbols from the vsyscall DSO in a core dump are nice, but not essential. Getting details from normal DSOs without using disk files is a new feature that is very nice but not necessary, nor related except in implementation details, to supporting vsyscall stuff. The steps above are not part of my immediate goals. OK, as long as we try to keep the code as generic as possible and isolate platform-specific hacks in platform-specific files. Note that symbols from the vsyscall would be very helpful to the user. There is also an issue with signal trampolines. GDB needs to be able to recognize them in order to support stepping over functions when a signal arrives. I proposed Richard Henderson to add a special DWARF CFI augmentation to mark __kernel_sigreturn and __kernel_rt_sigreturn as signal trampolines. That would allow me to recognize them without knowing their names. The essential need is to get .eh_frame information from the vsyscall DSO in both live processes and core dumps. The section-faking code already suffices for core dumps. For the time being, the image provided by the kernel does have section headers, so it suffices just to synthesize a bfd containing the whole file image read out of a live inferior's memory. My immediate goal is to get things working just using this. Other things we can see about later. For this immediate goal, I would take these steps: 1. Make dwarf-frame.c work with .eh_frame info. Mark is working on this, so I will wait for him or help with getting it done. I just checked something in. It could use a few more comments, and certainly needs to be tested, but the basic support for .eh_frame sections is there. 2. Make dwarf-frame.c locate .eh_frame via .eh_frame_hdr, matching a section named "eh_frame_hdrNN" as core dumps now have. This is pretty trivial after step 1. 3. Modify corelow.c to do something like symbol_add_file with the core bfd. If that barfs on some backends, it could be done just for ELF cores. I don't think it needs to be put into a Linux-specific module; if any other ELF core files contain useful phdrs they will work the same way. It also needs to remove the objfile/symfile again when the core file is detached. On this I could use advice from those more expert on gdb. I think it may suffice to call symbol_file_add on the core file name in place of opening the bfd directly, store the objfile pointer somewhere, and call free_objfile in core_detach. But that is only a guess. I can write this bit and observe internally that it works independent of the steps above that make it useful, so immediate implementation advice is solicited. Ordinary shared libraries are cleared out in core_close() by CLEAR_SOLIB(). This calls solib.c:clear_solib(), so I think you should remove things in that codepath. 4. Write a function that creates an in-memory bfd by reading an ELF header and the information it points to from inferior memory. I'll take a whack at this soon. 5. Write Linux backend code to locate the vsyscall DSO's ELF header, use that function to synthesize a bfd, and so something like symbol_add_file with it. I'm not sure where this belongs. It will be Linux-specific but not necessarily machine-dependent. Where it belongs exactly probably depends on how exactly the locating is done. The need to attach and detach the synthesized objfile is similar to the core file case. Heretofore I have avoided mentioning how we locate the vsyscall DSO's ELF header in the inferior's address space. It's an unresolved question that needs discussion, but it's a minor and boring detail among all the issues involved here. I saved it for those with the proven stamina to get through the first 200 lines of my ranting. I made it hrough ;-). The kernel tells the running process itself where to find the vsyscall DSO image with an ElfNN_auxv_t element of type AT_SYSINFO_EHDR in the aux vector it writes at the base of the stack at process startup. For gdb to determine this value, there are several approaches possible. * Add a ptrace request just for it, i.e. PTRACE_GETSYSINFO_EHDR or something. That is trivial to add on the kernel side, and easy for native Linux backend code to use. It just seems sort of unsightly. A way to get that address from some /proc/PID file would be equivalent. * Locate the address of the aux vector and read it out the inferior's stack. The aux vector is placed on the stack just past the environment pointers. AFAIK, gdb doesn't already have a way to know this stack address. It's simple to record it in the kernel without significant new overhead, and have a way via either ptrace or /proc to get this address. I raise this suggestion because it may be most acceptable to the Linux kernel folks to add something with so little kernel work involved. The problem with this is that the program might have clobbered its stack. glibc doesn't ordinarily modify it, but a buggy program might clobber it by random accident, and any program is within its rights to reuse that part of the stack. It won't have done so at program startup, but if you attach to a live process that has clobbered this part of its stack then you won't find the vsyscall info so as to unwind from those PCs properly. I am curious what gdb hackers' opinions on this danger are. * Add a way to get the original contents of the aux vector, like /proc/PID/auxv on Solaris. That could be /proc/PID/auxv, or new ptrace requests that act like the old PIOCNAUXV and PIOCAUXV. On Solaris, /proc/PID/auxv's contents are not affected by PID clobbering the auxv on its stack. In Linux, about half of the auxv entries are constants the kernel can easily fill in anew on the fly, but the other half are specific bits about the executable that are not easy to recover later from other saved information. Though AT_SYSINFO_EHDR is all we need, a general interface like this really should give the complete set that was given to the process. By far the simplest way to implement that is simply to save the array in the kernel. As the kernel code is now, I can do that without any additional copying overhead, but it does add at least 34 words to the process data structure, which Linux kernel people might well reject. Of these three options, this one is my preference on aesthetic grounds but I don't know whether it will happen on the kernel side. I have not been able to imagine any way to get this magic address (the vsyscall DSO loadbase) directly from the system that does not require a special backend call and therefore cause some kind of new headache for remote debugging. I don't know what people's thinking is on trying to translate this kind of thing across the remote protocol. There is also the option to punt trying to find it directly from the system, and rely on the dynamic linker's data structures to locate it. As mentioned above, I don't like relying on the inferior's data structures not being frotzed, nor relying on there being a normal dynamic linker to be able know about the vsyscall DSO. Furthermore, the normal dynamic linker report of l_addr is not helpful because that "loadbase" is the bias relative to the addresses in the DSO's phdrs, which is 0 for the vsyscall DSO since it is effectively prelinked. The only address directly available is l_ld, the address of its .dynamic section. There is no proper way from that to locate the phdrs or ELF file header, so it would have to be some kludge rounding down or searching back from there or something. The only thing favoring this approach is that it requires no new target interfaces and no new remote debugging complications. Relying on the dynamic linker's data structures certainly seems attractive to me as an additional method since it works independently of the remote protocol. To avoid kludging around one could: 1. Expose l_phdr in `struct link_map'. 2. Add a field to `struct r_debug'. 3. Add a dynamic tag. Since the vsyscall DSO is prelinked, I suppose this tag could be initailized correctly in the in-kernel image, and wouldn't need to be modified by the run-time dynamic linker. One could even consider abusing DT_DEBUG for this purpose. I think this question is pretty open, though not all that exciting. My inclination is to implement /proc/PID/auxv (with storage overhead) and see what the Linux kernel hackers' reaction to that is. They may suggest that it work by reading out of the process stack (which is what /proc/PID/cmdline and /proc/PID/environ do). I would like to know opinions from the gdb camp on how bad a thing to do that might be. Second choice is Well, a buffer overflow of a buffer allocated on the stack is a fairly common problem, and it is not unimaginable that it overwrites auxv. I think it is much more likely that this happens than unintentionally overwriting the dynamic linker data structures since IIRC those data structures are not allocated from the standard heap. ot make /proc/PID/maps list the vsyscall DSO mapping in a recognizable way; that is likely to go over well enough with the kernel hackers. I would be That would probably be better that reading /proc/PID/auxv out of the process stack. all for an entirely different solution that is both robust (not relying on the inferior's own fungible memory) and remote-friendly, if anyone thinks of one. Mark ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb support for Linux vsyscall DSO 2003-05-10 17:55 ` Mark Kettenis @ 2003-05-10 20:27 ` Roland McGrath 2003-05-11 23:14 ` Mark Kettenis 0 siblings, 1 reply; 43+ messages in thread From: Roland McGrath @ 2003-05-10 20:27 UTC (permalink / raw) To: Mark Kettenis; +Cc: gdb > No work has yet been done to convert GDB's ia64 target to make it use > the new frame unwinder framework. Andrew's idea was that it should be > possible to just hook the frame unwind methods into an existing > target, but that hasn't been tested yet. Ok. I am not going to worry about IA64 work per se for now. I mentioned it because the DSO issues are the same as the x86 case and so most of the work I've suggested can be machine-independent. > The run-time dynamic linker's data structures usually are intact, but > a fall-back mechanism wouldn't hurt I guess. The stack is usually intact too. ;-) It would not be the end of the world to rely on the dynamic linker's data structures. In practice, they are intact and people don't use the vsyscall entrypoint in statically linked programs. But I would rather consider *that* the fallback to be used in remote situations where the kernel inquiry mechanism isn't available. If there is a kernel inquiry mechanism, it will always be correct. If there are dynamic linker data structures at all, they might be bogus so you don't want to use them preferentially. > OK, as long as we try to keep the code as generic as possible and > isolate platform-specific hacks in platform-specific files. You know me. > Note that symbols from the vsyscall would be very helpful to the user. Surely. But lack thereof doesn't cripple the user the way failure to unwind the frame does, so it's not the highest priority. That's all I said. > There is also an issue with signal trampolines. GDB needs to be able > to recognize them in order to support stepping over functions when a > signal arrives. I don't think I know exactly what you mean here. Is there a special case for signal frames aside from just knowing how to unwind them properly? (The only other specialness I am aware of is "<signal handler called>", which with normal unwind info would show __kernel_sigreturn instead.) > I proposed Richard Henderson to add a special DWARF CFI augmentation to > mark __kernel_sigreturn and __kernel_rt_sigreturn as signal trampolines. > That would allow me to recognize them without knowing their names. The code I have seen looks at the instruction sequence to match the expected system call (using "int $0x80"). All extant Linux kernels still have those same exact instruction sequences (as libc's __restore and __restore_rt). So this will continue to work, ugly as it is. Not that we shouldn't address it more cleanly, but I don't think it's in fact breaking anything at this very moment. rth has added unwind info to the __kernel_{rt_,}sigreturn vsyscall code. These describe unwinding the signal frame to restore all the registers to the state that was interrupted by the signal (though not the processor flags word, I dunno if i386 DWARF2 format can do that--you'd only need that if you wanted to roll back the signal handling frame as if it had never happened at all, not just to unwind past it or examine the frame's state). > Ordinary shared libraries are cleared out in core_close() by > CLEAR_SOLIB(). This calls solib.c:clear_solib(), so I think you > should remove things in that codepath. Ok. > Relying on the dynamic linker's data structures certainly seems > attractive to me as an additional method since it works independently > of the remote protocol. Agreed. I was vaguely hoping that someone would have a brilliant idea that is both remote-friendly and as robust as the kernel-specific backend solutions, but I don't think there is one possible. > To avoid kludging around one could: These are the obvious suggestions. I am very hesitant to change the exposed structures; frankly, those two will probably never change again. The dynamic tag would be a convenient one, but would require an ld change and to be sure your kernel was built by a new enough ld; that is impractical. Exposing some way to get the l_phdr pointer is very reasonable. An idea that doesn't raise many of the issues of changing the public `struct link_map' layout is export an internal symbol giving offsetof (struct link_map, l_phdr). That is still sort of a kludge if you ask me. But it shouldn't cause many problems in practice. > to make /proc/PID/maps list the vsyscall DSO mapping in a recognizable way > > That would probably be better that reading /proc/PID/auxv out of the > process stack. Agreed. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb support for Linux vsyscall DSO 2003-05-10 20:27 ` Roland McGrath @ 2003-05-11 23:14 ` Mark Kettenis 2003-05-13 1:53 ` Roland McGrath 0 siblings, 1 reply; 43+ messages in thread From: Mark Kettenis @ 2003-05-11 23:14 UTC (permalink / raw) To: roland; +Cc: gdb Date: Sat, 10 May 2003 13:27:20 -0700 From: Roland McGrath <roland@redhat.com> > The run-time dynamic linker's data structures usually are intact, but > a fall-back mechanism wouldn't hurt I guess. The stack is usually intact too. ;-) It would not be the end of the world to rely on the dynamic linker's data structures. In practice, they are intact and people don't use the vsyscall entrypoint in statically linked programs. But I would rather consider *that* the fallback to be used in remote situations where the kernel inquiry mechanism isn't available. If there is a kernel inquiry mechanism, it will always be correct. If there are dynamic linker data structures at all, they might be bogus so you don't want to use them preferentially. Careless thinking of me; of course one should prefer the most reliable method. I fully agree with you here. > Note that symbols from the vsyscall would be very helpful to the user. Surely. But lack thereof doesn't cripple the user the way failure to unwind the frame does, so it's not the highest priority. That's all I said. > There is also an issue with signal trampolines. GDB needs to be able > to recognize them in order to support stepping over functions when a > signal arrives. I don't think I know exactly what you mean here. Is there a special case for signal frames aside from just knowing how to unwind them properly? (The only other specialness I am aware of is "<signal handler called>", which with normal unwind info would show __kernel_sigreturn instead.) There is some special handling for signal trampolines in infrun.c:handle_inferior_event(). Beware! Dragons can still be found in that function. However, it seems the bit of code I'm talking about is there for targets that don't known how to properly unwind signal frames :-). There is also the issue of unwinding interrupted frames vs. called frames, where we substract 1 from the return address to get an address in the middle of the call instruction that is in progress. But rth has taken care of that. > I proposed Richard Henderson to add a special DWARF CFI augmentation to > mark __kernel_sigreturn and __kernel_rt_sigreturn as signal trampolines. > That would allow me to recognize them without knowing their names. The code I have seen looks at the instruction sequence to match the expected system call (using "int $0x80"). All extant Linux kernels still have those same exact instruction sequences (as libc's __restore and __restore_rt). So this will continue to work, ugly as it is. Not that we shouldn't address it more cleanly, but I don't think it's in fact breaking anything at this very moment. rth has added unwind info to the __kernel_{rt_,}sigreturn vsyscall code. These describe unwinding the signal frame to restore all the registers to the state that was interrupted by the signal (though not the processor flags word, I dunno if i386 DWARF2 format can do that--you'd only need that if you wanted to roll back the signal handling frame as if it had never happened at all, not just to unwind past it or examine the frame's state). Restoring %eflags is certainly possible. Making GDB actually pop the signal trampoline frame should work, but could lead to "interesting" behaviour. I mean, the kernel will still think the program has taken a signal. Hmm, looking at both the FreeBSD and Linux kernels it seems as if only the signal mask might be incorrect. > Relying on the dynamic linker's data structures certainly seems > attractive to me as an additional method since it works independently > of the remote protocol. Agreed. I was vaguely hoping that someone would have a brilliant idea that is both remote-friendly and as robust as the kernel-specific backend solutions, but I don't think there is one possible. Well, for processes started by GDB we can read the auxiliary vector from the pristine stack, but that doesn't work for attached-to processes. > To avoid kludging around one could: These are the obvious suggestions. I am very hesitant to change the exposed structures; frankly, those two will probably never change again. The dynamic tag would be a convenient one, but would require an ld change and to be sure your kernel was built by a new enough ld; that is impractical. Well, extending the structure shouldn't pose a problem, although there is some risk. The origional link.h contained the following comment: /* Structure describing... ... This data structure might change in future, if necessary. User-level programs must avoid defining objects of this type. */ But those last two sentences have been removed from the link.h that's actually installed. Exposing some way to get the l_phdr pointer is very reasonable. An idea that doesn't raise many of the issues of changing the public `struct link_map' layout is export an internal symbol giving offsetof (struct link_map, l_phdr). That is still sort of a kludge if you ask me. But it shouldn't cause many problems in practice. Given that we know where the dynamic section is from l_ld, I think we can figure out all we need to know from there. I used the linker script from Linux 2.5.69 to generate a vsyscall-int80.so, and I'm seeing the location of all relevant sections in the symbol table. Is it possible to re-order the sections such that .dynamic comes a bit earlier than now? In that case (l_ld & 0xfffff000) would almost certainly be the address of the ELF header. Mark ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb support for Linux vsyscall DSO 2003-05-11 23:14 ` Mark Kettenis @ 2003-05-13 1:53 ` Roland McGrath 2003-05-15 21:26 ` Mark Kettenis 0 siblings, 1 reply; 43+ messages in thread From: Roland McGrath @ 2003-05-13 1:53 UTC (permalink / raw) To: Mark Kettenis; +Cc: gdb > There is some special handling for signal trampolines in > infrun.c:handle_inferior_event(). Beware! Dragons can still be found > in that function. However, it seems the bit of code I'm talking about > is there for targets that don't known how to properly unwind signal > frames :-). I only partly follow the code in that function, but it does look like it wants to know whether it's in a signal frame. I get the impression that "next" or "step" interrupted by a signal lets the signal be handled and continues until the end of the source line rather than doing a normal user stop for the signal, and that this is considered desireable. So it must know. Having a DWARF2 extension to mark signal frames seems reasonable, and less kludgey than matching symbol names. However, I wonder if there is in fact a way to do it that won't confuse older libgcc's .eh_frame unwinding code. > Restoring %eflags is certainly possible. Making GDB actually pop the > signal trampoline frame should work I only mentioned %eflags to pedantic because I caught myself about to say "restore the exact state of the interrupted thread" and that wasn't completely true. I don't anticipate gdb having any reason to want to roll back a signal frame. (However, in the abstract it seems like the right thing for the kernel unwind info to describe restoring %eflags if the DWARF2 format can already represent that.) > Well, for processes started by GDB we can read the auxiliary vector from > the pristine stack, but that doesn't work for attached-to processes. Good point. I am inclined to think this is worth doing because, for the case it covers, it is both fully robust and fully remote-friendly even with old existing remote stubs, and is easy enough to implement on a per-target basis. If a direct inquiry is available, that will still be quicker than the straightforward but numerous inferior memory reads that must be done to extract the information from the stack, and so is the first choice; if it's available for remote too, all the better. But I think I will implement this fallback at least for i386, just because it's a 100% correct solution for at least half the cases (i.e. run but not attach) that can work today without waiting for the a new kernel feature and/or remote stub upgrades to be installed. > Given that we know where the dynamic section is from l_ld, I think we > can figure out all we need to know from there. As a special case for the Linux vsyscall DSO, it would be adequate just to presume it will fit in a single page and round down. But you've reminded me that there are other useful addresses to be found by looking in the .dynamic section itself. DT_HASH gives the location of the .hash section, which a normal ld -shared always puts as the first section in the file, appearing right after the file and program headers. Without relying on .hash being first per se, you can reasonably assume that the sections referenced by DT_* are the first group in the file and so start with the lowest of those addresses. Rounding that address down to the smallest of any actual ELF platform's page size (which might be 4k?) is a pretty darn reasonable guess for finding the ELF header of any mapped DSO. Thanks much for all the helpful feedback, Roland ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb support for Linux vsyscall DSO 2003-05-13 1:53 ` Roland McGrath @ 2003-05-15 21:26 ` Mark Kettenis 2003-05-16 2:25 ` Roland McGrath 0 siblings, 1 reply; 43+ messages in thread From: Mark Kettenis @ 2003-05-15 21:26 UTC (permalink / raw) To: roland; +Cc: gdb Date: Mon, 12 May 2003 18:53:16 -0700 From: Roland McGrath <roland@redhat.com> > There is some special handling for signal trampolines in > infrun.c:handle_inferior_event(). Beware! Dragons can still be found > in that function. However, it seems the bit of code I'm talking about > is there for targets that don't known how to properly unwind signal > frames :-). I only partly follow the code in that function, but it does look like it wants to know whether it's in a signal frame. I get the impression that "next" or "step" interrupted by a signal lets the signal be handled and continues until the end of the source line rather than doing a normal user stop for the signal, and that this is considered desireable. So it must know. I'm not really sure. The code I referred to seems to be written for BSD-style signal trampolines, where the signal trampoline will call the signal handler. The Linux kernel calls the signal trampoline directly, so perhaps it doesn't need this code. Having a DWARF2 extension to mark signal frames seems reasonable, and less kludgey than matching symbol names. However, I wonder if there is in fact a way to do it that won't confuse older libgcc's .eh_frame unwinding code. If the `z' augmentation doesn't confuse older libgcc's, I don't see why adding another augmentation would do so. But we should first determine if we really need it before adding it. > Restoring %eflags is certainly possible. Making GDB actually pop the > signal trampoline frame should work I only mentioned %eflags to pedantic because I caught myself about to say "restore the exact state of the interrupted thread" and that wasn't completely true. I don't anticipate gdb having any reason to want to roll back a signal frame. (However, in the abstract it seems like the right thing for the kernel unwind info to describe restoring %eflags if the DWARF2 format can already represent that.) Well, GDB will do exactly that when the user gives the "return" command in a signal trampoline. Mark ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: gdb support for Linux vsyscall DSO 2003-05-15 21:26 ` Mark Kettenis @ 2003-05-16 2:25 ` Roland McGrath 0 siblings, 0 replies; 43+ messages in thread From: Roland McGrath @ 2003-05-16 2:25 UTC (permalink / raw) To: Mark Kettenis; +Cc: gdb > I'm not really sure. The code I referred to seems to be written for > BSD-style signal trampolines, where the signal trampoline will call > the signal handler. The Linux kernel calls the signal trampoline > directly, so perhaps it doesn't need this code. I assume you meant "calls the signal handler directly" here. I don't know off hand what other systems do. Linux does point the PC directly at the signal handler, but the return address on its stack is the sigreturn code. So once the handler function is entered, the register and stack state looks like that code was the caller. > If the `z' augmentation doesn't confuse older libgcc's, I don't see > why adding another augmentation would do so. But we should first > determine if we really need it before adding it. Oh, I see. It hadn't occurred to me you meant an augmentation addition, and I was thinking of new opcodes or something like that. > Well, GDB will do exactly that when the user gives the "return" > command in a signal trampoline. Does that need to work? Does it really work now? (Using "return" in a signal handler function should work fine, and that is what seems like it would matter.) ^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2003-05-16 2:25 UTC | newest] Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-05-09 9:45 gdb/dwarf-frame.c Roland McGrath 2003-05-09 13:41 ` gdb/dwarf-frame.c Daniel Jacobowitz 2003-05-09 14:10 ` gdb/dwarf-frame.c Elena Zannoni 2003-05-09 14:56 ` NPTL thread support H. J. Lu 2003-05-09 15:44 ` Elena Zannoni [not found] ` <20030509091522.A2960@lucon.org> [not found] ` <16059.55278.841645.134311@localhost.redhat.com> 2003-05-11 20:46 ` H. J. Lu 2003-05-12 19:24 ` J. Johnston 2003-05-12 20:08 ` H. J. Lu 2003-05-12 20:15 ` David Carlton 2003-05-12 21:09 ` Andrew Cagney 2003-05-12 21:18 ` David Carlton 2003-05-12 21:23 ` Daniel Jacobowitz 2003-05-12 20:17 ` Elena Zannoni 2003-05-09 17:01 ` gdb/dwarf-frame.c Andrew Cagney 2003-05-09 17:08 ` gdb/dwarf-frame.c Elena Zannoni 2003-05-09 19:43 ` gdb/dwarf-frame.c Mark Kettenis 2003-05-09 21:19 ` gdb/dwarf-frame.c Roland McGrath 2003-05-09 21:48 ` gdb/dwarf-frame.c Elena Zannoni 2003-05-09 22:17 ` gdb/dwarf-frame.c Roland McGrath 2003-05-09 21:54 ` gdb/dwarf-frame.c Andrew Cagney 2003-05-09 21:58 ` gdb/dwarf-frame.c Daniel Jacobowitz 2003-05-09 22:18 ` gdb/dwarf-frame.c Roland McGrath 2003-05-09 22:28 ` gdb/dwarf-frame.c Andrew Cagney 2003-05-09 22:33 ` gdb/dwarf-frame.c Roland McGrath 2003-05-09 20:32 ` gdb/dwarf-frame.c Roland McGrath 2003-05-09 19:36 ` gdb/dwarf-frame.c Mark Kettenis 2003-05-09 21:34 ` gdb/dwarf-frame.c Roland McGrath 2003-05-09 21:46 ` gdb/dwarf-frame.c Elena Zannoni 2003-05-10 7:07 ` gdb support for Linux vsyscall DSO Roland McGrath 2003-05-10 17:24 ` Andrew Cagney 2003-05-10 18:13 ` Daniel Jacobowitz 2003-05-10 19:42 ` Roland McGrath 2003-05-10 21:49 ` Andrew Cagney 2003-05-12 19:23 ` Andrew Cagney 2003-05-13 2:29 ` Roland McGrath 2003-05-13 16:03 ` Andrew Cagney 2003-05-10 21:28 ` Roland McGrath 2003-05-10 17:55 ` Mark Kettenis 2003-05-10 20:27 ` Roland McGrath 2003-05-11 23:14 ` Mark Kettenis 2003-05-13 1:53 ` Roland McGrath 2003-05-15 21:26 ` Mark Kettenis 2003-05-16 2:25 ` Roland McGrath
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).