[patch 03/15] PIE: breakpoint_address_match gdbarch_addr_bit workaround

[Tom Tromey]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> there are already multiple cases of CORE_ADDR being masked by the
Jan> width of gdbarch_addr_bit.

Jan> Checked that CORE_ADDR math operations are present on 6000+ lines
Jan> of code of GDB sources which makes it impossible to do some general
Jan> fix by replacing all
Jan> a-> addr < b->addr
Jan> by
Jan> 	addr_less_than (a->addr, b->addr)
Jan> etc.

Maybe spatch could handle this.  (I've had mixed success with spatch on
gdb, but it may be worth a try; it is also worth noting that the spatch
developers seem quite responsive to bug reports.)

Jan> Even with this patch I think there are still many bugs left in the
Jan> operation of x86_64 gdb debugging i386 targets.  Do you find the
Jan> C++ way as a viable one?

It definitely won't happen any time soon.

If we care about this problem I expect we will have to fix it the
old-fashioned way.

Jan> +  int addr_bit = gdbarch_addr_bit (target_gdbarch);
Jan> +  CORE_ADDR addr_mask = CORE_ADDR_MAX;
Jan> +
Jan> +  if (addr_bit < (sizeof (CORE_ADDR) * HOST_CHAR_BIT))
Jan> +    addr_mask = ((CORE_ADDR) 1 << addr_bit) - 1;
Jan> +

I am not so sure about this patch.  Is target_gdbarch really correct
here?  E.g., struct bp_location has a `gdbarch' field, which I presume
could differ from target_gdbarch and which should probably be used in
preference to it.  Maybe breakpoint_address_match needs two gdbarch
arguments to allow proper interpretation of the CORE_ADDRs?

Tom