[Mesa-dev] glx-tls: Visibility hidden attribute and fix x86/x86_64 tls/tds entry points

Emil Velikov emil.l.velikov at gmail.com
Mon Sep 28 09:41:39 PDT 2015


On 26 September 2015 at 00:59, Sedat Dilek <sedat.dilek at gmail.com> wrote:
> Hi,
>
> unfortunately, we still have no cool upstream fix for
> -fvisibility=hidden compiler flag handling.
> There is still no visibility-attribute "hidden" available or defined.
>
These two are separate things, as Alan pointed out. The -fvisibility
param should not be taken that the
__attribute__(visibility(("hidden"))) is available and vice-versa.

> I see people again fell over this issue [2].
>
> I have one concern...
>
> GCC uses "default" visibility-attribute (defined as PUBLIC) when
> compiler-flag "-fvisibility=hidden" is used.
> But CLANG needs in some cases "hidden" visibility-attribute.
>
Is that irrespective of the mapi issue at hand ? If so this is a
definite clang bug.


> [ src/util/macros.h ]
>
> /**
>  * PUBLIC/USED macros
>  *
>  * If we build the library with gcc's -fvisibility=hidden flag, we'll
>  * use the PUBLIC macro to mark functions that are to be exported.
>  *
>  * We also need to define a USED attribute, so the optimizer doesn't
>  * inline a static function that we later use in an alias. - ajax
>  */
> #ifndef PUBLIC
> #  if defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))
> #    define PUBLIC __attribute__((visibility("default")))
> #    define USED __attribute__((used))
> #  elif defined(_MSC_VER)
> #    define PUBLIC __declspec(dllexport)
> #    define USED
> #  else
> #    define PUBLIC
> #    define USED
> #  endif
> #endif
>
> #ifdef HAVE_FUNC_ATTRIBUTE_VISIBILITY
> #define HIDDEN __attribute__((visibility("hidden")))
> #else
> #define HIDDEN
> #endif
>
> [ src/util/macros.h ]
>
> Alan pointed to a solution like in [4] ("Use clang's __has_attribute
> to check for attribute support")
>
> So, what can people do to help to nail this down?
>
> I have attached a refreshed version of Marc's and added the TDS
> snippet from [2] to 0002 patch.
> ( Patches have no changelog and are against mesa v10.6.8. )
>
The major 'issue' is wrt the second patch really. It changes the
visibility of the symbols, which imho is due to a misfeature in clang
(i.e. gcc adopts behaviour of new standards if it's more laxed,
whereas clang have done the following here).

I would suggest re-spinning the patches on top of master (ideally
retaining authorship/revision history etc.) and sending them inline.

Thanks for bringing this topic again.
Emil


More information about the mesa-dev mailing list