This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA 1/2] Make line tables independent of progspace
On Tue, 27 Mar 2018, Simon Marchi wrote:
> Anyway, I just have some small comments here, otherwise the patch LGTM. Maybe
> it would be a good idea to get the opinion of Maciej (in CC) for the
> addr_bits_remove part?
It's not clear to me offhand what the impact on processing that involves
`addr_bits_remove' the change proposed will have. So what specifically
would you like me to comment on here?
As to the MIPS handler it seems ill-conceived to me. On 64-bit MIPS
hardware 32-bit addresses are architecturally sign-extended, so assuming
that the comment in `mips_addr_bits_remove' is correct any workaround for
inconsistent handling should have been made the other way round, that is
by sign-extending rather than zero-extending addresses.
This hack was introduced with:
commit 96431497ff2c780978d95f5fda7148ba732dcae0
Author: Mark Alexander <marka@cygnus>
Date: Wed Nov 27 03:40:02 1996 +0000
and then the default for whether to mask was changed to off with:
commit 4014092b582281f6db1c43f618d3722561fb01e6
Author: Andrew Cagney <cagney@redhat.com>
Date: Tue Jul 11 09:25:22 2000 +0000
I'm tempted to remove the hack altogether as nowadays we should be getting
the sign-extension right for 32-bit addresses everywhere.
I know of a single case of hardware, the Sony R5900 processor (used in
the PS2 video game console), which is 64-bit but has addressing limited to
32 bits and, contrary to what the MIPS architecture requires, does not
sign-extend the PC correctly. This is only observable with the link
register (typically $ra) and the JAL/JALR/BGEZAL/BGEZALL/BLTZAL/BLTZALL
instructions that copy the value of the PC there. And then only in bare
metal debugging, as bit #31 is only set for kernel mode addresses. I
don't think any bare metal debugging facility is available for that
processor though, and if one turns up, then we can think how to deal with
that.
FWIW,
Maciej