From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27145 invoked by alias); 8 Nov 2011 16:22:36 -0000 Received: (qmail 27128 invoked by uid 22791); 8 Nov 2011 16:22:33 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate1.uk.ibm.com (HELO mtagate1.uk.ibm.com) (194.196.100.161) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Nov 2011 16:22:16 +0000 Received: from d06nrmr1707.portsmouth.uk.ibm.com (d06nrmr1707.portsmouth.uk.ibm.com [9.149.39.225]) by mtagate1.uk.ibm.com (8.13.1/8.13.1) with ESMTP id pA8GMD3K006722 for ; Tue, 8 Nov 2011 16:22:13 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 pA8GMDYG2318412 for ; Tue, 8 Nov 2011 16:22:13 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 pA8GMB0G019298 for ; Tue, 8 Nov 2011 09:22:11 -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 pA8GMAfm019242; Tue, 8 Nov 2011 09:22:10 -0700 Message-Id: <201111081622.pA8GMAfm019242@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 08 Nov 2011 17:22:10 +0100 Subject: Re: RFC: remove gdbarch from struct breakpoint To: pedro@codesourcery.com (Pedro Alves) Date: Tue, 08 Nov 2011 16:22:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, brobecker@adacore.com (Joel Brobecker), tromey@redhat.com (Tom Tromey) In-Reply-To: <201111071609.39862.pedro@codesourcery.com> from "Pedro Alves" at Nov 07, 2011 04:09:39 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: 2011-11/txt/msg00194.txt.bz2 Pedro Alves wrote: > On Monday 07 November 2011 15:20:58, Joel Brobecker wrote: > > I think that makes sense. I am trying to figure out how a breakpoint > > could have a gdbarch that made some sort of sense when the breakpoint > > has two locations and each location had a different gdbarch from > > the other.... > > History behind the fields: > http://sourceware.org/ml/gdb-patches/2009-06/msg00215.html > and: > http://sourceware.org/ml/gdb-patches/2009-07/msg00075.html > > Reading the first url, I was wondering if we'd indeed need the > breakpoint's gdbarch for reparsing conditions and watchpoint > expressions (or anything that uses expressions instead of linespecs), > but I can't find such dependency in the code. Maybe Ulrich can > take a look at this. The Cell combined debugger can maybe > reveal hidden dependencies with the gdbarch fallbacks we do. Ahh. That seems to be one of the "open ends" of multi-arch support that has never been addressed so far. Currently, expression parsing always takes place in the "current" architecture context; see the get_current_arch call in parse_exp_in_context. This is really a bug; the parse routines probably ought to take a gdbarch parameter instead. (The reasons why expression parsing is dependent on the architecture are basically those Stan described; things like how to interpret register names, struct layout ABI, and predefined types like "long".) Having a gdbarch field in "struct breakpoint" was in part a preparation for this: once expression parsing is -properly- done specifically in an architecture context, we need to decide which arch to pass when parsing (and re-parsing) breakpoint conditions and expressions. My thought was that the right way to do that would be to remember and re-use the architecture that was current at the time the expression was initially entered; just like is currently done with the language and input radix used when reparsing conditions and watchpoint expressions. Most other architecture-dependent things in breakpoint.c etc really should use a per-location architecture. However, the way the per- location arch is currently chosen is to either determine it from the location --but this works only if we find a symtab!-- or else fall back to the main breakpoint architecture. If we remove that fall back, there will be cases where breakpoints are set at locations with no symtab (e.g. in generated code, stack trampolines, etc.) and we will not find any associated architecture. Now maybe it is not really correct to use the same field both for the architecture to parse a breakpoint expression, and as the fall-back location arch for locations without symtab. Maybe the fall-back could instead be a per-program_space default gdbarch ... or we could add a gdbarch field to the SAL, and require all users to fill it ... > > In most cases, it is sufficient to replace the use of this field with > > the location's gdbarch instead. In fact, I think the cases in > > tracepoint.c where this is not done are probably latent bugs. > > Yeah. Agreed about the tracepoint.c uses. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com