Page MenuHomeFreeBSD
Feed Advanced Search

Mon, Feb 3

jrtc27 added a comment to D23436: Set the LMA of the riscv kernel to the OpenSBI jump target by default.

Thanks!

Mon, Feb 3, 1:13 PM

Jan 17 2020

jrtc27 accepted D23236: fix riscv load/stores.

Yes, this is exactly what I had in mind.

Jan 17 2020, 4:14 PM

Jan 16 2020

jrtc27 accepted D23139: RISC-V: fix global pointer assignment at boot.

Yes, looks good.

Jan 16 2020, 8:34 PM

Jan 11 2020

jrtc27 added inline comments to D23139: RISC-V: fix global pointer assignment at boot.
Jan 11 2020, 11:56 PM
jrtc27 added a comment to D23139: RISC-V: fix global pointer assignment at boot.

Yep, this is what I was thinking of (with the lla fixed). Thanks!

Jan 11 2020, 11:53 PM
jrtc27 added a comment to D23138: RISC-V: fix global symbol lookups for mpentry with lld.

Ah yes, good point, looks good to me.

Jan 11 2020, 11:48 PM

Jan 7 2020

jrtc27 added a comment to D23064: Workaround lld's inability to handle undefined weak symbols on risc-v..
In D23064#505712, @jhb wrote:

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.?

Jan 7 2020, 10:26 PM
lwhsu renamed jrtc27 from jrtc27_jrtc27.com to jrtc27.
Jan 7 2020, 1:58 AM
jrtc27 added a comment to D23064: Workaround lld's inability to handle undefined weak symbols on risc-v..

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 7 2020, 1:05 AM

Jan 3 2020

jrtc27 created D23017: devel/py-setuptools: Fix with non-default PREFIX.
Jan 3 2020, 3:45 AM

Dec 30 2019

jrtc27 updated the diff for D22970: RISC-V: Don't hard-code field offsets of struct riscv_bootparams.

Wrapped >80-character line.

Dec 30 2019, 4:53 PM
jrtc27 created D22970: RISC-V: Don't hard-code field offsets of struct riscv_bootparams.
Dec 30 2019, 3:12 PM
jrtc27 created D22968: RISC-V: Don't hard-code size of struct riscv_bootparams.
Dec 30 2019, 1:33 PM

Dec 29 2019

jrtc27 created D22961: RISC-V: Ensure kernel stack is aligned.
Dec 29 2019, 10:00 PM

Dec 5 2019

jrtc27 added a comment to D22659: Add a new "riscv-relaxations" linker feature..

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 5 2019, 1:05 AM

Dec 4 2019

jrtc27 added inline comments to D22659: Add a new "riscv-relaxations" linker feature..
Dec 4 2019, 12:01 AM

Dec 3 2019

jrtc27 added a comment to D22661: Correct the offset of static TLS variables for Initial-Exec..

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).

Dec 3 2019, 11:58 PM
jrtc27 added inline comments to D22659: Add a new "riscv-relaxations" linker feature..
Dec 3 2019, 11:45 PM
jrtc27 added a comment to D22658: Use "far" calls and branches so that lld uses valid relocations..

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.

Dec 3 2019, 10:50 PM
jrtc27 added a comment to D22656: Use a single 'ld' to read the jmpbuf magic values instead of 'la; ld'..

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.)

Dec 3 2019, 10:24 PM

Oct 20 2019

jrtc27 added a comment to D22084: Fix atomic_*cmpset32 on riscv64 with clang..
In D22084#482546, @jhb wrote:

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 20 2019, 12:31 AM

Oct 13 2019

jrtc27 abandoned D17820: Don't hardcode X_ prefix on fallback path for X_COMPILER_*/X_LINKER_*.

We're ditching our extra CHERI_CC/CHERI_LD so this is no longer relevant to us.

Oct 13 2019, 9:48 PM
jrtc27 added a comment to D21912: nda(4): Remove unnecessary union and avoid Clang -Wsizeof-array-div warning.

Could you please commit this if you believe it is ready to land? Thanks.

Oct 13 2019, 9:46 PM

Oct 11 2019

jrtc27 added inline comments to D21971: rpcgen: make compiler arglist allocation dynamic.
Oct 11 2019, 4:52 PM
jrtc27 added inline comments to D21971: rpcgen: make compiler arglist allocation dynamic.
Oct 11 2019, 4:39 PM

Oct 6 2019

jrtc27 created D21914: Fix various -Wpointer-compare warnings.
Oct 6 2019, 3:16 PM
jrtc27 created D21913: msun: Silence new harmless -Wimplicit-int-float-conversion warnings.
Oct 6 2019, 3:05 PM
jrtc27 created D21912: nda(4): Remove unnecessary union and avoid Clang -Wsizeof-array-div warning.
Oct 6 2019, 2:37 PM
jrtc27 created D21911: binutils: Fix bugs found by -Wpointer-compare.
Oct 6 2019, 1:57 PM

Sep 18 2019

jrtc27 added a comment to D21699: Hack around incorrect TLS defaults for mips64.

(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...)

Sep 18 2019, 5:27 PM
jrtc27 added a comment to D21699: Hack around incorrect TLS defaults for mips64.

