bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/29998] ld terminated with signal 11 [Segmentation fault] under m


From: medhefgo at web dot de
Subject: [Bug ld/29998] ld terminated with signal 11 [Segmentation fault] under mingw with LTO
Date: Wed, 25 Jan 2023 14:17:22 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=29998

--- Comment #21 from Jan Janssen <medhefgo at web dot de> ---
Of course the reproducer is nonsensical. It's just a minified version of
systemd-boot.

> These files appear to be redundant - their code is never called.

When I minified the code, this appeared to be necessary for the miscompile to
happen. For example, dropping test2.o from the final link will have popcount be
compiled and called correctly.

> Shouldn't this function be called main() rather than run() ?

Since I am trying to build an EFI binary, I cannot use main(). The miscompile
also happens if -Wl,--entry=run is passed when linking.

> If you are linking without the standard libraries, can you really expect
the program to run ?

I don't expect the reproducer to run at all. I only expect it to build
correctly. When building with stdlib+main produces correct output, but that's
not what I need.

So yeah, change the link command to this if you want:
   x86_64-w64-mingw32-gcc -o test.exe -flto -nostdlib -Wl,--entry=run test2.o
test3.o libtest.a -lgcc


> True - but as far as I can see this code will never be called.  So having
LTO eliminate the call to  __popcountdi2 is understandable.

But run does get called (by the EFI runtime). Or for userspace nostdlib stuff:
whichever code loads the stuff is also responsible for calling into the entry
point.

I don't mind opening a bug on gcc if you think it's on their side. I would not
be able to tell.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]