sorear changed the topic of #riscv to: RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv
cousteau has joined #riscv
<aurel32> bjdooks: this is an issue with recent binutils
<aurel32> I don't have the issue building a .s extracted from the kernel build with 2.39, but I get the issue with a binutils snapshot from today with the same file
ZipCPU has quit [Read error: Connection reset by peer]
ZipCPU has joined #riscv
cousteau has quit [Quit: ♫ I can't forget the day I shot that network down ♫]
pabs3 has quit [Ping timeout: 268 seconds]
pabs3 has joined #riscv
epony has joined #riscv
elastic_dog has quit [Ping timeout: 265 seconds]
elastic_dog has joined #riscv
EchelonX has joined #riscv
vagrantc has joined #riscv
ZipCPU has quit [Ping timeout: 264 seconds]
ZipCPU has joined #riscv
vagrantc has quit [Quit: leaving]
wbn has joined #riscv
jimbzy has quit [Ping timeout: 260 seconds]
jimbzy has joined #riscv
frkzoid has joined #riscv
frkazoid333 has quit [Ping timeout: 272 seconds]
EchelonX has quit [Quit: Leaving]
pabs3 has quit [Ping timeout: 246 seconds]
pabs3 has joined #riscv
<bjdooks> aurel32: not sure if this a debian issue or just they're packaging a latest one which has a bug
<dh`> debian? latest? surely you're joking :-)
drmpeg has left #riscv [#riscv]
BootLayer has joined #riscv
drmpeg has joined #riscv
ZipCPU_ has joined #riscv
ZipCPU has quit [Ping timeout: 248 seconds]
ZipCPU_ is now known as ZipCPU
* DynamiteDan wishes everyone a great Christmas day. (Don't have too much sugar intake!)
ZipCPU has quit [Ping timeout: 272 seconds]
ZipCPU has joined #riscv
ZipCPU has quit [Ping timeout: 246 seconds]
ZipCPU has joined #riscv
ZipCPU has quit [Ping timeout: 252 seconds]
ZipCPU has joined #riscv
<bjdooks> Well it is 2.39.50 so must be fairly new
<bjdooks> I just need to work out how to find the source
ZipCPU has quit [Ping timeout: 246 seconds]
ZipCPU has joined #riscv
<conchuod> They do carry some patches, but looks mostly like importing from upstream binutils.
jmdaemon has quit [Ping timeout: 246 seconds]
epony has quit [Quit: QUIT]
ZipCPU has quit [Ping timeout: 265 seconds]
ZipCPU has joined #riscv
ZipCPU has quit [Ping timeout: 248 seconds]
ZipCPU has joined #riscv
<bjdooks> conchuod: there's nothing obviously riscv related
<conchuod> AFAICT, they pull in upstream binutils. In https://salsa.debian.org/toolchain-team/binutils/-/blob/master/debian/changelog
<conchuod> you can see the same tag as your binutils is there
* bjdooks is going to check upstream gas post lunch
<conchuod> Meh, check it after Stephens Day :)
<bjdooks> i'll get bored some point this afternoon
<bjdooks> gdb build makes laptop warm
<aurel32> this commit looks suspicious: ecb915b4de7569027ad78bd3e24873bb92cb8e32
tusko has quit [Remote host closed the connection]
tusko has joined #riscv
ZipCPU has quit [Ping timeout: 260 seconds]
<aurel32> and yes the current upstream binutils is also affected
ZipCPU has joined #riscv
epony has joined #riscv
motherfsck has joined #riscv
epony has quit [Ping timeout: 268 seconds]
aerkiaga has joined #riscv
<aurel32> i reported it on the debian side: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026979
motherfsck has quit [Ping timeout: 252 seconds]
junaid_ has joined #riscv
aerkiaga has quit [Remote host closed the connection]
epony has joined #riscv
pedja has joined #riscv
<bjdooks> aurel32: thanks, the next move might just be to try and update modpost to ignore zero
<aurel32> bjdooks: do you mean that the change might on the binutils might be the correct one?
<bjdooks> aurel32: more like hacking to avoid borked code
<aurel32> technically it could happen with any register, so we should ignore all register names in addition of zero
<aurel32> i am currently bisecting to try to identify the commit that introduced the change
<bjdooks> aurel32: ok, thanks
jimbzy has quit [Changing host]
jimbzy has joined #riscv
<aurel32> the commit that introduced that change is 839189bc932ea02c9647a3ad829dda72f8a9562c
jay2718 has joined #riscv
<aurel32> reverting just the jal hunk on master fixes the issue
jay2718 has quit [Ping timeout: 260 seconds]
<bjdooks> hmm, matching the wrong form of jal firsT?
<bjdooks> hmm, matching the wrong form of jal first?
Andre_H has joined #riscv
Andre_H has quit [Client Quit]
Proudmuslim|[m] has joined #riscv
junaid_ has quit [Remote host closed the connection]
<aurel32> bjdooks: looks like it might be an issue in the way we build binutils, as others can't reproduce the issue
<aurel32> that was just a user issue, so this is reproducible
Gravis has quit [Ping timeout: 260 seconds]
EchelonX has joined #riscv
freakazoid332 has joined #riscv
frkzoid has quit [Ping timeout: 246 seconds]
<la_mettrie> why call convention codes are like "addi sp,sp,-16" instead of "sub sp,sp,16"?
<Xark> la_mettrie: Because there is no subi instruction (unneeded). :)
Gravis has joined #riscv
Trifton has quit [Ping timeout: 268 seconds]
Trifton has joined #riscv
Trifton has quit [Remote host closed the connection]
Trifton has joined #riscv
Trifton2 has joined #riscv
Trifton has quit [Ping timeout: 256 seconds]
rneese has joined #riscv
aerkiaga has joined #riscv
<muurkha> la_mettrie: you could do the sub thing if you loaded the 16 into a register first
<muurkha> which you do with addi t0,x0,-16
<muurkha> uh, or addi t0,x0,16
<muurkha> although maybe your assembler and disassembler will disguise that as li t0,16
rneese has quit []
crabbedhaloablut has quit [Write error: Connection reset by peer]
tusko has quit [Remote host closed the connection]
crabbedhaloablut has joined #riscv
tusko has joined #riscv
vagrantc has joined #riscv
BootLayer has quit [Quit: Leaving]
cousteau has joined #riscv
tusko has quit [Ping timeout: 255 seconds]
tusko has joined #riscv
wingsorc has joined #riscv
aerkiaga has quit [Remote host closed the connection]
dh` has quit [Ping timeout: 272 seconds]
djdelorie has joined #riscv
jmdaemon has joined #riscv
EchelonX has quit [Quit: Leaving]
pedja has quit [Quit: Leaving]
vagrantc has quit [Quit: leaving]