R_68K_PC32 and m68k

[Kalamatee]

Describe the bug Recent versions of binutils/gcc started generating code with R_68K_PC32 on m68k. Elf2Hunk tries to use RELRELOC32 to store these - however RELRELOC32 can only handle 16bit offsets and upto 65k relocations per hunk.

This breaks in many places on aros including -:

Linking the ROM, uses offsets over the supported size for RELRELOC32. Linking many c++ objects (e.g. Mesa) fail due to having offsets over the supported size.

To Reproduce Steps to reproduce the behavior: Compile AROS for m68k.

Expected behaviour Relocations are fixed up correctly.

Screenshots If applicable, add screenshots to help explain your problem.

Architecture

• Amiga (including UAE, Vampire cards)

CPU

• m68k

Version All using relatively new binutils versions.

Additional context Possible solutions include making Elf2Hunk use some other method of relocating R_68K_PC32

[thatguywiththekids]

I'll have a look at this. I can reproduce it with binutils 2.40. For instance: 3564 relocation(s) failed in HUNK #2421 of mesa3dgl20-0.library

[thatguywiththekids]

On second thought no. There are more pressing issues I want to address.

[thatguywiththekids]

A question relevant to this issue: Why convert mesa to hunk format? I don't see mesa being used in the bootstrap, and I would expect AROS to be able to load elf binaries.