Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 28 Apr 2015 21:41:14 +0300 (MSK)
From: Alexander Monakov <>
Subject: Re: [PATCH] force LTO to be disabled when compiling

> This seems to be a common problem then. I helped someone on #gcc with
> almost the exact same issue doing freestanding work making a
> kernel/bare-metal app using LTO a week or so ago. I'm not sure the
> linker plugin can solve the problem since it seems to happen for
> symbol references *within* a single translation unit (or a combined .o
> file produced by ld -r, as in the case of the person on #gcc) which
> the linker plugin probably does not track.

I think I see the root cause now.  The reference to _dlstart_c is from a GCC
asm statement (toplevel in this case), not from a separate assembly file.  The
toplevel asm is part of LTO "bytecode", so when linker symbol resolution runs,
it did not yet have a chance to see the reference from the asm, and GCC is
oblivious to the fact (it would need to parse the asm to notice).

If the person on #gcc with ld -r was using gcc asm statements as well, that
would explain their problem too.

So moving the assembly into its own .s file should avoid the issue; adding
__attribute__((used)) to _dlstart_c fixes it too; but even then ...

> Even if the problem is missing linker plugin though, I think we want
> to avoid LTO on these files. It's likely to be very risky since the
> code is running in a situation where no function calls, global data
> accesses, or symbolic references are possible. Here we really are
> asking the compiler to produce asm for us, rather than asking it to
> produce an optimized way to get an abstract job done.

acknowledged.  Your call :)


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.