This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] LD: PROVIDE_HIDDEN export class problem
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Alan Modra <amodra at gmail dot com>, Dave Anglin <dave dot anglin at nrc dot ca>, Jeff Law <law at redhat dot com>, <binutils at sourceware dot org>
- Date: Wed, 1 May 2013 23:35:56 +0100
- Subject: Re: [PATCH] LD: PROVIDE_HIDDEN export class problem
- References: <alpine dot DEB dot 1 dot 10 dot 1304292220350 dot 1453 at tp dot orcam dot me dot uk> <20130430012124 dot GA3074 at bubble dot grove dot modra dot org> <alpine dot DEB dot 1 dot 10 dot 1304300301170 dot 1453 at tp dot orcam dot me dot uk> <Pine dot LNX dot 4 dot 64 dot 1305011857290 dot 13182 at digraph dot polyomino dot org dot uk>
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