From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14574 invoked by alias); 8 Nov 2011 17:19:09 -0000 Received: (qmail 14560 invoked by uid 22791); 8 Nov 2011 17:19:07 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD,TW_BJ X-Spam-Check-By: sourceware.org Received: from mtagate3.uk.ibm.com (HELO mtagate3.uk.ibm.com) (194.196.100.163) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Nov 2011 17:18:54 +0000 Received: from d06nrmr1707.portsmouth.uk.ibm.com (d06nrmr1707.portsmouth.uk.ibm.com [9.149.39.225]) by mtagate3.uk.ibm.com (8.13.1/8.13.1) with ESMTP id pA8HIpB1016968 for ; Tue, 8 Nov 2011 17:18:51 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pA8HIpBV2244630 for ; Tue, 8 Nov 2011 17:18:51 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pA8HIpWR022787 for ; Tue, 8 Nov 2011 10:18:51 -0700 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id pA8HInH6022772; Tue, 8 Nov 2011 10:18:49 -0700 Message-Id: <201111081718.pA8HInH6022772@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 08 Nov 2011 18:18:49 +0100 Subject: Re: RFC: remove gdbarch from struct breakpoint To: tromey@redhat.com (Tom Tromey) Date: Tue, 08 Nov 2011 17:19:00 -0000 From: "Ulrich Weigand" Cc: pedro@codesourcery.com (Pedro Alves), gdb-patches@sourceware.org, brobecker@adacore.com (Joel Brobecker) In-Reply-To: from "Tom Tromey" at Nov 08, 2011 09:59:31 AM 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: 2011-11/txt/msg00198.txt.bz2 Tom Tromey wrote: > >>>>> "Ulrich" == Ulrich Weigand writes: > > Ulrich> Most other architecture-dependent things in breakpoint.c etc really > Ulrich> should use a per-location architecture. However, the way the per- > Ulrich> location arch is currently chosen is to either determine it from > Ulrich> the location --but this works only if we find a symtab!-- or else > Ulrich> fall back to the main breakpoint architecture. If we remove that > Ulrich> fall back, there will be cases where breakpoints are set at locations > Ulrich> with no symtab (e.g. in generated code, stack trampolines, etc.) > Ulrich> and we will not find any associated architecture. > > Ok, I see. > > Why not just use the location's arch when parsing and re-parsing the > expression, though? Well, which location? A single breakpoint might expand to multiple locations in different architectures, any or none of which might be the same as the current architecture at the time the breakpoint is initially entered ... For example, today we could add a breakpoint like: break spu.c:123 if var.offset == 123 while currently in PowerPC architecture. The way this was intended to work is to set a breakpoint location on spu.c:123 (with a location architecture of "spu"), while evaluating the condition using PowerPC architecture settings. > With my patches this still defaults to the current > arch when the breakpoint is set -- this just isn't stored on the > breakpoint any more. Actually, it doesn't: the location arch is retrieved from the SAL, it only falls back to the current arch if there is no architecture associated with the SAL. So in the case mentioned above, the location arch would be set to "spu", and the fact that the current arch was "powerpc" when the breakpoint was set would be lost. > (Now get_sal_arch tries to get the objfile arch as > a fallback, which I hope avoids any missing cases.) Well, in the cases I mentioned above (generated code, stack trampolines) -- which are rare, but possible, breakpoint targets, especially for single-step breakpoints -- there is no objfile either. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com