aerkiaga has quit [Read error: Connection reset by peer]
aerkiaga has joined #riscv
heat has quit [Read error: Connection reset by peer]
heat has joined #riscv
enoq has joined #riscv
jimbzy has joined #riscv
jimbzy has quit [Changing host]
heat_ has joined #riscv
heat has quit [Read error: Connection reset by peer]
heat_ is now known as heat
FL4SHK has joined #riscv
<palmer>
conchuod: maybe it's the mapping symbols?
<conchuod>
palmer: re: relocatable?
<palmer>
the odd stack trace
<palmer>
they shouldn't make something crash, but I bet Linux's stack dumper just doesn't know about them and tries to print them out
<conchuod>
Ah right, completely forgot about that!
<conchuod>
It was already crashing due to no rootfs, I just never saw it do that before.
<palmer>
I haven't either, but if you recently updated a toolchain that might be it
<palmer>
IIRC they went into the latest binutils release, not sure about LLVM
<conchuod>
Yeah, my vision5v2 stuff config uses 2.40 I think
<conchuod>
I guess that means we need to patch the stack dumper then.
<palmer>
I'd guess that's it, then. Maybe just send a bug report to LKML? I can probably get someone around here to fix it, Nelson added the mapping symbols
<conchuod>
palmer: done ;)
<palmer>
thanks
<conchuod>
palmer: I hope I didn't ruin poor auld Alex's weekend!
<palmer>
was he working over the weekend?
<conchuod>
He was emailing me about the relocatable boot failures, yeah
<palmer>
thanks for the heads up, I'll tell him thanks ;)
<conchuod>
Oh dear, have I ratted him out to his boss for working on a bank holiday weekend?!
<palmer>
no worries, I'm not his boss
<conchuod>
I have no clue yet why that stuff is failing to boot for me though, I need to try some older compilers or w/e I think.
<palmer>
cool. We can always revert/hide it if it's broken, but it'd be best to get to the bottom of it first
<conchuod>
Yeah, we still have a good bit of time on it & the hibernation stuff. Although, I do not think the hibernation one is going to be fixed in 3 weeks.
<palmer>
ya, I think we can call hibernation CONFIG_NONPORTABLE already -- at a bare minimum we'll need some DT stuff to make it work, and even if we could agree on adding something it's probably too late
<conchuod>
Yah, sounds about right to me..
<palmer>
cool, I just put the patch in the test queue
ncopa has quit [Quit: Ping timeout (120 seconds)]
dlan has quit [Ping timeout: 265 seconds]
AmyMalik has quit [Read error: Connection reset by peer]
kilobyte_ch has quit [Ping timeout: 265 seconds]
NishanthMenon has quit [Ping timeout: 265 seconds]
englishm has quit [Ping timeout: 265 seconds]
sami has quit [Ping timeout: 265 seconds]
sami_ has joined #riscv
dlan has joined #riscv
enoq has quit [Ping timeout: 265 seconds]
kilobyte_ch has joined #riscv
Ellenor has joined #riscv
ncopa has joined #riscv
aerkiaga2 has joined #riscv
aerkiaga has quit [Read error: Connection reset by peer]
awita has joined #riscv
Andre_Z has quit [Ping timeout: 240 seconds]
englishm has joined #riscv
NishanthMenon has joined #riscv
drewj has joined #riscv
<drewj>
conchuod: Hey Conor, what's patchwork's preferred base? Sunil just asked me and I said for-next or -rc1. But then I decided I better double check.
heat has quit [Ping timeout: 248 seconds]
<conchuod>
It should be capable of either now
<conchuod>
But right now, there's no difference
<drewj>
ok, and -rc1 is preferred over a later rc?
<conchuod>
Yes
<drewj>
ack
heat has joined #riscv
<conchuod>
riscv/master usually doesn't leave rc1
jay321 has joined #riscv
jacklsw has joined #riscv
motherfsck has joined #riscv
jay321 has quit [Remote host closed the connection]
jay321 has joined #riscv
jay321 has quit [Ping timeout: 240 seconds]
awita has quit [Ping timeout: 268 seconds]
jbowen has quit []
jbowen has joined #riscv
jay321 has joined #riscv
gurki_ has joined #riscv
gurki_ has quit [Client Quit]
gurki_ has joined #riscv
gurki_ has joined #riscv
gurki_ has quit [Client Quit]
gurki_ has joined #riscv
gurki_ has quit [Client Quit]
gurki_ has joined #riscv
gurki_ has quit [Client Quit]
gurki_ has joined #riscv
gurki has joined #riscv
pedja has joined #riscv
random-jellyfish has quit [Quit: Client closed]
motherfsck has quit [Ping timeout: 240 seconds]
awita has joined #riscv
random-jellyfish has joined #riscv
jacklsw has quit [Read error: Connection reset by peer]
___nick___ has quit [Ping timeout: 250 seconds]
Stat_headcrabed has joined #riscv
random-jellyfish has quit [Ping timeout: 245 seconds]
pedja has quit [Quit: Leaving]
billchenchina has joined #riscv
billchenchina has quit [Remote host closed the connection]
<zBeeble42>
so I'm teaching some students and we're looking at C and how it compiles to RISCV. In preparation, and put pow(), sin(), cos() and tan() in code and compiled with clang. This got compiled to "call pow@plt", "call sin@plt", "call cos@plt" and "call tan" ... in additon, at the end of the .s file, only tan was listed with addrsig_sym (which I assume is marking tan as external linkage).
<zBeeble42>
target here is an unmatched we have for the course.
<zBeeble42>
... so why is tan() the odd one out?
zBeeble42 is now known as zBeeble
<muurkha>
interesting!
<zBeeble>
I was specificall fishing to see if the processor had sin/cos/etc instructions. Fine that it doesn't. PLT as far as I can google is "Proceedure Linkage Table" ... but why are pow, sin, and cos on it and not tan?
motherfsck has joined #riscv
heat has quit [Read error: Connection reset by peer]
heat has joined #riscv
heat has quit [Read error: Connection reset by peer]
heat has joined #riscv
<jrtc27>
zBeeble: what compiler? I don't see that
<jrtc27>
for both GCC and Clang
motherfsck has quit [Ping timeout: 250 seconds]
gurki has quit [Ping timeout: 265 seconds]
<zBeeble>
clang in my case
<zBeeble>
I don't actually have gcc installed ATM.
<jrtc27>
I see clang using @plt for both on godbolt.org
<jrtc27>
hm though indeed not locally for a freebsd sysroot
<jrtc27>
seems to be some weirdness between how intrinsics are lowered vs normal functions
<jrtc27>
sin and cos have intrinsics
motherfsck has joined #riscv
heat has quit [Ping timeout: 250 seconds]
<zBeeble>
so... aren't intrinsics for (say) the case where some processors have sin() as an instruction and some don't (68030 w/ mmu, for instance)?
<jrtc27>
LLVM aggressively maps to intrinsics
<zBeeble>
... I'm poking around the riscv instruction set manual, and I don't see this difference for tan() --- is this just something the porter did?
<jrtc27>
it'll then turn them back into libcalls if needed
<jrtc27>
no
heat has joined #riscv
<jrtc27>
nothing to do with the ISA
<jrtc27>
it's about LLVM's IR
<jrtc27>
there's @llvm.sin and @llvm.cos but no @llvm.tan
<zBeeble>
odd?
<jrtc27>
maybe the theory is it gets canonicalised as sin / cos