Parsing fixes for riscv64: lui, loads

[strlcat]

lui decompilation is wrong:

• original produces "a0 = 0x429a000; return;" for "lui a0, 0x17050; ret", but shall produce "a0 = 0x17050000; return;"
• Note that lui followed by addi is correct and is unaffected.

l{d,w,h,b}[u] decompilation is wrong:

• original produces "ra = *((sp + 0x40));" for "ld ra, 40(sp)" (note that '40' decimal is simply left unaffected and gets substituted to '0x40' in result, giving impression that this is now correct hex value), but shall produce "ra = *((sp + 0x28));". This affects all load insns of all types.
• Note that store insns are unaffected by this bug.

[strlcat]

Please note that these are quick & dirty fixes by person inexperienced with js, to make it work and be less annoying when decompilation & translation process goes.

[wargio]

do you have a test? you can generate it using pddi

[strlcat]

do you have a test? you can generate it using pddi

This generates a really long single line, potentially with sensitive data included about my project. How shall I proceed?
The machine it runs on is same as reversed binary, i.e. riscv64.

[strlcat]

I generated one for random riscv64 binary on my system here: https://rys.strlcat.eu/pddi.json.xz

[wargio]

I generated one for random riscv64 binary on my system here: https://rys.strlcat.eu/pddi.json.xz

i get a 403. can you just upload it here?

[strlcat]

There's still problem with construct like:

lui a4, 0x80010
sw a4, 8(s0)

gives me

a4 = 0x0;
*((s0 + 0x8)) = a4;

but shall be

a4 = 0x80010000;
*((s0 + 0x8)) = a4;

(if assuming uint32_t, I don't know how typing here works, for uint64_t it shall produce 0xffffffff80010000)
I don't know how to solve it right now, so notifying you.

[wargio]

true. the sign should extend