nmeum has quit [Remote host closed the connection]
nmeum has joined #riscv
vagrantc has joined #riscv
Trifton has quit [Ping timeout: 246 seconds]
aerkiaga has quit [Remote host closed the connection]
davidlt has quit [Ping timeout: 264 seconds]
ball has quit [Quit: leaving]
davidlt has joined #riscv
aerkiaga has joined #riscv
prabhakarlad has quit [Quit: Client closed]
<bjdooks>
anyone else seen an issue with gcc producing static binaries that don't work under qemu?
<bjdooks>
it has been segfaulting, but the last build I did works, so assuming something got fixed in the glibc
<bjdooks>
it kepts segfaulting in ctype_inti() code
<palmer>
bjdooks: this is GCC trunk, or a release? I haven't seen anything specifically that would do that
<bjdooks>
whichever release debian/testing has been going, I think it is either a glibc/qemu interaction or something similar
erg_ has joined #riscv
<palmer>
looks like that's gcc-12, so it shouldn't be generating bad code (who knows, though). If you have a reproducer then filing a bugzilla is probably the right way to go
<palmer>
djdelorie has been chasing down some old glibc patches/bugs, so if you're on glibc/master (or they're getting backported to Debian) then you might be seeing some stuff get fixed in there
dor has quit [Ping timeout: 264 seconds]
<bjdooks>
palmer: yeah, i don't have a reproduction any more, it failed mondat and now works
<palmer>
I guess that's a bummer (or maybe good? it works)
<bjdooks>
and it's not qemu change, i can use the old binary i stored for ref to produce segfdault
<palmer>
OK, so I guess if you can figure out how to reproduce it (or even what changed) then that's probably going to be the best bet
<palmer>
aside from that, poking around in the bugzilla to see if anything's been reported is probably the best bet -- I generally run GCC trunk regressions sometimes, and while we always have some I don't see anything like "all static binaries fail"
<palmer>
(and I run those against qemu-user)
<bjdooks>
yeah, not sure it is gcc's fault, it might be an interaction with glibc
<palmer>
are you on 2.36? that's only a month old, maybe Debian just bumped you and that's what fixed it?
<palmer>
(it's 2 months old, I guess I'm just a month behind on the real world ;))
<bjdooks>
i'll go check, i know something moved as my test binary is slightly bigger
<palmer>
thanks. It'd still be interesting to see what was broken, it's possible whatever changed is just masking the actual issue
<palmer>
and I guess it should go into some regression suite somewhere, but that doesn't always happen ;)
erg_ has quit [Remote host closed the connection]
motherfsck has quit [Quit: quit]
BootLayer has quit [Quit: Leaving]
<conchuod>
Speaking of binutils, I know you said you don't check GitHub notifs palmer
<palmer>
hm, not sure what's up. did you send a patch?
<palmer>
I'd expect just some sort of $(cc-option ...Wa,...zicbom...) to do it
<conchuod>
No I didn't send a patch b/c it didnt work
<palmer>
that's sensible
<conchuod>
I changed -march=rv64ima_zicbom to -Wa,-march=rv64ima_zicbom, which turned off CONFIG_...ZICBOM correctly
<conchuod>
But still left me with rv64i2p0_m2p0_a2p0_c2p0_zicbom1p0_zihintpause2p0 in the object file
<palmer>
and you're sure you don't have any old objects floating around that were built with zicbom?
freakazoid332 has joined #riscv
<palmer>
(or I guess you're saying it was just in that one object?)
<conchuod>
Uh I blow away my build dir every time so there shouldn't be anything hanging around
<conchuod>
I'm building w/ clang 15 & binutils 2.35.2
<palmer>
did you also get the `toolchain-supports-zicbom := $(call cc-option-yn, -march=$(riscv-march-y)_zicbom)` in the Makefile?
<palmer>
we should probably just convert that over to a Kconfig-based switch, so it's only in one place (not sure if that works, though, as I'd probably have suggested it last time)
<conchuod>
Oh it's probably something dumb like that alright...
<palmer>
hopefully that's just it, then
Andre_H has quit [Ping timeout: 265 seconds]
<palmer>
there tends to be a few places where compiler support gets interrogated, sometimes it's just bad code but sometimes it's because the info doesn't plumb through like you'd hope it does
frkzoid has quit [Ping timeout: 260 seconds]
<palmer>
(you'll also need to make sure everything is CONFIG_ZICBOM, not __riscv_zicbom, if you drop the compiler march)
<conchuod>
I'll just push it out for LKP before sending anythin ;)
<palmer>
ya, that's what I do as well ;)
<palmer>
and just sort of thinking: -march=...zicbom... is wrong, that would let the compiler insert an unconditional cbo.zero
<palmer>
I think we don't do that (at least in GCC)
<conchuod>
palmer: looks like the same fix is needed for Zihintpause too...
<palmer>
we don't have a Kconfig for zihintpause so it's a little different, but ya it's essentially the same thing
<palmer>
another option would be to fall back to .insn for the old assemblers, not sure which is better but that's what we're doing for the T-Head custom instructions
knolle has joined #riscv
theruran has quit [Quit: Connection closed for inactivity]
<conchuod>
Ye, just needs the makefile bit
<conchuod>
Hey, at least I know what to look for next time someones adding extensions with instruction support :)
wingsorc has joined #riscv
<jrtc27>
clang+old bfd probably doesn't like that still
<jrtc27>
dunno if that's meant to be supported
<jrtc27>
and FYI I think -Wa* is blanket ignored by clang
<conchuod>
idk, I've been testing w/ clang-15 + 2.35.2 and my house has yet to go on fire jess
prabhakarlad has joined #riscv
pecastro has quit [Ping timeout: 252 seconds]
<jrtc27>
hm
geertu has quit [Ping timeout: 265 seconds]
geertu has joined #riscv
<somlo>
does opensbi support using something like "earlicon=sbi console=hvc0" with Linux? I remember using that with LiteX when running under BBL
<somlo>
*earlycon (with a y :)
<jrtc27>
opensbi doesn't care what you do
<jrtc27>
that's between you and your linux kernel
<jrtc27>
so sure it should
<palmer>
IIRC the SBI console got dropped after SBI-0.1, so you'd need a SBI implementation that supports the old stuff