From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26203 invoked by alias); 23 Jul 2009 12:24:58 -0000 Received: (qmail 26194 invoked by uid 22791); 23 Jul 2009 12:24:57 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate2.de.ibm.com (HELO mtagate2.de.ibm.com) (195.212.17.162) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 23 Jul 2009 12:24:51 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.1/8.13.1) with ESMTP id n6NCOnsT017604 for ; Thu, 23 Jul 2009 12:24:49 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n6NCOn8V1351822 for ; Thu, 23 Jul 2009 14:24:49 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n6NCOmJf001420 for ; Thu, 23 Jul 2009 14:24:48 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id n6NCOlAH001392; Thu, 23 Jul 2009 14:24:47 +0200 Message-Id: <200907231224.n6NCOlAH001392@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 23 Jul 2009 14:24:47 +0200 Subject: Re: [rfc] Infrastructure to disable breakpoints during inferior startup To: tromey@redhat.com Date: Thu, 23 Jul 2009 15:49:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, jkratoch@redhat.com (Jan Kratochvil) In-Reply-To: from "Tom Tromey" at Jul 22, 2009 01:07:23 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2009-07/txt/msg00579.txt.bz2 Tom Tromey wrote: > FWIW, I took a look at the PIE patch from the Fedora SRPM. It has > almost identical functions disable_breakpoints_before_startup and > re_enable_breakpoints_at_startup. Yes, it's the same concept, but those functions in the PIE patch have some code that seems PIE specific (e.g. the entry point checks) that should be moved to the caller (presumably solib-svr4.c in the PIE case) to make the same infrastructure usable for both scenarios. > There are some differences, but I don't know whether they are relevant > or not. > > The Fedora disable_breakpoints_before_startup has a check like this: > > + if (((b->type == bp_breakpoint) || > + (b->type == bp_hardware_breakpoint)) && > + b->enable_state == bp_enabled && > + !b->loc->duplicate) > > This differs from yours because it checks `loc->duplicate'. I don't see why a breakpoint shouldn't be disabled just because its first location has a duplicate ... If the breakpoint has another location, or if the duplicate gets removed later on, GDB would attempt to insert this breakpoint and fail ... See also the comments in disable_breakpoints_in_shlibs that explain why the shlib_disabled flag is explicitly set also for duplicates. > The Fedora re_enable_breakpoints_at_startup does this: > > + /* Do not reenable the breakpoint if the shared library > + is still not mapped in. */ > + if (target_read_memory (b->loc->address, buf, 1) == 0) > + { > + /*printf ("enabling breakpoint at 0x%s\n", paddr_nz(b->loc->address));*/ > + b->enable_state = bp_enabled; > + } > > I have no idea about this either. Perhaps it is something specific to > PIE on Linux. This seems odd to me; breakpoint disabled at startup cannot really be within a shared library. (Even if they were, a unmapped shared library ought to be handled via the shlib_disabled mechanism ...) > Ulrich> +/* Are we executing startup code? */ > Ulrich> +static int executing_startup; > > This seems like it should be a field in struct inferior. Agreed. > I seem to say that a lot :-). I don't actually know .. should we be > doing this sort of thing now, or are we waiting for Pedro's > multi-inferior patches to land first? I don't know; what's the timeline for Pedro's patches? (In any case, moving this variable over to a struct inferior field can be trivially done after Pedro's patches are merged; I'm not sure we have to wait because of that ...) > Ulrich> + bp_startup_disabled,/* The eventpoint has been disabled during inferior > > I think a new bp_ constant probably needs an entry in the array in > print_one_breakpoint_location. Otherwise if something funny happens, > and we try to print one, gdb will get an internal error. Unless I'm missing someting, the array in print_one_breakpoint_location is about enum bptype member; I've added a enum enable_state member here ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com