Mon, Feb 3
Jan 17 2020
Yes, this is exactly what I had in mind.
Jan 16 2020
Yes, looks good.
Jan 11 2020
Yep, this is what I was thinking of (with the lla fixed). Thanks!
Ah yes, good point, looks good to me.
Jan 7 2020
I also note we're playing a bit fast and loose with linker relaxations here; all those llas before we set up gp risk being relaxed to GP-relative (although unlikely given none of these symbols are in .sdata so it's a game of chance whether it happens to be placed near enough, and also prone to breakage if this code is edited later to refer to other symbols), as does the la of cpu_exception_handler. I think we should be initialising gp twice; once as the first thing in _start to get it in the physical world, and again at the start of va (and mpva) to get the virtual address as we do now (but earlier). But that's something for another patch.
To be clear, that's true of the existing code as well, not a "new" thing relative to the change to lla? The la virtmap at least always has to come before a load of gp. I guess if being paranoid we could use an explicit lui / addi sequence with %lo, etc.?
Ah yes that's nicer having it in kern.pre.mk, I think I naively just assumed kern.mk included kern.pre/post.mk and thus it wouldn't have helped.
Jan 3 2020
Dec 30 2019
Wrapped >80-character line.
Dec 29 2019
Dec 5 2019
There isn't really a precedent for arch-specific linker features, but I don't think it's an issue. Do you know how long it might be before we see support for relaxations in lld? If it's not long, could we not just check for lld directly instead of using a linker feature?
Dec 4 2019
Dec 3 2019
Note that this is the same fix as rS339072 for powerpc and rS342671 for powerpc64, and matches the mips implementation, all of which use Variant I TLS and thus should look the same (ignoring the values of the constants themselves).
In this instance it's uses of R_RISCV_JAL/R_RISCV_BRANCH rather than R_RISCV_CALL, but they all behave the same in BFD (plus their compressed variants, and interestingly also R_RISCV_PCREL_HI20). LLD will always error if you use these on undefined/preemptible symbols, much like any other architecture, whereas BFD does the weird resolution as John describes.
This is particularly beneficial as, for PIC code, which this will almost always be, la expands to auipc/ld to index the GOT, so we save a level of unnecessary indirection too. (This could have been lla instead to save the indirection but still take 2 instructions just to do the address calculation.)
Oct 20 2019
So I now wonder if this isn't actually a compiler bug in LLVM. Specifically, section 4.2 of the 2.2 spec when talking about RV64 has this "explanatory" comment in italics:The compiler and calling convention maintain an invariant that all 32-bit values are held in a sign-extended format in 64-bit registers. Even 32-bit unsigned integers extend bit 31 into bits 63 through 32. Consequently, conversion between unsigned and signed 32-bit integers is a no-op, as is conversion from a signed 32-bit integer to a signed 64-bit integer. Existing 64-bit wide SLTU and unsigned branch compares still operate correctly on unsigned 32-bit integers under this invariant. Similarly, existing 64-bit wide logical operations on 32-bit sign-extended integers preserve the sign-extension property. A few new instructions (ADD[I]W/SUBW/SxxW) are required for addition and shifts to ensure reasonable performance for 32-bit values.
If I'm reading this correctly, the compiler should be storing the unsigned 32-bit values as sign-extended instead of zero-extended and that clang is zero-extending the value that gets passed in to 'cmpval' incorrectly. It may be that it is only fcmpset32 that is affected due to cmpval being a pointer? In fact, I wonder if this change will in fact break GCC now as it might be passing in a 64-bit value in the cmpval register.
Nice investigation, it sounds like this is indeed an LLVM bug. I believe this patch would break a GCC-built kernel as is, but if you can sign-extend *cmpval instead of zero-ing tmp, we could commit it as a workaround.
Oct 13 2019
We're ditching our extra CHERI_CC/CHERI_LD so this is no longer relevant to us.
Could you please commit this if you believe it is ready to land? Thanks.
Oct 11 2019
Oct 6 2019
Sep 18 2019
(FWIW, to complete the picture, -fPIE *is* accepted since it's still a position-independent code model and thus doesn't upset -mabicalls (though really PIC and ABI calls shouldn't be conflated), and thus overrides the implicit default -fPIC, giving initial exec as the default TLS model, so that might be a nicer way to go...)
Actually, it's possible that lld wasn't (or isn't) able to optimize these relocations for static linking, which might cause statically linked binaries to fail.
Feb 10 2019
Ping? Seems this was never landed.
Dec 4 2018
Nov 2 2018
Do the same for X_LINKER_* too
Aug 10 2018
In D16510#353963, @jrtc27_jrtc27.com wrote:
Fixed powerpc64's rtld_machdep.h (missed in the previous version), and introduced new calculate_tls_post_size MD macro.
Renamed MVPCONF0_PVPE to MVPCONF0_PVPE_MASK.
Aug 9 2018
Boots to userspace with -smp 4 on QEMU:
Removed unused m variable.