From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5706 invoked by alias); 5 Dec 2010 19:47:51 -0000 Received: (qmail 5698 invoked by uid 22791); 5 Dec 2010 19:47:50 -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; Sun, 05 Dec 2010 19:47:45 +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 oB5JlQw9007525; Sun, 5 Dec 2010 20:47:26 +0100 (CET) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id oB5JlOMj023972; Sun, 5 Dec 2010 20:47:24 +0100 (CET) Date: Sun, 05 Dec 2010 19:47:00 -0000 Message-Id: <201012051947.oB5JlOMj023972@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: kevinb@redhat.com CC: gdb-patches@sourceware.org In-reply-to: <20101203140433.69c17fc4@mesquite.lan> (message from Kevin Buettner on Fri, 3 Dec 2010 14:04:33 -0700) Subject: Re: [RFC] Limit attempts to place breakpoints on _start, __start, and main in solib-svr4.c References: <20101129160233.1265d555@mesquite.lan> <20101130000707.GA26969@host0.dyn.jankratochvil.net> <20101130180618.66003c99@mesquite.lan> <20101201230339.GA8453@host0.dyn.jankratochvil.net> <20101203140433.69c17fc4@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-12/txt/msg00038.txt.bz2 > Date: Fri, 3 Dec 2010 14:04:33 -0700 > From: Kevin Buettner > > On Thu, 2 Dec 2010 00:03:39 +0100 > Jan Kratochvil wrote: > > 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? Makes sense to me. > * solib-svr4.c (enable_break): Don't attempt to place breakpoints, > when attaching, on the names in bkpt_names: _start, __start, and > main.