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: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: "Maciej W. Rozycki" <macro 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 19:03:04 +0000
- 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>
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