From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18826 invoked by alias); 1 Jun 2012 18:19:53 -0000 Received: (qmail 18816 invoked by uid 22791); 1 Jun 2012 18:19:52 -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, 01 Jun 2012 18:19:32 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q51IJVTR029504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Jun 2012 14:19:32 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q51IJTR7006241; Fri, 1 Jun 2012 14:19:30 -0400 Message-ID: <4FC907B1.2090805@redhat.com> Date: Fri, 01 Jun 2012 18:19: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: Jan Kratochvil CC: 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> <20120601174527.GA968@host2.jankratochvil.net> In-Reply-To: <20120601174527.GA968@host2.jankratochvil.net> 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/msg00031.txt.bz2 On 06/01/2012 06:45 PM, Jan Kratochvil wrote: > On Fri, 01 Jun 2012 19:37:22 +0200, Pedro Alves wrote: >> > 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.) > I do not have to strip the binary to not have _dl_debug_state, there are many > libc implementations out there and I guess they are not all compatible with > the "_dl_debug_state" naming. The fix for those would be to either list the name in GDB, or fix the loaded to use the same name as GDB already knows. I think the fallback must be for something else. > I guess this is also the reason why GDB knows > so many names for it: > "r_debug_state", > "_r_debug_state", > "_dl_debug_state", > "rtld_db_dlactivity", > "__dl_rtld_db_dlactivity", > "_rtld_debug_state", > And the goal of this non-ld.so breakpoint is that most of programs loads > libraries only during its init, before main, therefore a breakpoint at "main" > should catch them all. Looking a bit more, I don't think that's the original motivation. Instead, it looks more like the intent was to get to a point after the interpreter has mapped in the program, and therefore it is safe to install breakpoints in the main program. See solib-sunos.c (and remember that solib.c originally supported both svr4 and sunos): For SunOS executables, this first instruction is typically the one at "_start", or a similar text label, regardless of whether the executable is statically or dynamically linked. The runtime startup code takes care of dynamically linking in any shared libraries, once gdb allows the inferior to continue. So even for static binaries, you still need to place a breakpoint at _start and run to it, in order to see the main program mapped in. And since programs might choose a different entry point name, "main" is chosen as fallback. Looking even further back, to gdb 4.6, we see: #else /* SVR4_SHARED_LIBS */ #ifdef BKPT_AT_MAIN struct minimal_symbol *msymbol; msymbol = lookup_minimal_symbol ("main", symfile_objfile); if ((msymbol != NULL) && (msymbol -> address != 0)) { breakpoint_addr = msymbol -> address; } else { return (0); } if (target_insert_breakpoint (breakpoint_addr, shadow_contents) != 0) { return (0); } #else /* !BKPT_AT_MAIN */ struct symtab_and_line sal; /* Read the debugger interface structure directly. */ read_memory (debug_base, (char *) &debug_copy, sizeof (debug_copy)); /* Set breakpoint at the debugger interface stub routine that will be called just prior to each mapping change and again after the mapping change is complete. Set up the (nonexistent) handler to deal with hitting these breakpoints. (FIXME). */ warning ("'%s': line %d: missing SVR4 support code", __FILE__, __LINE__); #endif /* BKPT_AT_MAIN */ So at that point (1992), SVR4 support was quite infant, and BKPT_AT_MAIN, is mutually exclusive with the other method, and looks quite like an easy fallback used because nothing else better had been written yet. Over the years, all the macros disappeared, and got converted into runtime fallbacks, and we ended up with what we have. > > OTOH as I said current GDB will place the breakpoint to _start first and it > will miss those libraries anyway. So it is not a regression. Right. So you're okay with the patch as is, right? > Also nowadays some 3rd party runtime probably more adapts to GDB than vice > verse. Certainly. -- Pedro Alves