[PATCH] LD: PROVIDE_HIDDEN export class problem

[Joseph S. Myers]

On Wed, 1 May 2013, Maciej W. Rozycki 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.

-- 
Joseph S. Myers
joseph@codesourcery.com