[Mesa-dev] [PATCH] mapi: fix LTO compilation

Emil Velikov emil.l.velikov at gmail.com
Mon Jun 6 11:12:46 UTC 2016


Hi Jan,

Fwiw I fully agree on your point on outstanding patches.

Now about this patch itself.

On 2 June 2016 at 18:41, Jan Ziak (⚛) <0xe2.0x9a.0x9b at gmail.com> wrote:
> LTO compilation can sometimes fail with GCC 4.9 and GCC 5.3 because
> src/mapi uses unusual mixing of C code and assembly code. The issue
> may be present in case of GCC 6.1 as well.
>
> This is a Mesa bug rather than a compiler bug
This is a bold statement without any justification. I'm not saying
that the code is correct - just that saying "it's wrong" without
saying "why or how" serves little benefit.

> (although in an ideal
> world the compilation with -flto should fail if and only if normal
> compilation fails).
>
> The error message:
>
> entry_x86-64_tls.h:61: undefined reference to `x86_64_entry_start'
>
> Without the patch:
> - using "-flto -O2 -DDEBUG" fails with GCC 4.9 and 5.3
> - using "-flto -O3 -DDEBUG" succeeds with GCC 4.9 and 5.3
> - using "-flto -O2 -DNDEBUG" succeeds with GCC 4.9 and 5.3
>
Thanks you for the test/analisys.

So it seems like that infamous x86_64_entry_start comes again. There's
been a few threads and bug reports on the topic. In some it was
pointed out that clang was enforcing C11 rule/behaviour, even though
-std=c99 was used at the command line. In others there was a
suggestion on alternative solution.

Can you please search through for the said symbol and
compact/summarise things -  fold bug reports as duplicates, reference
old patches/threads and even opt for the alternative fix ?

> The patch assumes that the assembler understands ".hidden" directive.
>
This is perfectly fine assumption, since we already rely on it in
other parts of mesa.

Thanks
Emil


More information about the mesa-dev mailing list