Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.