This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch 03/15] PIE: breakpoint_address_match gdbarch_addr_bit workaround
- From: Tom Tromey <tromey at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 09 Nov 2009 15:11:55 -0700
- Subject: Re: [patch 03/15] PIE: breakpoint_address_match gdbarch_addr_bit workaround
- References: <20091109205757.GD19138@host0.dyn.jankratochvil.net>
- Reply-to: tromey at redhat dot com
>>>>> "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