Alex

the issue is really in jwasm, it generates roughly "undefined behavior". old binutils just happens to interpret it one way, and new binutils interprets it another way. in terms of other projects, any programs using jwasm family assemblers to access array constants will encounter the issue. i sent https://sourceware.org/pipermail/binutils/2022-April/120428.html to discuss workarounds in binutils, but no replies yet. the proper solution would be to fix jwasm to emit proper relocation.

all jwasm-family assemblers (jwasm, asmc, uasm) appear to generate the wrong relocation. binutils 2.37 and greater has the changed behavior. you can see the binutils versions of various distros at https://repology.org/project/binutils/versions. so if you like ubuntu, you can see the broken result by upgrading to ubuntu 22.04. I used Sha*Opt.asm in Windows because old MSVC compilers do not support Sha instructions. just wondering, why do you need to use old MSVC? is it for some users which are embedding...

i wonder if Sha*Opt.asm can be removed? it seems basically same speed as C intrinsics version with gcc. is it faster on your machine?

following patch "resolves" issue: --- Asm/x86/Sha256Opt.asm.old 2022-04-15 16:17:04.301518160 -0400 +++ Asm/x86/Sha256Opt.asm 2022-04-15 16:21:16.744220724 -0400 @@ -171,7 +171,7 @@ RND4 macro k - movdqa msg, xmmword ptr [K_CONST + (k) * 16] + movdqa msg, xmmword ptr [rax + (k) * 16] paddd msg, @CatStr(xmm, %(w_regs + ((k + 0) mod 4))) MY_sha256rnds2 state0_N, state1_N pshufd msg, msg, 0eH @@ -213,6 +213,8 @@ cmp rNum, 0 je end_c + lea rax, [K_CONST] + movdqu state0, [rState] ; dcba movdqu state1,...

ok, i found "root cause". both jwasm and asmc emit wrong relocation: they use rela format relocation but put offset in instruction stream and constant -4 in relocation table. earlier versions of binutils accomodated this by adding value stored in instruction stream (should be always 0), but new binutils (i am using 2.38) ignores value in instruction stream. this happens to still work properly as long as offset = 0 (scalar value) but is totally broken for array values: the program will always retrieve...

upon further research (i.e. i asked on #musl), rela uses the addend in the relocation table and overwrites the value in the file. so this generated table is totally wrong for rela. the question is how it works on your system. what linux are you using? can you show readelf -r Sha256Opt.o and objdump -d -Mintel Sha256Opt.o?

upon further research (i.e. i asked on #musl), rela uses the addend in the relocation table and ignores the addend in the file. so this generated table is totally wrong for rela. the question is how it works on your system. what linux are you using? can you show readelf -r Sha256Opt.o and objdump -d -Mintel Sha256Opt.o?

does original precompiled binary 7zz or 7zzs work correctly? seems to work ok in quick tests. I think I am getting close to finding root cause. I did extremely stupid "traced execution" by breaking in Sha256_UpdateBlocks_HW, setting gdb to display $pc and $xmm* on each break, then entering "si" and holding down enter key. I found that both executions start with ok parameters, but different xmm registers, so i forcibly set xmm* of broken run to ok run values (should be ok because no floating point...