* Question about _dl_debug_state and new glibc @ 2004-10-11 18:54 Randolph Chung 2004-10-11 19:03 ` Kevin Buettner 0 siblings, 1 reply; 6+ messages in thread From: Randolph Chung @ 2004-10-11 18:54 UTC (permalink / raw) To: gdb Hi all, I've been away from gdb for a bit, so hopefully this is not something simple I missed while I've been away :) It appears that newer versions of glibc now marks the _dl_debug_state function as hidden, making it not visible to gdb. This breaks the solib tracking code in solib-svr4.c..... Looking at the docs, it looks like the "proper" way for gdb to do this is to look up the r_debug symbol and use the r_brk member to locate _dl_debug_state's address. is there any particular reason why we don't do this in gdb? randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question about _dl_debug_state and new glibc 2004-10-11 18:54 Question about _dl_debug_state and new glibc Randolph Chung @ 2004-10-11 19:03 ` Kevin Buettner 2004-10-11 19:14 ` Daniel Jacobowitz 0 siblings, 1 reply; 6+ messages in thread From: Kevin Buettner @ 2004-10-11 19:03 UTC (permalink / raw) To: Randolph Chung; +Cc: gdb On Mon, 11 Oct 2004 10:22:07 -0700 Randolph Chung <randolph@tausq.org> wrote: > I've been away from gdb for a bit, so hopefully this is not something > simple I missed while I've been away :) > > It appears that newer versions of glibc now marks the _dl_debug_state > function as hidden, making it not visible to gdb. This breaks the > solib tracking code in solib-svr4.c..... > > Looking at the docs, it looks like the "proper" way for gdb to do this > is to look up the r_debug symbol and use the r_brk member to locate > _dl_debug_state's address. is there any particular reason why we don't > do this in gdb? I can't think of any reason. I'm guessing that it was more expedient for the original authors of the code to do it the way it was done. In any case, I know of no reason not to change it so that it's done "properly". Patches are welcome... Kevin ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question about _dl_debug_state and new glibc 2004-10-11 19:03 ` Kevin Buettner @ 2004-10-11 19:14 ` Daniel Jacobowitz 2004-10-11 20:47 ` Mark Kettenis 2004-10-11 22:00 ` Kevin Buettner 0 siblings, 2 replies; 6+ messages in thread From: Daniel Jacobowitz @ 2004-10-11 19:14 UTC (permalink / raw) To: Kevin Buettner; +Cc: Randolph Chung, gdb On Mon, Oct 11, 2004 at 10:46:47AM -0700, Kevin Buettner wrote: > On Mon, 11 Oct 2004 10:22:07 -0700 > Randolph Chung <randolph@tausq.org> wrote: > > > I've been away from gdb for a bit, so hopefully this is not something > > simple I missed while I've been away :) > > > > It appears that newer versions of glibc now marks the _dl_debug_state > > function as hidden, making it not visible to gdb. This breaks the > > solib tracking code in solib-svr4.c..... > > > > Looking at the docs, it looks like the "proper" way for gdb to do this > > is to look up the r_debug symbol and use the r_brk member to locate > > _dl_debug_state's address. is there any particular reason why we don't > > do this in gdb? Only for static executables usually; for dynamic executables it's supposed to be DT_DEBUG if that's available. Same difference. > I can't think of any reason. I'm guessing that it was more expedient > for the original authors of the code to do it the way it was done. > In any case, I know of no reason not to change it so that it's done > "properly". We set the breakpoint on _dl_debug_state before starting the inferior. _dl_debug_initialize initializes _r_debug somewhat later... I'm not sure how it is supposed to be used. Do either of you know? I see it hasn't been exported since March. Blech. -- Daniel Jacobowitz ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question about _dl_debug_state and new glibc 2004-10-11 19:14 ` Daniel Jacobowitz @ 2004-10-11 20:47 ` Mark Kettenis 2004-10-12 6:57 ` Daniel Jacobowitz 2004-10-11 22:00 ` Kevin Buettner 1 sibling, 1 reply; 6+ messages in thread From: Mark Kettenis @ 2004-10-11 20:47 UTC (permalink / raw) To: drow; +Cc: kevinb, randolph, gdb, libc-alpha Date: Mon, 11 Oct 2004 13:55:25 -0400 From: Daniel Jacobowitz <drow@false.org> On Mon, Oct 11, 2004 at 10:46:47AM -0700, Kevin Buettner wrote: > On Mon, 11 Oct 2004 10:22:07 -0700 > Randolph Chung <randolph@tausq.org> wrote: > > > I've been away from gdb for a bit, so hopefully this is not something > > simple I missed while I've been away :) > > > > It appears that newer versions of glibc now marks the _dl_debug_state > > function as hidden, making it not visible to gdb. This breaks the > > solib tracking code in solib-svr4.c..... > > > > Looking at the docs, it looks like the "proper" way for gdb to do this > > is to look up the r_debug symbol and use the r_brk member to locate > > _dl_debug_state's address. is there any particular reason why we don't > > do this in gdb? Only for static executables usually; for dynamic executables it's supposed to be DT_DEBUG if that's available. Same difference. Hey wake up Daniel. Static executables don't have shared libraries. > I can't think of any reason. I'm guessing that it was more expedient > for the original authors of the code to do it the way it was done. > In any case, I know of no reason not to change it so that it's done > "properly". We set the breakpoint on _dl_debug_state before starting the inferior. _dl_debug_initialize initializes _r_debug somewhat later... I'm not sure how it is supposed to be used. Do either of you know? The problem is that even DT_DEBUG isn't initialized before initialization of the dynamic linker. Theoretically, we could put a watchpoint on DT_DEBUG, and lookup r_brk if it triggers. However, I don't think that's very practical on platforms without hardware watchpoint support. I suppose this is just something that has never been completely implemented. Somehow I think the dynamic linker was supposed to trap just after initializing r_debug and setting DT_DEBUG if it was being traced, perhaps if it noticed that DT_DEBUG was set to some special value by the debugger. Perhaps we'll know when "Open Solaris" is released. I see it hasn't been exported since March. Blech. So we should ask the glibc developers to unhide _dl_debug_state. Mark ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question about _dl_debug_state and new glibc 2004-10-11 20:47 ` Mark Kettenis @ 2004-10-12 6:57 ` Daniel Jacobowitz 0 siblings, 0 replies; 6+ messages in thread From: Daniel Jacobowitz @ 2004-10-12 6:57 UTC (permalink / raw) To: Mark Kettenis; +Cc: kevinb, randolph, gdb, libc-alpha On Mon, Oct 11, 2004 at 09:13:41PM +0200, Mark Kettenis wrote: > Date: Mon, 11 Oct 2004 13:55:25 -0400 > From: Daniel Jacobowitz <drow@false.org> > > On Mon, Oct 11, 2004 at 10:46:47AM -0700, Kevin Buettner wrote: > > On Mon, 11 Oct 2004 10:22:07 -0700 > > Randolph Chung <randolph@tausq.org> wrote: > > > > > I've been away from gdb for a bit, so hopefully this is not something > > > simple I missed while I've been away :) > > > > > > It appears that newer versions of glibc now marks the _dl_debug_state > > > function as hidden, making it not visible to gdb. This breaks the > > > solib tracking code in solib-svr4.c..... > > > > > > Looking at the docs, it looks like the "proper" way for gdb to do this > > > is to look up the r_debug symbol and use the r_brk member to locate > > > _dl_debug_state's address. is there any particular reason why we don't > > > do this in gdb? > > Only for static executables usually; for dynamic executables it's > supposed to be DT_DEBUG if that's available. Same difference. > > Hey wake up Daniel. Static executables don't have shared libraries. Oddly enough, in glibc they can - and often do. There's a static version of the runtime linker included, and things like dlopen work - and internal libc functionality like NSS (gethostname, etc.) and gconv use it. Also, there are architectures where DT_DEBUG is missing. I think MIPS may be one. Or maybe I'm misremembering this bit. > I suppose this is just something that has never been completely > implemented. Somehow I think the dynamic linker was supposed to trap > just after initializing r_debug and setting DT_DEBUG if it was being > traced, perhaps if it noticed that DT_DEBUG was set to some special > value by the debugger. Perhaps we'll know when "Open Solaris" is > released. Makes sense to me. Do any of the BSDs support using r_debug this way, or do they export _dl_debug_state also? > I see it hasn't been exported since March. Blech. > > So we should ask the glibc developers to unhide _dl_debug_state. I agree. -- Daniel Jacobowitz ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question about _dl_debug_state and new glibc 2004-10-11 19:14 ` Daniel Jacobowitz 2004-10-11 20:47 ` Mark Kettenis @ 2004-10-11 22:00 ` Kevin Buettner 1 sibling, 0 replies; 6+ messages in thread From: Kevin Buettner @ 2004-10-11 22:00 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Randolph Chung, gdb On Mon, 11 Oct 2004 13:55:25 -0400 Daniel Jacobowitz <drow@false.org> wrote: > On Mon, Oct 11, 2004 at 10:46:47AM -0700, Kevin Buettner wrote: > > > I can't think of any reason. I'm guessing that it was more expedient > > for the original authors of the code to do it the way it was done. > > In any case, I know of no reason not to change it so that it's done > > "properly". > > We set the breakpoint on _dl_debug_state before starting the inferior. > _dl_debug_initialize initializes _r_debug somewhat later... I'm not > sure how it is supposed to be used. Do either of you know? Ah! Perhaps that's the reason why _dl_debug_state was used directly. I ran into this problem when I wrote the FR-V's solib code. (Due to the fact that text and data are independetly relocated, the code in solib-svr4.c couldn't be used.) The symbol in question was not exported and could only be accessed from the r_debug struct. But as you say, it's value wasn't immediately available. So, we set the solib event breakpoint on the executable's entry point (probably _start). Once this breakpoint was hit, the data structures in question had been initialized, and so we reset it to the address determined by examining the r_debug struct. I suspect that a similar strategy could be used for solib-svr4.c. Kevin ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-10-11 19:21 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-10-11 18:54 Question about _dl_debug_state and new glibc Randolph Chung 2004-10-11 19:03 ` Kevin Buettner 2004-10-11 19:14 ` Daniel Jacobowitz 2004-10-11 20:47 ` Mark Kettenis 2004-10-12 6:57 ` Daniel Jacobowitz 2004-10-11 22:00 ` Kevin Buettner
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).