From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17441 invoked by alias); 17 Sep 2010 23:40:25 -0000 Received: (qmail 17433 invoked by uid 22791); 17 Sep 2010 23:40:24 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,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, 17 Sep 2010 23:40:19 +0000 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o8HNeGhj021124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 17 Sep 2010 19:40:17 -0400 Received: from mesquite.lan ([10.3.113.3]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o8HNeFC6028539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 17 Sep 2010 19:40:16 -0400 Date: Sat, 18 Sep 2010 14:13:00 -0000 From: Kevin Buettner To: gdb-patches@sourceware.org Subject: Re: [RFC] solib-svr4.c: Never attempt to place breakpoints on _start, __start, or main Message-ID: <20100917164015.69011490@mesquite.lan> In-Reply-To: <201009170810.o8H8AITW028258@glazunov.sibelius.xs4all.nl> References: <20100916152334.7e4f1ee5@mesquite.lan> <201009170810.o8H8AITW028258@glazunov.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00326.txt.bz2 On Fri, 17 Sep 2010 10:10:18 +0200 (CEST) Mark Kettenis wrote: > > 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(). Okay. > 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? That sounds like a good idea. It's not sufficient though for debugging scenarios in which one attaches to a program that's already gone past start or main. Perhaps we should skip the attempt to place a breakpoint on _start, __start, and main when attaching? > 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? Yes, the same thing happens for static binaries. Here's "maint info breakpoints" when run on a static hello world program: (gdb) maint info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0x00000000004003f8 in main at hello.c:6 inf 1 breakpoint already hit 1 time -2 shlib events keep y 0x000000000043a200 <_dl_debug_state> inf 1 -4 exception master keep n 0x0000000000469960 <_Unwind_DebugHook> inf 1 We don't have a breakpoint on _start, __start, or main, but that's because _dl_debug_state was found first. (The code searches for that symbol and others like it first...) If I edit the binary and change _dl_debug_state to _dl_rebug_state, I can get a breakpoint set on _start: (gdb) maint info break Num Type Disp Enb Address What 1 breakpoint keep y 0x00000000004003f8 in main at hello.c:6 inf 1 breakpoint already hit 1 time -2 shlib events keep y 0x00000000004002e0 <_start> inf 1 breakpoint already hit 1 time -4 exception master keep n 0x0000000000469960 <_Unwind_DebugHook> inf 1 Kevin