Using LTO on PowerPC generates broken binaries

[pkubaj]

Bugzilla Link	47353
Version	unspecified
OS	FreeBSD
CC	@adalava,@nemanjai,@smithp35

Extended Description

FreeBSD head, LLVM 11.0.0-rc2, powerpc64 elfv2

FreeBSD uses GH BC as its bc implementation. It tries to build using -flto, but it's disabled for powerpc64, because it generates a broken bc that segfaults at start.

I also tried to build ffmpeg 4.3.1 with --enable-lto passed to configure. -flto is passed properly and ffmpeg builds fine. I can also compile software that links to ffmpeg libraries. However, running such software (e.g. mpv, or just ffmpeg itself) leads to instant segfault.

Compiling such software with GCC mitigates this issue.

[nemanjai]

I understand that a reproducer is hard to provide for something like this. However, are you able to at least provide instructions on how to build/configure this? Is it possible to do this on a big endian Linux system (i.e. after downloading some custom ELFv2 libraries)? If not, are you aware of any publicly accessible system that we can get into to reproduce this?

Perhaps at least start with information about the HW, stack trace, disassembly in the debugger of the place where the segfault happens...

[pkubaj]

Full reproducer, it looks like even hello world fails:
pkubaj@talos:$$ cc -v
FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe)
Target: powerpc64-unknown-freebsd13.0
Thread model: posix
InstalledDir: /usr/bin
pkubaj@talos:$$ cat test.c
#include <stdio.h>

int main(void)
{
printf("Hello world!\n");
}
pkubaj@talos:$$ cc test.c
pkubaj@talos:$$ ./a.out
Hello world!
pkubaj@talos:$$ cc -flto test.c
pkubaj@talos:$$ ./a.out
Segmentation fault (core dumped)

[pkubaj]

This seems to be an issue only on 64-bits on BE (FreeBSD uses ELFv2). LE works fine and 32-bit BE is also fine.

[pkubaj]

It looks like this issue is about LLD, not Clang.

Building software with LTO using Clang and linking them with BFD generates proper binaries.

[nemanjai]

There may very well be assumptions in LLD that ELFv2 implies little endian.

[llvmbot]

Yeah, looks like some extreme confusion going on. For some reason main is in .opd, and it's jumping to it.

It feels to me that there must be some vestigal ELFv1 code in lld that got missed during the ELFv1 removal kicking in.

[llvmbot]

Looks like at the very least llvm/lib/Target/PowerPC/PPCTargetObjectFile.cpp needs fixed. I don't know if that has anything to do with the LTO issue though.

[llvmbot]

Yeah, I suspect that might be where the problem is -- when it's ingesting the object file again, it might be injecting function descriptors...

I think what it should be doing there is only kicking in if Obj->getPlatformFlags() != 0x2 or similar.

[adalava]

With e3cbf1d I get these warnings on powerpc64 BE target:

$ ~/source/llvm-project/build/bin/clang -target powerpc64-unknown-freebsd13 -flto 47353-test.c
'-isa-v207-instructions' is not a recognized feature for this target (ignoring feature)
'-privileged' is not a recognized feature for this target (ignoring feature)
'-rop-protect' is not a recognized feature for this target (ignoring feature)
'-isa-v207-instructions' is not a recognized feature for this target (ignoring feature)
'-privileged' is not a recognized feature for this target (ignoring feature)
'-rop-protect' is not a recognized feature for this target (ignoring feature)

[pkubaj]

Fixed in 4b09cb2.