Message ID | 5347321E.2060802@redhat.com |
---|---|
State | Committed |
Headers |
Return-Path: <x14307373@homiemail-mx20.g.dreamhost.com> X-Original-To: siddhesh@wilcox.dreamhost.com Delivered-To: siddhesh@wilcox.dreamhost.com Received: from homiemail-mx20.g.dreamhost.com (mx2.sub5.homie.mail.dreamhost.com [208.113.200.128]) by wilcox.dreamhost.com (Postfix) with ESMTP id 2D63336007A for <siddhesh@wilcox.dreamhost.com>; Thu, 10 Apr 2014 17:07:06 -0700 (PDT) Received: by homiemail-mx20.g.dreamhost.com (Postfix, from userid 14307373) id E282840DCDB7D; Thu, 10 Apr 2014 17:07:05 -0700 (PDT) X-Original-To: glibc@patchwork.siddhesh.in Delivered-To: x14307373@homiemail-mx20.g.dreamhost.com Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by homiemail-mx20.g.dreamhost.com (Postfix) with ESMTPS id AC1B540DCDB7D for <glibc@patchwork.siddhesh.in>; Thu, 10 Apr 2014 17:07:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:cc :subject:content-type:content-transfer-encoding; q=dns; s= default; b=B1sAdUt3DwXYkpxLu+Y8MJMpGtvT8xaNLBV4gMIFZ+WmrbDmwQ69z DAPeixdqE7PmxAMogljQ07QgzsHgN4yWa20BTKS/N0tIEAg5T1GMVHpfcWZLzjeh hCK0i7sUuAofLYEU6HELYSt9VO///qlhyg1bEcgKTaSaaIV1ZDjxSE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:cc :subject:content-type:content-transfer-encoding; s=default; bh=P O3PKmaN7tKDrv2Hm7mSSKeXKuo=; b=HzLV3rxkTvmp8mcAUfTP6I4lvgYPP3vRz diFuJXYsk9SB89G14kprGFIZQNRmjd+ITUooymtE+geTx/vNmwge2nFSRlz51al7 0oklPC7tUwlhxUU2A48ofHwNkGV3z0dlg9+/vtFAju5X9mlghcotwOjxcAZsfIDO vOH+NKdJaQ= Received: (qmail 22597 invoked by alias); 11 Apr 2014 00:07:03 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-glibc=patchwork.siddhesh.in@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 22579 invoked by uid 89); 11 Apr 2014 00:07:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Message-ID: <5347321E.2060802@redhat.com> Date: Thu, 10 Apr 2014 20:06:54 -0400 From: "Carlos O'Donell" <carlos@redhat.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: GNU C Library <libc-alpha@sourceware.org> CC: Jan Kratochvil <jan.kratochvil@redhat.com>, "Maciej W. Rozycki" <macro@codesourcery.com>, Roland McGrath <roland@hack.frob.com> Subject: [PATCH] Initialize _r_debug for static applications. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DH-Original-To: glibc@patchwork.siddhesh.in |
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
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;