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: Thu, 2 May 2013 22:19:30 +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> <alpine dot DEB dot 1 dot 10 dot 1305012101450 dot 26443 at tp dot orcam dot me dot uk> <Pine dot LNX dot 4 dot 64 dot 1305012240210 dot 13182 at digraph dot polyomino dot org dot uk>
On Wed, 1 May 2013, Joseph S. Myers wrote:
> > 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?
>
> I am not aware of such a decision and do not know what code is responsible
> for it.
OK, thanks for your input. As it happens the new version of the tests I
have just posted does not see a difference between tic6x-* and other
targets because unmodified bfd_elf_record_link_assignment forces all
symbols mentioned in PROVIDE_HIDDEN commands to be STB_LOCAL/STV_DEFAULT
regardless of the origin of the symbols. Therefore I'm leaving it up to
you to decide if investigating the difference for ordinary STV_INTERNAL
(and presumably STV_HIDDEN) symbols is worth any effort.
Maciej