[llvm-dev] lld-link crash when build openssl with LTO

[Reid Kleckner via llvm-dev]

On Tue, Jul 16, 2019 at 7:04 AM Teresa Johnson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Usage of the builtin appears independent of LTO, see below.
>
> With any of -fno-builtin, -fno-builtin-memcpy, and -ffreestanding, which
> are all typically used to prevent usage of memcpy calls, we still always
> get a memcpy builtin in TlsDriverEntryPoint(). I see this even without
> -flto (e.g. try with just -emit-llvm).
>
> I guess it is because this memcpy is not coming from the original source,
> but rather from the initialization code created by clang for the
> cryptopro_ext local variable. The code that generates that must not honor
> -fno-builtin. I see this even when I remove -flto (and this gets converted
> to a call to _memcpy in the final assembly with or without -fno-builtin).
>
> I can't do the full LTO link with these options (don't have a windows
> linker I guess?), and have been unsuccessful in getting the failure with
> various other options I tried. I wanted to look at the merged LTO code with
> save-temps.
>
> What happens to the builtin created by clang in LTO mode that causes lld
> to seg fault?
>

I added some analysis to the bug. I think (but am not 100% confident) that
we are lazily the memcpy bitcode file from an archive after LTO has already
happened, leading to a crash later. I guess LLD should have some kind of
check that ensures we don't load LTO objects after LTO has already run.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190716/d7e9143a/attachment.html>