I can't remember why we need this change. There were some cases where we really need inital-exec for executables rather than global-dynamic.
I tend to forget everything about TLS once I no longer need to know it but maybe @jrtc27_jrtc27.com, @brooks or @jhb know.

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.

Sep 18 2019, 5:04 PM

Feb 10 2019

jrtc27 added a comment to D18429: RISC-V: Avoid orphan sections between __bss_start and .(s)bss.

Ping? Seems this was never landed.

Feb 10 2019, 11:52 AM

Dec 4 2018

jrtc27 added inline comments to D17820: Don't hardcode X_ prefix on fallback path for X_COMPILER_*/X_LINKER_*.
Dec 4 2018, 11:19 PM
jrtc27 added inline comments to D17820: Don't hardcode X_ prefix on fallback path for X_COMPILER_*/X_LINKER_*.
Dec 4 2018, 11:05 PM
jrtc27 added inline comments to D17820: Don't hardcode X_ prefix on fallback path for X_COMPILER_*/X_LINKER_*.
Dec 4 2018, 11:01 PM
jrtc27 added inline comments to D17820: Don't hardcode X_ prefix on fallback path for X_COMPILER_*/X_LINKER_*.
Dec 4 2018, 10:47 PM
jrtc27 added inline comments to D17820: Don't hardcode X_ prefix on fallback path for X_COMPILER_*/X_LINKER_*.
Dec 4 2018, 10:47 PM
jrtc27 added inline comments to D17820: Don't hardcode X_ prefix on fallback path for X_COMPILER_*/X_LINKER_*.
Dec 4 2018, 10:44 PM
jrtc27 created D18429: RISC-V: Avoid orphan sections between __bss_start and .(s)bss.
Dec 4 2018, 8:52 PM
jrtc27 added a comment to D17820: Don't hardcode X_ prefix on fallback path for X_COMPILER_*/X_LINKER_*.

Ping?

Dec 4 2018, 8:42 PM

Nov 2 2018

jrtc27 retitled D17820: Don't hardcode X_ prefix on fallback path for X_COMPILER_*/X_LINKER_* from bsd.compiler.mk: Don't hardcode X_ prefix on fallback path to Don't hardcode X_ prefix on fallback path for X_COMPILER_*/X_LINKER_*.
Nov 2 2018, 6:20 PM
jrtc27 updated the diff for D17820: Don't hardcode X_ prefix on fallback path for X_COMPILER_*/X_LINKER_*.

Do the same for X_LINKER_* too

Nov 2 2018, 6:19 PM
jrtc27 created D17820: Don't hardcode X_ prefix on fallback path for X_COMPILER_*/X_LINKER_*.
Nov 2 2018, 6:07 PM

Aug 10 2018

jrtc27 added a comment to D16510: Rework rtld's TLS Variant I implementation to match r326794.
In D16510#353963, @jrtc27_jrtc27.com wrote:

@jhibbits asked if I could run this on my ppc64 because he's busy:
P198 -m64

&aligned_var_ie: 0x810058000
aligned_var_ie: 0x0
&aligned_var_le: 0x810059000
aligned_var_le: 0x0

Thanks, anything obviously wrong for 64-bit? [...]

Aug 10 2018, 1:53 PM
jrtc27 updated the diff for D16510: Rework rtld's TLS Variant I implementation to match r326794.

Fixed powerpc64's rtld_machdep.h (missed in the previous version), and introduced new calculate_tls_post_size MD macro.

Aug 10 2018, 1:52 PM
jrtc27 added a comment to D16510: Rework rtld's TLS Variant I implementation to match r326794.

@jhibbits asked if I could run this on my ppc64 because he's busy:
P198 -m64

&aligned_var_ie: 0x810058000
aligned_var_ie: 0x0
&aligned_var_le: 0x810059000
aligned_var_le: 0x0
Aug 10 2018, 10:21 AM
jrtc27 created D16655: MALTA: Avoid repeated address calculation for malta_ap_boot.
Aug 10 2018, 9:59 AM
jrtc27 updated the diff for D16644: MALTA: Query MVPConf0.PVPE for number of CPUs.

Renamed MVPCONF0_PVPE to MVPCONF0_PVPE_MASK.

Aug 10 2018, 9:14 AM

Aug 9 2018

jrtc27 added a comment to D16644: MALTA: Query MVPConf0.PVPE for number of CPUs.

Boots to userspace with -smp 4 on QEMU:

Aug 9 2018, 4:36 PM
jrtc27 updated the test plan for D16644: MALTA: Query MVPConf0.PVPE for number of CPUs.
Aug 9 2018, 4:34 PM
jrtc27 updated the diff for D16644: MALTA: Query MVPConf0.PVPE for number of CPUs.

Removed unused m variable.

Aug 9 2018, 4:34 PM
jrtc27 added a comment to D16644: MALTA: Query MVPConf0.PVPE for number of CPUs.
In D16644#353674, @br wrote:

what is test plan ?

Aug 9 2018, 2:02 PM
jrtc27 created D16644: MALTA: Query MVPConf0.PVPE for number of CPUs.
Aug 9 2018, 1:26 PM

Jul 30 2018

jrtc27 created D16510: Rework rtld's TLS Variant I implementation to match r326794.
Jul 30 2018, 3:18 PM
jrtc27 created P198 tls-align.c.
Jul 30 2018, 3:10 PM