Re: RFC: remove gdbarch from struct breakpoint

[Stan Shebs <stanshebs@earthlink.net>]

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