[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <d8f4abb8-32d6-7867-4c42-c52aed450e6a@mirbsd.de>
Date: Tue, 13 May 2025 00:09:36 +0200 (CEST)
From: Thorsten Glaser <tg@...bsd.de>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] force -fno-lto for CRT files
On Mon, 12 May 2025, Andy Caldwell wrote:
>On Mon, May 12, 2025 at 6:47 PM Rich Felker <dalias@...c.org> wrote:
>> On top of that, LTO-type transformations are wrong/unsafe for code
>> that executes prior to relocations and passing control to the entry
>> point, since at least in theory they could lift things without side
>> effects to somehow run before relocations or other initialization they
>> depend upon has happened. In some sense, this code runs in a separate,
>> lower-level execution environment operating *on* the memory of the
>> program that will run rather than *as part of* the program. So I think
>> it makes sense to suppress LTO.
ACK.
>Is this true? My understanding is that LTO optimizations follow the same
>rules as compiler optimizations (this specific case feels special but it's just
>dead-code-elimination that the per-unit compilations can't do since they
>can't see the whole binary). Currently start-files are compiled with `-O2`
>so any problematic lifting etc could already happen.
Only within the unit, i.e. the .o file, not across execution contexts
(pre-program vs. program itself).
LTO (at least in GCC) is also subtly buggy (and the bugreports get
mostly ignored).
>Out of perverse interest, I compiled `libc.a`, `Scrti.o` and `rcrti.o`
>with `-flto` and built some dynamic and static(-pie) binaries with
>`-flto` which all just worked out of the box (the main complexity was
It worked today, in your specific setup, with the toolchain you use,
but there is no guarantee it will continue working.
While whole-program optimisation sounds nice at first, the compiler
will assume that normal C rules for applications apply; the libc, in
application context already, isn’t part of the application but “the
implementation” and therefore allowed to do things application code
isn’t by the standard, and the startup files add initialisation context
to the mix. This will break subtly over time.
>> I kinda don't like introducing a second parallel set of "NOLTO" rules
>> that are identical to the "NOSSP" ones though, when the motivation for
Yes, that looked awful.
Keep CFLAGS_NOSSP and do:
CFLAGS_CSU = $(CFLAGS_NOSSP) $(CFLAGS_NOLTO)
Then use CFLAGS_CSU for the C startup objects.
(At least this is what I’d probably do.)
bye,
//mirabilos
--
<igli> exceptions: a truly awful implementation of quite a nice idea.
<igli> just about the worst way you could do something like that, afaic.
<igli> it's like anti-design. <mirabilos> that too… may I quote you on that?
<igli> sure, tho i doubt anyone will listen ;)
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.
