[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.11.1505010949180.22867@monopod.intra.ispras.ru>
Date: Fri, 1 May 2015 09:57:08 +0300 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: musl@...ts.openwall.com
Subject: Re: Re: building musl libc.so with gcc -flto
> > Wouldn't adding __attribute__((externally_visible)) to the relevant
> > symbols be more appropriate? It's intended to solve exactly this
> > problem.
>
> I'm not clear whether it would be reliable to use this or not.
> Semantically externally_visible and visibility=hidden are
> contradictory. Even if we weren't trying to avoid relying on
> additional GNU C features, I think it would be a bad idea to rely on
> this working since the behavior under such contradictory annotations
> could potentially vary widely between compilers.
The attribute that's suitable for this case is "used", not
"externally_visible" (um, I already mentioned that in the other thread where I
explained why the reference from the asm is 'ignored'). Andy is not correct
in saying that "it's intended to solve exactly this problem". To quote GCC
manual,
externally_visible
This attribute, attached to a global variable or function, nullifies
the effect of the -fwhole-program command-line option, so the object
remains visible outside the current compilation unit.
used
This attribute, attached to a function, means that code must be
emitted for the function even if it appears that the function is not
referenced. This is useful, for example, when the function is
referenced only in inline assembly.
( https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html )
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
