From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29778 invoked by alias); 8 Jun 2012 12:10:20 -0000 Received: (qmail 29750 invoked by uid 22791); 8 Jun 2012 12:10:15 -0000 X-SWARE-Spam-Status: No, hits=-7.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 08 Jun 2012 12:09:56 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q58C9oZU016553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jun 2012 08:09:50 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q58C9mec005996; Fri, 8 Jun 2012 08:09:49 -0400 Message-ID: <4FD1EB8C.1050407@redhat.com> Date: Fri, 08 Jun 2012 12:10:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Jan Kratochvil , Joakim Tjernlund , gdb-patches@sourceware.org Subject: Re: [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot References: <1338562868-22411-1-git-send-email-Joakim.Tjernlund@transmode.se> <4FC8EC08.1060609@redhat.com> <20120601172214.GA21236@host2.jankratochvil.net> <4FC8FDD2.7060407@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-06/txt/msg00224.txt.bz2 On 06/07/2012 12:59 AM, Maciej W. Rozycki wrote: > On Fri, 1 Jun 2012, Pedro Alves wrote: > >>>> --- a/gdb/solib-svr4.c >>>> +++ b/gdb/solib-svr4.c >>>> @@ -1707,7 +1707,7 @@ enable_break (struct svr4_info *info, int from_tty) >>>> } >>>> } >>>> >>>> - if (!current_inferior ()->attach_flag) >>>> + if (interp_name != NULL && !current_inferior ()->attach_flag) >>>> { >>>> for (bkpt_namep = bkpt_names; *bkpt_namep != NULL; bkpt_namep++) >>>> { >>> >>> It has a regression in the case below. >>> >>> OTOH one has to strip _start to make it a regression as with _start GDB did not >>> catch startup libraries even before. >> >> >> Yeah, that's a really contrived example. You're relying on stopping at main, >> not when the DSO is really loaded (_dl_debug_state) to set the breakpoint. >> I can see _start not existing, with the entry point named something else, >> but if you strip your static binary to miss _dl_debug_state, you won't get >> main either. (and then static binaries that dlopen aren't something you'd >> want to do normally.) > > Not really that contrived, glibc itself will dlopen(3) any NSS modules > required even from static binaries (unless you configure the library in a > non-standard way, that is yet more horrible a case) and I reckon there are > real life examples that make use of that feature (and explicit provisions > in glibc to handle a static and a dynamic copy of libc code to be loaded > both at once; it matters for things like malloc(3) if nothing else). That's basically the same thing. With either that, or explicitly linking a program that calls dlopen with "-static -ldl", you end up with "_dl_debug_state" built into your binary, so the "_start" or "main" "fallbacks" are never triggered. If you strip your binary, GDB won't find "_dl_debug_state", but then it won't find "_start" nor "main" either! So it is a contrived example to strip "_dl_debug_state" and "_start" but not "main", because that's not something that is natural to do. > If this scenario cannot be handled as one would expect and in a clean > way, then perhaps we need to arrange for another shared-library event hook > in glibc to be exported from static dlopen(3) code (e.g. a special section > that won't ever be stripped unless tried really, really hard). "_dl_debug_state" ends up available on static links too, I don't see what is there to do. -- Pedro Alves