| Message ID | 5347321E.2060802@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 04/10/2014 08:06 PM, Carlos O'Donell wrote: > With Maciej's great work on reducing the difference between > static and dyanmic executables, and with the addition of > a functional main link map in static exectuables we can now > usefully initialize _r_debug for static applications. This > will allow future debuggers the ability to coalesce code > paths which previously had to have special cases for static > v.s. dyanmic. > > It also fixes this particular use case where gdb would like > a consistent way to find the application link map for looking > up TLS variables in both static and dynamic applications: > https://www.sourceware.org/ml/libc-help/2014-03/msg00024.html > > The discussion touches on the fact that without _r_debug the > debugger has to make various assupmtions while using > libthread_db that contrains the implementation. > > This patch initializes the debug infrastructure during > LIBC_START_MAIN, but only for static applications, by > calling `_dl_debug_initialize (0, LM_ID_BASE)'. We pass 0 as > the ldbase because it's a static application, and the runtime > address of the loader doesn't matter. We pass LM_ID_BASE because > we want to load, by default, the base link map, and that's what > really matters. > > Tested on x86_64 with no regressions. > > Jan reports this works and that gdb can be patched to use > _r_debug to access TLS variables in static applications > while still using the current libthread_db calls normally > used for dynamic applications. > > This removes one more difference between static and dynamic > applications. > > Note: This does not attempt to cleanup the -Wundef warning > for SHARED, which I am looking to fix in another patch so > we still use `#ifndef SHARED' (Makeconfig needs to be fixed > to use -DSHARED=0 and -DSHARED=1 IMO to make this work correctly). > > OK to checkin? > > Cheers, > Carlos. > > 2014-04-10 Carlos O'Donell <carlos@redhat.com> > [BZ #16831] > * csu/libc-start.c (LIBC_START_MAIN) [!SHARED]: Call > _dl_debug_initialize. Filed 16831 for user visible change to _r_debug interface. https://sourceware.org/bugzilla/show_bug.cgi?id=16831 Cheers, Carlos.
On 04/10/2014 08:33 PM, Carlos O'Donell wrote: > On 04/10/2014 08:06 PM, Carlos O'Donell wrote: >> With Maciej's great work on reducing the difference between >> static and dyanmic executables, and with the addition of >> a functional main link map in static exectuables we can now >> usefully initialize _r_debug for static applications. This >> will allow future debuggers the ability to coalesce code >> paths which previously had to have special cases for static >> v.s. dyanmic. >> >> It also fixes this particular use case where gdb would like >> a consistent way to find the application link map for looking >> up TLS variables in both static and dynamic applications: >> https://www.sourceware.org/ml/libc-help/2014-03/msg00024.html >> >> The discussion touches on the fact that without _r_debug the >> debugger has to make various assupmtions while using >> libthread_db that contrains the implementation. >> >> This patch initializes the debug infrastructure during >> LIBC_START_MAIN, but only for static applications, by >> calling `_dl_debug_initialize (0, LM_ID_BASE)'. We pass 0 as >> the ldbase because it's a static application, and the runtime >> address of the loader doesn't matter. We pass LM_ID_BASE because >> we want to load, by default, the base link map, and that's what >> really matters. >> >> Tested on x86_64 with no regressions. >> >> Jan reports this works and that gdb can be patched to use >> _r_debug to access TLS variables in static applications >> while still using the current libthread_db calls normally >> used for dynamic applications. >> >> This removes one more difference between static and dynamic >> applications. >> >> Note: This does not attempt to cleanup the -Wundef warning >> for SHARED, which I am looking to fix in another patch so >> we still use `#ifndef SHARED' (Makeconfig needs to be fixed >> to use -DSHARED=0 and -DSHARED=1 IMO to make this work correctly). >> >> OK to checkin? >> >> Cheers, >> Carlos. >> >> 2014-04-10 Carlos O'Donell <carlos@redhat.com> >> > [BZ #16831] >> * csu/libc-start.c (LIBC_START_MAIN) [!SHARED]: Call >> _dl_debug_initialize. > > Filed 16831 for user visible change to _r_debug interface. > > https://sourceware.org/bugzilla/show_bug.cgi?id=16831 Given that this only makes static binaries "better" I've gone ahead and checked in. commit 650362caaddf8109b47522c1113e2acbb881f693 Author: Carlos O'Donell <carlos@redhat.com> Date: Fri Apr 11 12:43:58 2014 -0400 Support _r_debug for static binaries. We initialize _r_debug for static binaries to allows debug agents to treat static binaries a little more like dyanmic ones. This simplifies the work a debug agent has to do to access TLS in a static binary via libthread_db. Tested on x86_64. See: https://sourceware.org/ml/libc-alpha/2014-04/msg00183.html [BZ #16831] * csu/libc-start.c (LIBC_START_MAIN) [!SHARED]: Call _dl_debug_initialize. Cheers, Carlos.
diff --git a/csu/libc-start.c b/csu/libc-start.c index 3b7092b..d571a1a 100644 --- a/csu/libc-start.c +++ b/csu/libc-start.c @@ -264,6 +264,9 @@ LIBC_START_MAIN (int (*main) (int, char **, char ** MAIN_AUXVEC_DECL), GLRO(dl_debug_printf) ("\ntransferring control: %s\n\n", argv[0]); #endif +#ifndef SHARED + _dl_debug_initialize (0, LM_ID_BASE); +#endif #ifdef HAVE_CLEANUP_JMP_BUF /* Memory for the cancellation buffer. */ struct pthread_unwind_buf unwind_buf;