Page MenuHomeFreeBSD

jrtc27_jrtc27.com (James Clarke)
User

Projects

User does not belong to any projects.

User Details

User Since
Jul 4 2018, 7:23 PM (71 w, 5 d)

Recent Activity

Oct 20 2019

jrtc27_jrtc27.com 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_jrtc27.com 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_jrtc27.com 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_jrtc27.com added inline comments to D21971: rpcgen: make compiler arglist allocation dynamic.
Oct 11 2019, 4:52 PM
jrtc27_jrtc27.com added inline comments to D21971: rpcgen: make compiler arglist allocation dynamic.
Oct 11 2019, 4:39 PM

Oct 6 2019

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

Sep 18 2019

jrtc27_jrtc27.com 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_jrtc27.com 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_jrtc27.com 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_jrtc27.com 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_jrtc27.com 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_jrtc27.com 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_jrtc27.com 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_jrtc27.com 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_jrtc27.com 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_jrtc27.com created D18429: RISC-V: Avoid orphan sections between __bss_start and .(s)bss.
Dec 4 2018, 8:52 PM
jrtc27_jrtc27.com 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_jrtc27.com 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_jrtc27.com 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_jrtc27.com 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_jrtc27.com 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

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

Aug 10 2018, 1:53 PM
jrtc27_jrtc27.com 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_jrtc27.com 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_jrtc27.com created D16655: MALTA: Avoid repeated address calculation for malta_ap_boot.
Aug 10 2018, 9:59 AM
jrtc27_jrtc27.com 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_jrtc27.com 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_jrtc27.com updated the test plan for D16644: MALTA: Query MVPConf0.PVPE for number of CPUs.
Aug 9 2018, 4:34 PM
jrtc27_jrtc27.com updated the diff for D16644: MALTA: Query MVPConf0.PVPE for number of CPUs.

Removed unused m variable.

Aug 9 2018, 4:34 PM
jrtc27_jrtc27.com 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_jrtc27.com created D16644: MALTA: Query MVPConf0.PVPE for number of CPUs.
Aug 9 2018, 1:26 PM

Jul 30 2018

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