From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12650 invoked by alias); 7 Jun 2012 00:00:11 -0000 Received: (qmail 12582 invoked by uid 22791); 7 Jun 2012 00:00:08 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 Jun 2012 23:59:54 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1ScQ8m-0007RV-ST from Maciej_Rozycki@mentor.com ; Wed, 06 Jun 2012 16:59:52 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jun 2012 16:59:22 -0700 Received: from [172.30.1.189] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Thu, 7 Jun 2012 00:59:50 +0100 Date: Thu, 07 Jun 2012 00:00:00 -0000 From: "Maciej W. Rozycki" To: Pedro Alves CC: Jan Kratochvil , Joakim Tjernlund , Subject: Re: [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot In-Reply-To: <4FC8FDD2.7060407@redhat.com> Message-ID: References: <1338562868-22411-1-git-send-email-Joakim.Tjernlund@transmode.se> <4FC8EC08.1060609@redhat.com> <20120601172214.GA21236@host2.jankratochvil.net> <4FC8FDD2.7060407@redhat.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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/msg00209.txt.bz2 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). 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). Of course as soon as one dynamic module has been loaded, then there'll be a copy of the dynamic linker most likely pulled in too with its own shared-library event hook (I think shared modules that have not been linked against libc.so have not been supported beyond libc 5 on glibc systems, i.e. from glibc 2.0 on; this may have to be double-checked though). Can't speak of other libc implementations. Maciej