From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15616 invoked by alias); 17 Sep 2010 08:10:48 -0000 Received: (qmail 15604 invoked by uid 22791); 17 Sep 2010 08:10:46 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 17 Sep 2010 08:10:41 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id o8H8AKNi018763; Fri, 17 Sep 2010 10:10:20 +0200 (CEST) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id o8H8AITW028258; Fri, 17 Sep 2010 10:10:18 +0200 (CEST) Date: Fri, 17 Sep 2010 12:29:00 -0000 Message-Id: <201009170810.o8H8AITW028258@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: kevinb@redhat.com CC: gdb-patches@sourceware.org In-reply-to: <20100916152334.7e4f1ee5@mesquite.lan> (message from Kevin Buettner on Thu, 16 Sep 2010 15:23:34 -0700) Subject: Re: [RFC] solib-svr4.c: Never attempt to place breakpoints on _start, __start, or main References: <20100916152334.7e4f1ee5@mesquite.lan> 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: 2010-09/txt/msg00316.txt.bz2 > Date: Thu, 16 Sep 2010 15:23:34 -0700 > From: Kevin Buettner > > I recently had a discussion with a colleague who, while debugging the > linux kernel using GDB, noticed that GDB is writing a breakpoint to > the _start address on every "step" and "continue". He had not placed > a breakpoint at that address, nor did he want that address being > written to in the event that the page containing that address had > been recycled and was now being used for other purposes. > > I have found some cruft in solib-svr4.c which is responsible for this > behavior -- well, I think it's cruft anyway. There's a bit of code at > the end of enable_break() which, in desperation, attempts to place a > breakpoint on one of _start, __start, or main, in that order only when > all earlier attempts to place a shared library event breakpoint have > failed. I have no doubt that there was probably some platform for > which this once worked and was perhaps even needed, probably back in > the days when GDB's SunOS and SVR4 shared library support was jumbled > together in one file. I suspect that it may have been needed for > SunOS support but was copied over to the SVR4 file in an abundance of > caution. I doubt that there's any recent SVR4-like platform which > requires this code. > > I've tested the patch below on Fedora 13 x86_64 (native) and do not > see any regressions. > > Comments? (I.e. does anyone know of a platform or a situation where > the code that I'm deleting is still needed?) Sorry, but I think that code is still useful. Over the years I've seen various cases where setting the breakpoint in the proper place failed: the magic ld.so breakpoint function was renamed, somebody stripped ld.so, GDB misinterpreted the debug information in ld.so. The code you're removing makes sure (or at least attempts too make sure) that you have a valid list of shared libraries as soon as you hit main(). Obviously it is pointless to keep removing and reinserting these breakpoints. Perhaps they should be disabled as soon as one of them has been hit? Also, I think it is pointless to insert these if the program you're debugging isn't using the dynamic linker. I'm a little bit suprised that the solib-svr4.c code is used at all when debugging the Linux kernel. Does the same thing happen for static binaries?