Andre_Z has quit [Remote host closed the connection]
emneo has quit [Ping timeout: 256 seconds]
hmw has quit [Quit: Bye.]
hmw has joined #riscv
levitating__ has joined #riscv
hmw has quit [Quit: Bye.]
Andre_Z has joined #riscv
hmw has joined #riscv
hmw has quit [Quit: Bye.]
hmw has joined #riscv
psydroid3 has joined #riscv
levitating__ has quit [Remote host closed the connection]
hmw has quit [Quit: Bye.]
hmw has joined #riscv
hmw has quit [Client Quit]
hmw has joined #riscv
etra has joined #riscv
etra has quit [Changing host]
etra has joined #riscv
coldfeet has joined #riscv
hmw has quit [Client Quit]
hmw has joined #riscv
psydroid3 has quit [Ping timeout: 258 seconds]
cleger has quit [Ping timeout: 265 seconds]
emneo has joined #riscv
lechner has joined #riscv
cleger has joined #riscv
s1b1_ has quit [Ping timeout: 256 seconds]
<lechner>
Please let me rephrase that question. Is there any reason a riscv64 platform would segfault when executing memory aligned to a page boundary and obtained via the mmap Glibc function with the "prot" argument PROT_EXEC | PROT_WRITE ?
<dramforever[m]>
<lechner> Please let me rephrase that question. Is there any reason a riscv64 platform would segfault when executing memory aligned to a page boundary and obtained via the mmap Glibc function with the "prot" argument PROT_EXEC | PROT_WRITE ?
<dramforever[m]>
what's your kernel version
coldfeet has quit [Quit: Lost terminal]
<aurel32>
lechner: a failure to clear the i-cache after writing to it?
<sorear>
"GNU system" in the glibc manual means Hurd
<sorear>
non-executable stacks have been the default for a few years I think, and the stack overflow answer points at x86_64 details which are irrelevant here
<dramforever[m]>
i don't think 6.12 has any of the weird problems with PROT_*
<dramforever[m]>
so i'm outta ideas
emdevt has joined #riscv
<sorear>
I doubt it's the icache, a SIGSEGV on the first instruction is fairly unlikely especially if the page didn't previously hold text
emdevt has quit [Ping timeout: 248 seconds]
<sorear>
load-absolute-address won't work at all because the ori immediate is sign extended
<lechner>
sorear / what does that mean, please?
<lechner>
sorry, i get it. you looked at my code
<lechner>
how may I load a 64 bit value, please?
<lechner>
also, how can a logical value be sign-extended?
<lechner>
i'd rather not do the memory thing
emdevt has joined #riscv
emdevt has quit [Ping timeout: 265 seconds]
<sorear>
sign extension means that bit 11 of the immediate is copied to fill 63:12 so the valid values are -2048 .. 2047
<sorear>
memory is the typically recommended approach, you could also use xor or a 6-instruction sequence lui, addi, lui, addi, slli, add, or just do ori in 11-bit chunks
<courmisch>
is 6 instructions the shortest generalisation if using multiple registers?
<courmisch>
how many registers does it take for an assembler macro that can't clobber any register other than the destination?
<sorear>
fp usage is unidiomatic and possibly wrong, if you intend it to be available for debugging the fp needs to be the *old* sp with the saved fp at -8 and the ra at -16, like https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/437, also access to the frame is normally done with an sp base even if fp is set
<sorear>
courmisch: yes, or 5 with Zbb pack, without a second register you need 8 lui, addi, slli, addi, slli, addi, slli, addi
psydroid2 has joined #riscv
ldevulder has quit [Ping timeout: 250 seconds]
vagrantc has joined #riscv
Andre_Z has quit [Quit: Leaving.]
<lechner>
sorear / thanks! i think i get the first sequence with five. the last add is for lower half in one register to the upper half in another, right?
<lechner>
out of curiosity, how would the ori in 11-bit chunks work?
libercv has joined #riscv
<sorear>
lechner: yes, slli/add to combine two 32-bit chunks, just remember that they are signed
<sorear>
same as you have now, but 0-11, 11-22, 22-33, etc
<sorear>
ori immediates outside 0..2047 are less useful because they are interpreted as negative
<lechner>
sorear / okay, thanks! maybe i will stick with the ori for now. keeping the upper bit a zero is a good solution, too. thanks for that!
<sorear>
Why are you JITing something with no dynamic parts anyway? Is this being called with libffi?
<lechner>
sorear / so for the add, i'd have to check the highest bit of the upper to pick either a straight add (for 0) or a sub of the two's complement (for 1)?
<sorear>
It's an add either way. After you've cast the lower to int32, add 1 to the upper if the lower is negative
<lechner>
thanks!
<lechner>
sorear / it's part of a new concept interpreter that may or may not work as intended. the goal is to radically reduce prerequisites at the cost of some assembly, for bootstrapping
<sorear>
Or cast the lower to int32, then back, then subtract, then divide the residual (exactly) by 2^32
<sorear>
it seems a little weird that the arguments are nine integers but the result is a heap value (?)
<sorear>
anyway none of this explains segfaulting on an 8067
<lechner>
for boostrapping, i have to provide basic Guile types in assembly anyway. everything is on the heap, i think
<lechner>
what's 8067, please?
<lechner>
you may find interactive assembly an interesting experience. it radically reduces the number of steps in order to run something, plus you have a higher language to interpret data, structures, etc---plus formatted output
<lechner>
also, i'd like to credit you in my code with your name or handle here. which do you prefer?
<lechner>
i guess the five-step addi would be more efficient
cleger has quit [Remote host closed the connection]
<lechner>
but wouldn't i also need the upper half check on the last addi?
<sorear>
think of it recursively
<sorear>
you can construct any 64-bit value by adding something in the range -2048 to 2047, to something divisible by 4096, which can be constructed by shifting a 52-bit number, which...
<sorear>
or as a signed digit representation
<sorear>
<lechner> Hi, is the 00008067 opcode the standard way to return from a function? I see a segmentation fault with the little-endian bytevector 103 128 0 0 (decimal) even though the start is aligned to a page boundary. Also, how may I find out whether my system is little-endian, please? Thanks!
<sorear>
it wasn't mentioned in the replies earlier but riscv instructions are always little endian
<lechner>
thanks for those
<lechner>
sorear / but isn't there a chance that the uppermost bit is 1 in the last step of the recursive addi sequence, meaning it would be interpreted as a signed number and would hence require correction by adding 1?
<sorear>
remember, the whole process is linear. "adding 1" at the last step "increases" the final number by 2^72, which is a noop
<sorear>
if you've done six rounds of a shift-and-add-12-bits
<sorear>
alternatively, do a recursive process and stop when you reach something in range of lui, which will happen since it shrinks at each step
<sorear>
did your original complaint of ret (00008067) segfaults get resolved
libercv has quit [Quit: Konversation terminated!]
coldfeet has joined #riscv
<sorear>
either credit is fine
<sorear>
paste doesn't immediately look wrong
Trifton is now known as TDRC
<markh>
If it is still segfaulting, running it under valgrind should help to narrow down the cause.
ZLima12 has quit [Remote host closed the connection]
ZLima12 has joined #riscv
<lechner>
markh / sorear / yeah, it's still segfaulting. is valgrind available in Debian sid for riscv64