Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assembler - %hi relocations are sometimes broken #70

Open
Souzooka opened this issue May 19, 2020 · 2 comments
Open

Assembler - %hi relocations are sometimes broken #70

Souzooka opened this issue May 19, 2020 · 2 comments

Comments

@Souzooka
Copy link

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

@rickgaiser
Copy link
Member

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.

Information on how to compile can be found here:
https://www.psx-place.com/threads/wip-updated-homebrew-toolchain-for-ps2.20539/

@fjtrujy
Copy link
Member

fjtrujy commented Jan 12, 2021

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?

If this is the case, can you create the issue in the repo
https://github.com/ps2dev/ps2toolchain-ee

Thanks

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants