From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8946 invoked by alias); 7 Nov 2011 16:52:06 -0000 Received: (qmail 8937 invoked by uid 22791); 7 Nov 2011 16:52:05 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from elasmtp-galgo.atl.sa.earthlink.net (HELO elasmtp-galgo.atl.sa.earthlink.net) (209.86.89.61) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Nov 2011 16:51:52 +0000 Received: from [70.170.59.51] (helo=macbook2.local) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RNSQJ-0001t3-Ip for gdb-patches@sourceware.org; Mon, 07 Nov 2011 11:51:51 -0500 Message-ID: <4EB80CA6.9080700@earthlink.net> Date: Mon, 07 Nov 2011 16:52:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: gdb-patches Subject: Re: RFC: remove gdbarch from struct breakpoint References: <20111107152058.GD14508@adacore.com> <201111071609.39862.pedro@codesourcery.com> In-Reply-To: <201111071609.39862.pedro@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da94008d51e6cbd2075b8babe168060b48dff350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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: 2011-11/txt/msg00158.txt.bz2 On 11/7/11 8:09 AM, Pedro Alves wrote: > On Monday 07 November 2011 15:20:58, Joel Brobecker wrote: >>> This patch removes the 'gdbarch' field from struct breakpoint. >>> >>> 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. >> 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. > break foo if sizeof($pc)==8 ? Or one could conceivably have watch shared_mem_struct.afield with different offsets and sizes for each arch accessing the field, but in practice the program's code is unlikely to work if they are different. (Of course, it would be better for GDB to expose such an inconsistency, rather than silently using only the first gdbarch's version...) Stan stan@codesourcery.com