[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAO2+NUAO607B6vRhWdOt9+p9Ccx-aWr=Td9=kyE1rgFME=dwMw@mail.gmail.com>
Date: Sat, 30 Jan 2021 23:59:14 +0300
From: Леонид Юрьев (Leonid Yuriev) <leo@...iev.ru>
To: musl@...ts.openwall.com
Cc: Jiahao XU <Jiahao_XU@...look.com>
Subject: Re: Can’t build musl with lto=thin
I have some experience in solving problems with LTO, including for
embedded projects.
Therefore, perhaps my thoughts and advice will be useful.
In general, LTO almost always requires a little refinement of source
code but problems arise only with really dirty code or due to
ill-conceived modularity.
For instance, the ODR must not be violated.
On Sat, Jan 30, 2021 at 11:12 PM Rich Felker <dalias@...c.org> wrote:
> The -fmerge-all-constants option gives non-conforming language
> semantics and should not be used, but that's a separate issue.
There are no problems with constants, unless it's addresses are used
to distinguish ones (and even more so to change).
But this is easily workarounded by placing such constants inside an
instance of a single static structure, etc.
> Otherwise, it's a known issue that LTO misses references from asm
> (both top-level and in functions). I think dlstart.lo and a few other
> files should just be built with LTO disabled; any LTO-type
> optimization in code that runs at this stage is inherently invalid,
> anyway. So something like (in config.mak):
This is easily workarounded by adding __attribute__((__used__)) or
__attribute__((__externally_visible__)) to the function/variable
definition, but requires binutils version >= 2.36.
Regards,
Leonid.
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.
