Initialize _r_debug for static applications.

Message ID 5347321E.2060802@redhat.com
State Committed
Headers

Commit Message

Carlos O'Donell April 11, 2014, 12:06 a.m. UTC
  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>
 
	* csu/libc-start.c (LIBC_START_MAIN) [!SHARED]: Call
	_dl_debug_initialize.

---

Cheers,
Carlos.
  

Comments

Carlos O'Donell April 11, 2014, 12:33 a.m. UTC | #1
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.
  
Carlos O'Donell April 14, 2014, 8:05 p.m. UTC | #2
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.
  

Patch

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;