- User Since
- Jan 11 2019, 6:48 AM (157 w, 5 d)
Mar 30 2021
Yeah, I think the only reason the isl code can get away with it is that it's related to the usage of Autoconf in that directory. llvm/cmake/config.guess doesn't have that exemption because it's being invoked from a cmake module, not an Autoconf script.
I'm pretty sure we're using this old config.guess on purpose to avoid GPL3 code.
Mar 8 2021
The code changes look logical and correct to me.
Jan 2 2021
Forcing retest again.
Update altivec changes after fd739804e0591468762eb87488a497a3f7d4afb0.
Dec 30 2020
Dec 29 2020
Add missing OpenMP TLS test for powerpcle.
- Adjust the GNU LD settings for 32 bit powerpc to more closely match reality.
- Add linker emulation test for powerpcle, as well as adding testing for the FreeBSD emulations.
Fully fix the unit test.
Re-uploading patch for part 5 now that I have the dependency tree fixed.
Dec 28 2020
Add q66 to reviewers list for the targeting bits relevant to Void ppcle.
- Fix LLVM object handling unit test.
- Fix bug in clang/test/Driver/linux-header-search.cpp -- The powerpc64le test was being done with -m32 accidentally.
- Update llvm/unittests/ADT/TripleTest.cpp for powerpcle.
- Update gcc driver bits to reflect use of powerpcle in void-ppc.
Dec 23 2020
Fix merge base.
- Address review comment from MaskRay.
- Incorporate changes from the Void powerpcle patchset.
Splitting up into multiple commits as per MaskRay's suggestion.
Dec 2 2020
Dec 1 2020
Regarding things like Altivec and VSX:
Altivec should be just fine to run in 32-bit LE.
I am undecided as to whether VSX should be banned or not. However that goes, it should be identical in powerpc64 -m32 and powerpc64le -m32.
On FreeBSD, the main use of this will be on the new powerpc64le arch, where we need to build a 32-bit LE bootloader for use with pseries. (it is easier to retarget LLVM than make a cross-endian bootloader, as it would involve rewriting filesystem code etc.)
Nov 23 2020
OK, patch updated with the typo fix.
Nov 21 2020
Nov 20 2020
Sep 17 2020
Sep 12 2020
That's fair. Will just use a patch on the FreeBSD side and revisit after 11.0.0 is released. Thanks.
Sep 10 2020
Any chance of a backport to 11?
Aug 26 2020
Aug 25 2020
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.