#15122: arm linker relocation issues
----------------------------+----------------------------
Reporter: kallisti5 | Owner: bonefish
Type: bug | Status: new
Priority: normal | Milestone: Unscheduled
Component: Build System | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 0 | Platform: arm
----------------------------+----------------------------
Changes (by simonsouth):
* platform: All => arm
Comment:
The underlying issue is that gcc is [https://git.haiku-
os.org/buildtools/tree/gcc/gcc/config/arm/haiku.h?id=56d94c3a719296abace2ace7ad80aa45a95bd86a#n71
configured at build time] to request ld use its standard armelf emulation
rather than Haiku's own variant, [https://git.haiku-
os.org/buildtools/tree/binutils/ld/emulparams/armelf_haiku.sh?id=56d94c3a719296abace2ace7ad80aa45a95bd86a
armelf_haiku].
Among other things this means
[https://sourceware.org/binutils/docs-2.32/ld/ARM.html#index-TARGET2 the
TARGET2_TYPE linker option] isn't being set, causing ld to transparently
map R_ARM_TARGET2 relocations to R_ARM_REL32 (the built-in default,
apparently). This effectively specifies static relocation, which
presumably is why ld suggests recompiling with -fPIC: If it finds a symbol
can't be relocated it must assume the code was built without relocation in
mind.
Since Haiku always provides dynamic relocation at runtime R_ARM_TARGET2
should instead map to R_ARM_GOT_PREL, one of the things the armelf_haiku
emulation specifies.
Fixing gcc's build configuration and rebuilding the cross-tools allows the
ARM build of Haiku to complete, and seems to reduce the number of compiler
warnings, too.
I'll upload a patch shortly but the only change is to modify [https://git
.haiku-
os.org/buildtools/tree/gcc/gcc/config/arm/haiku.h?id=56d94c3a719296abace2ace7ad80aa45a95bd86a#n71
gcc's LINKSPEC] to specify "-m armelf_haiku" instead of "-m armelf".
--
Ticket URL: <https://dev.haiku-os.org/ticket/15122#comment:4>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.
