- User Since
- Jan 11 2019, 6:48 AM (88 w, 6 d)
Thu, Sep 17
Sat, Sep 12
That's fair. Will just use a patch on the FreeBSD side and revisit after 11.0.0 is released. Thanks.
Thu, Sep 10
Any chance of a backport to 11?
Wed, Aug 26
Tue, Aug 25
Use correct target for FreeBSD driver test.
Add some tests for the new target.
Aug 24 2020
May 20 2020
Mar 1 2020
Here's the LLD_REPRODUCE using the cross toolchain (since I had it already and I hit the same thing on the backport, this one is probably the best one to look at)
OK, I reinterpreted 9569a1472ee7fee37f7f991d34634c5d8d1f3559 (as a prereq to reduce the churn) and this patch in the context of llvm10 (mainly re-uppercasing function names so that stuff applies and converting the MCSection::NonUniqueID bit back into ~0) so I can run it in-tree for a FreeBSD buildworld, and I hit the exact same failure, so it looks like there's an actual problem here.
I'm pretty sure I'm just tripping over c++ weirdness related to trying to use an external llvm HEAD compiler as a toolchain for the same platform. I will retry from my cross build machine.
Right, which is why it was so surprising to see it again in HEAD. I'm still trying to get a reproduce.
This fixes my problem encountered trying to build kyua and atf for lld10-native FreeBSD ppc32.
Still working on testing this one.
Feb 28 2020
From a FreeBSD standpoint, I am very happy with this.
AWESOME, this fixed the clang crash I was seeing with lld10 as well! I think it's possible this might be the last crashing bug blocking ppc32 lld migration.
This patch will be needed on FreeBSD to fix some crashes for an lld10-linked FreeBSD powerpc32 world, such as a crash running /usr/bin/objdump -D.
Jan 28 2020
Looks correct to me, works great, and fixes the last lld-related problem I am aware of currently on FreeBSD powerpc32.
I am now able to load pf.ko on FreeBSD powerpc32 without it crashing.
Jan 25 2020
This is necessary to run large programs like clang on FreeBSD powerpc32 when built with lld, because of REL24 branches in the crt startup code (done on purpose for object reusability reasons -- the csu objects need to work on both non-pic and pic, so they just use a plain bl and rely on the link editor to do a thunk if necessary.)
This version looks very promising so far. Will do a full freebsd buildworld test / boot on G4. I expect this version to have fixed the issue, but will verify.
Excellent! This looks like it fixed the FreeBSD putchar problem for me. I will test this with a full powerpc32 buildworld and report back.
Jan 24 2020
While I ran into further problems on ppc32, I think it's just because there are further problems on ppc32 (unrelated to this one). At the very least this gets FreeBSD ppc32/lld10 as far as the rescue shell, which is great progress!
Jan 23 2020
For anyone who is curious about this, copy relocations are especially needed on powerpc32, where they are used to implement global data (such as sharing a pointer between a .so and the main program) in situations where the main program's copy lives in .bss.
Jan 7 2020
I am definitely in favor of this change, as the defaulting to PIC has been causing headaches in the FreeBSD kernel.
Nov 29 2019
On the FreeBSD kernel side, I put some time into working out the missing parts on ppc32 and slightly extending the kernel linker to support secure-plt PIC kernel modules. Working on that over at https://reviews.freebsd.org/D22608.
Nov 25 2019
This doesn't seem quite sufficient for FreeBSD kernel modules. It's emitting R_PPC_REL24 instead of R_PPC_ADDR16_HA/R_PPC_ADDR16_LO pairs for stuff like memset and memcpy, which are unusable because we're running modules in KVA and the kernel text in the 32 bit DMAP. Still need to figure out why these are being emitted this way when using freestanding.
Aug 8 2019
It turns out I need the proper fix after all in my local tree, because lately I have been working on getting a working Petitboot loader binary, and that means I'm technically cross compiling code for ppc64le Linux. So yeah, it would be very nice to get this in.
May 14 2019
May 7 2019
So for ELF, you would want to do this logic INSTEAD of the hidden check immediately above.
So basically, it's either printing nothing (if st_other is 0), .internal (if st_other is 1), .hidden (if st_other is 2), .protected (if st_other is 3), or hex (anything other than these exact st_other values.)
The relevant binutils objdump logic is contained in bfd/elf.c, specifically the bfd_elf_print_symbol() function.
Jan 11 2019
One particular place this is needed is to handle FreeBSD powerpc64 (ELFv2 experimental) libc's weak symbols / symbol aliasing, especially when using LLD (in my experience, binutils ld will partially compensate for this issue.)