This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: remove gdbarch from struct breakpoint


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]