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: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Sun, 10 Jan 2010 21:20:02 +0100
- Subject: Re: [patch 03/15] PIE: breakpoint_address_match gdbarch_addr_bit workaround
- References: <20091109205757.GD19138@host0.dyn.jankratochvil.net> <m3fx8ne4b8.fsf@fleche.redhat.com>
On Mon, 09 Nov 2009 23:11:55 +0100, Tom Tromey wrote:
> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
>
> 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.
OK.
> 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?
It was forgotten quick-hack I have not noticed later, thanks.
> 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?
Those gdbarch fields discussion is now posted as
[00/03] per-aspace target_gdbarch (+local gdbarch obsoletion?)
http://sourceware.org/ml/gdb-patches/2010-01/msg00227.html
and this pastch is reposted as:
[03/03] Make breakpoint_address_match gdbarch_addr_bit-aware
http://sourceware.org/ml/gdb-patches/2010-01/msg00230.html
This patch is required for PIE but only in biarch (64bit debugger -> 32bit
inferior) or just for 32bit host built with --enable-64-bit-bfd mode.
Regards,
Jan