Re: [RFA 1/2] Make line tables independent of progspace

["Maciej W. Rozycki" <macro@mips.com>]

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