You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sometimes, GAS will produce incorrect instructions for %hi directives. I'm unsure of the exact cause,
but it seems there have been numerous relocation bugs addressed in future releases of GCC
(e.g. https://sourceware.org/legacy-ml/binutils/2006-11/msg00055.html for problems with global offsets).
Removing other relocations may fix the problem or cause new problems on different lines.
I've attached an input file which generates incorrect results for a couple %hi directives.
On line 399526, operation "lui $v0, %hi(dword_647648)" (dword_647648 being a symbol which is
located at address 0x647648 after assembly) will produce "lui $v0, 0x65" (located at 117800h in output).
The corresponding %lo operation, "sw $a0, %lo(dword_647648)($v0)", is assembled correctly ("sw $a0, 0x7648($v0)").
On line 400157, operation "lui $v0, %hi(byte_64764D)" (byte_64764D being a symbol which is located at address 0x64764D after assembly) will produce "lui $v0, 0x65" (located at 117F40h in output).
The corresponding %lo operation, "sb $zero, %lo(byte_64764D)($v0)", is assembled correctly ("sb $zero, 0x764D($v0)").
Notice that on lines 400152 and 400156, the hi bits of symbols immediately before and after
byte_64764D are loaded; however, these are accurately assembled as lui instructions with the immediate 0x64.
I'm assembling the file with the command "ee-gcc -o output.elf input.s &> output.txt -nostartfiles -nostdlib".
I'm curious what it is you're working on.... there's not many people diving in this deep.
As for the bug; I think we should focus on updating the toolchain to the latest gcc version. There's already a working gcc 11/master toolchain. Most is working, but a lot of exising ps2 libraries and applications are broken when switching from gcc 3.2.3 to gcc 11.
Hello @Souzooka,
We have recently updated the version of Binutils and GCC to the latest ones. Additionally, we have done a better layer separation in the toolchain, and now the EE toolchain is in a separate repo.
Can you double-check if this issue is still happening?
Sometimes, GAS will produce incorrect instructions for %hi directives. I'm unsure of the exact cause,
but it seems there have been numerous relocation bugs addressed in future releases of GCC
(e.g. https://sourceware.org/legacy-ml/binutils/2006-11/msg00055.html for problems with global offsets).
Removing other relocations may fix the problem or cause new problems on different lines.
I've attached an input file which generates incorrect results for a couple %hi directives.
On line 399526, operation "lui $v0, %hi(dword_647648)" (dword_647648 being a symbol which is
located at address 0x647648 after assembly) will produce "lui $v0, 0x65" (located at 117800h in output).
The corresponding %lo operation, "sw $a0, %lo(dword_647648)($v0)", is assembled correctly ("sw $a0, 0x7648($v0)").
On line 400157, operation "lui $v0, %hi(byte_64764D)" (byte_64764D being a symbol which is located at address 0x64764D after assembly) will produce "lui $v0, 0x65" (located at 117F40h in output).
The corresponding %lo operation, "sb $zero, %lo(byte_64764D)($v0)", is assembled correctly ("sb $zero, 0x764D($v0)").
Notice that on lines 400152 and 400156, the hi bits of symbols immediately before and after
byte_64764D are loaded; however, these are accurately assembled as lui instructions with the immediate 0x64.
I'm assembling the file with the command "ee-gcc -o output.elf input.s &> output.txt -nostartfiles -nostdlib".
input.zip
The text was updated successfully, but these errors were encountered: