From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21557 invoked by alias); 3 Dec 2010 21:04:45 -0000 Received: (qmail 21543 invoked by uid 22791); 3 Dec 2010 21:04:43 -0000 X-SWARE-Spam-Status: No, hits=-6.0 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,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, 03 Dec 2010 21:04:36 +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.13.8/8.13.8) with ESMTP id oB3L4Z3J030084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 3 Dec 2010 16:04:35 -0500 Received: from mesquite.lan ([10.3.113.8]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id oB3L4YGj008123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 3 Dec 2010 16:04:34 -0500 Date: Fri, 03 Dec 2010 21:04:00 -0000 From: Kevin Buettner To: gdb-patches@sourceware.org Subject: Re: [RFC] Limit attempts to place breakpoints on _start, __start, and main in solib-svr4.c Message-ID: <20101203140433.69c17fc4@mesquite.lan> In-Reply-To: <20101201230339.GA8453@host0.dyn.jankratochvil.net> References: <20101129160233.1265d555@mesquite.lan> <20101130000707.GA26969@host0.dyn.jankratochvil.net> <20101130180618.66003c99@mesquite.lan> <20101201230339.GA8453@host0.dyn.jankratochvil.net> 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-12/txt/msg00025.txt.bz2 On Thu, 2 Dec 2010 00:03:39 +0100 Jan Kratochvil wrote: > On Wed, 01 Dec 2010 02:06:18 +0100, Kevin Buettner wrote: > > My testing shows that use of `! current_inferior ()->attach_flag' as > > the test in enable_break() works when attaching to a process started > > natively. I also see the correct behavior (in which a breakpoint is > > placed on _start, et al) when the process is started via GDB's > > "run" command. > > > > The case that doesn't work - and, unfortunately, it's the case that > > really matters to me - is connecting to a remote target via "target > > remote". > > GNU gdb (GDB) 7.2.50.20101201-cvs > > killall -9 gdbserver;sleep 1h&p=$!;sleep 0.1;./gdbserver/gdbserver :1234 ./pause& ./gdb -nx -ex 'file ./pause' -ex 'target remote localhost:1234' > attach_flag=0 > - correct > > killall -9 gdbserver;./pause&p=$!;sleep 0.1;./gdbserver/gdbserver --attach :1234 $p& ./gdb -nx -ex 'file ./pause' -ex 'target remote localhost:1234' > attach_flag=1 > - correct > > killall -9 gdbserver;./pause&p=$!;sleep 0.1;./gdbserver/gdbserver --multi :1234& ./gdb -nx -ex 'file ./pause' -ex 'target extended-remote localhost:1234' -ex "attach $p" > attach_flag=1 > - correct > > Probably in the first case you do not want to place those breakpoints? > > But I think at least the "main" breakpoint is the one requested by Mark > Kettenis to stay there even in the case solib_break_names[] bpts fail: > http://sourceware.org/ml/gdb-patches/2010-09/msg00313.html Hi Jan, That's a nice demonstration of GDB's behavior when using gdbserver. My earlier testing and analysis was flawed. (FWIW, I was testing only case 1.) We do want to (potentially) attempt to place the breakpoints on _start, __start, and main in case 1, but not for case 2 and 3. You have demonstrated that the patch appended below will work correctly for gdbserver. I have used variants of your examples to verify that this is the case. (I have a hacked static executable in which I see a breakpoint placed on _start in case 1, but not for case 2 and 3 - which is as it should be.) The patch below won't necessarily work correctly with stubs which do not implement the qAttached packet. (gdbserver does implement qAttached.) My reading of remote.c indicates that stubs which do not implement "qAttached" will end up causing attach_flag to be 0. This may or may not be what we want depending upon the situation. It is certainly not what we want when connecting to a kernel stub (intended to debug a running kernel). On the other hand, there may be other stubs where this is in fact the correct answer. I'm going to recommend that my colleague (who pointed me at this problem a while ago) implement qAttached in his kernel stubs. I hereby withdraw my earlier patch in favor of the one below. Further comments? Kevin * solib-svr4.c (enable_break): Don't attempt to place breakpoints, when attaching, on the names in bkpt_names: _start, __start, and main. Index: solib-svr4.c =================================================================== RCS file: /cvs/src/src/gdb/solib-svr4.c,v retrieving revision 1.139 diff -u -p -r1.139 solib-svr4.c --- solib-svr4.c 11 Oct 2010 08:50:33 -0000 1.139 +++ solib-svr4.c 3 Dec 2010 20:30:35 -0000 @@ -1607,17 +1607,20 @@ enable_break (struct svr4_info *info, in } } - for (bkpt_namep = bkpt_names; *bkpt_namep != NULL; bkpt_namep++) + if (!current_inferior ()->attach_flag) { - msymbol = lookup_minimal_symbol (*bkpt_namep, NULL, symfile_objfile); - if ((msymbol != NULL) && (SYMBOL_VALUE_ADDRESS (msymbol) != 0)) + for (bkpt_namep = bkpt_names; *bkpt_namep != NULL; bkpt_namep++) { - sym_addr = SYMBOL_VALUE_ADDRESS (msymbol); - sym_addr = gdbarch_convert_from_func_ptr_addr (target_gdbarch, - sym_addr, - ¤t_target); - create_solib_event_breakpoint (target_gdbarch, sym_addr); - return 1; + msymbol = lookup_minimal_symbol (*bkpt_namep, NULL, symfile_objfile); + if ((msymbol != NULL) && (SYMBOL_VALUE_ADDRESS (msymbol) != 0)) + { + sym_addr = SYMBOL_VALUE_ADDRESS (msymbol); + sym_addr = gdbarch_convert_from_func_ptr_addr (target_gdbarch, + sym_addr, + ¤t_target); + create_solib_event_breakpoint (target_gdbarch, sym_addr); + return 1; + } } } return 0;