[PATCH] LD: PROVIDE_HIDDEN export class problem

[Maciej W. Rozycki]

On Wed, 1 May 2013, Joseph S. Myers wrote:

> >  Also I have realised the retention of the internal export class across 
> > PROVIDE_HIDDEN requires test coverage, so here's an updated patch with 
> > some extra cases added.  They succeed across all the targets I've got 
> > covered except tic6x-elf and tic6x-uclinux:
> > 
> > tic6x-elf  FAIL: PROVIDE_HIDDEN test 2
> > tic6x-elf  FAIL: PROVIDE_HIDDEN test 8
> > tic6x-uclinux  FAIL: PROVIDE_HIDDEN test 2
> > tic6x-uclinux  FAIL: PROVIDE_HIDDEN test 8
> > 
> > This is because unlike all the others they put the internal symbol in the 
> > symbol table of a static executable as STB_LOCAL/STV_DEFAULT rather than 
> > STB_GLOBAL/STV_INTERNAL.
> > 
> >  Joseph, would you please comment on this -- has this been a deliberate 
> > design decision for the tic6x ABI or is it just a bug/oversight of some 
> > sort?
> 
> I don't really understand what the question is.  The symbols provided with 
> PROVIDE_HIDDEN in the C6X linker scripts have different values in each 
> linked object, but as long as they aren't non-hidden dynamic symbols I 
> don't think the details matter - and in particular, I don't think it 
> matters how, if at all, those symbols appear in the *static* symbol table 
> of an executable or shared library.

 Both tests define the symbol concerned explicitly, PROVIDE_HIDDEN is 
supposed not to trigger -- the purpose of the tests is to check for it and 
to verify that the export class has not been downgraded from internal to 
hidden.  Also no default C6X linker scripts are used, the tests supply 
their own linker script each.

 The question is: has it been a deliberate decision to make tic6x-* unlike 
any other target in how STV_INTERNAL symbols appear in the static linker 
table?  Why does this backend do it, i.e. what piece of code is 
responsible for it?

 And to address your doubt as to whether the contents of the static symbol 
have a value: well, I think they do e.g. examining symbol tables I find it 
useful to know what particular export class a symbol had in static 
linking.  I think consistency with other targets has a value too, unless 
other requirements preclude it or at least there is a clear advantage from 
doing things differently.

  Maciej