Re: [PATCH v4] BFD: Prevent writing the MIPS _gp_disp symbol into symbol tables

Re: [PATCH v4] BFD: Prevent writing the MIPS _gp_disp symbol into symbol tables

[Maciej W. Rozycki]

Hi Joseph,

> Does this affect the glibc testsuite (which currently has _gp_disp in all 
> the *.abilist expectations for 32-bit MIPS)?  If it does, do you have a 
> suggestion for how to keep it passing with both old and new linkers (e.g. 
> ignoring absolute symbols in the ABI tests)?

 Thanks for raising this concern.

 The presence of a dynamic `_gp_disp' symbol is I think a grey area of the 
MIPS psABI.  This is what it has to say about this symbol[1]:

"The symbol name _gp_disp is reserved.  Only R_MIPS_HI16 and R_MIPS_LO16 
relocations are permitted with _gp_disp.  These relocation entries must 
appear consecutively in the relocation section and they must reference 
consecutive relocation area addresses."

By inference this means no dynamic references are allowed to `_gp_disp', 
because the R_MIPS_HI16 and R_MIPS_LO16 relocations must fully resolve at 
static link time.  Therefore while the presence of `_gp_disp' in the 
dynamic symbol table is not explicitly disallowed by the MIPS psABI, it 
serves no run-time purpose either, and certainly none defined the the ABI.  
Consequently I think the symbol should be considered not a part of the 
ABI.

 Therefore I think we should selectively ignore it.  What you write 
implies we have no predefined way of doing that, and it looks to me like 
we ought to define a way to feed `scripts/abilist.awk' a (carefully 
selected) list of symbols to ignore in processing.

 Alternatively (and that looks to me like a better way to deal with this 
symbol, as it will actually fix non-compliant dynamic binaries produced by 
unfixed binutils) we could run `strip --strip-symbol=_gp_disp' after link.  
I'm not sure how feasible implementing this solution would be though and 
then this should probably be wired into the link stage somehow for o32 
MIPS targets only, that is with `sysdeps/mips/mips32/configure.ac', so as 
not to burden irrelevant configurations.

References:

[1] "SYSTEM V APPLICATION BINARY INTERFACE, MIPS RISC Processor
    Supplement, 3rd Edition", Section "Relocation", p. 4-20

  Maciej

Re: [PATCH v4] BFD: Prevent writing the MIPS _gp_disp symbol into symbol tables

[Joseph Myers]

On Mon, 30 Apr 2018, Maciej W. Rozycki wrote:

>  Therefore I think we should selectively ignore it.  What you write 
> implies we have no predefined way of doing that, and it looks to me like 
> we ought to define a way to feed `scripts/abilist.awk' a (carefully 
> selected) list of symbols to ignore in processing.

But do we need such a list, or would just ignoring all absolute symbols 
suffice?

At present, abilist.awk shows such symbols with a type of "A".  Apart from 
symbol version names, _gp_disp seems to be the only such symbol.  Is there 
any need to have the "A" lines for each symbol version in the abilist 
files?

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH v4] BFD: Prevent writing the MIPS _gp_disp symbol into symbol tables

[Maciej W. Rozycki]

On Mon, 30 Apr 2018, Joseph Myers wrote:

> >  Therefore I think we should selectively ignore it.  What you write 
> > implies we have no predefined way of doing that, and it looks to me like 
> > we ought to define a way to feed `scripts/abilist.awk' a (carefully 
> > selected) list of symbols to ignore in processing.
> 
> But do we need such a list, or would just ignoring all absolute symbols 
> suffice?
> 
> At present, abilist.awk shows such symbols with a type of "A".  Apart from 
> symbol version names, _gp_disp seems to be the only such symbol.  Is there 
> any need to have the "A" lines for each symbol version in the abilist 
> files?

 I don't know.  Perhaps someone else knows.

 As I noted stripping the problematic symbol is IMO the best solution.  
Using `$CC -print-prog-name=strip' to discover where the right `strip' 
binary is should be a straightforward way to arrange that in a platform 
`configure' fragment.  Then we can dump `_gp_disp' from .abilist files.

  Maciej

Re: [PATCH v4] BFD: Prevent writing the MIPS _gp_disp symbol into symbol tables

[Joseph Myers]

On Tue, 1 May 2018, Maciej W. Rozycki wrote:

>  As I noted stripping the problematic symbol is IMO the best solution.  
> Using `$CC -print-prog-name=strip' to discover where the right `strip' 
> binary is should be a straightforward way to arrange that in a platform 
> `configure' fragment.  Then we can dump `_gp_disp' from .abilist files.

But adding an extra step to the process for linking shared objects (which 
is in architecture-independent code; after-link is used for executables as 
well as shared libraries, so doesn't seem suitable here) seems like excess 
complexity here, compared to changing existing handling of absolute 
symbols in abilist.awk to do something else (a net reduction in the amount 
of code).

Does strip even work to remove symbols from the dynamic symbol table (as 
opposed to the static symbol table)?

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH v4] BFD: Prevent writing the MIPS _gp_disp symbol into symbol tables

[Maciej W. Rozycki]

On Tue, 1 May 2018, Joseph Myers wrote:

> Does strip even work to remove symbols from the dynamic symbol table (as 
> opposed to the static symbol table)?

 Indeed, `strip' seems unable to remove dynamic symbol table entries, so I 
need to withdraw my alternative proposal.

 As to filtering out all absolute symbols as I noted I don't know what 
impact it may have across current targets and whether it may cause hassle 
in the future, so I have no opinion either.  If you think it's safe, then 
I won't object.

  Maciej