[RuntimeDyld][ELF] Unwanted sign-extension when computing stub addresses.

[al45tair]

The RuntimeDyldELF implementation tries to make a stub, it uses an expression like

reinterpret_cast<uint64_t>(Section.getAddressWithOffset(Section.getStubOffset()))

to get the address of the stub it's generating as a uint64_t.

Sadly, on 32-bit platforms where addresses are regarded as signed, because getAddressWithOffset() returns a uint8_t * pointer, this can cause unwanted sign-extension, so if (for instance) the code has been loaded at 0xf1a10000, and the stub is at offset 4, the resulting uint64_t will be 0xfffffffff1a10004 instead of the expected 0xf1a10004.

[DavidSpickett]

I tried to reproduce this issue on Arm 32 bit and couldn't so -

Sadly, on 32-bit platforms where addresses are regarded as signed

Makes sense here.

In Arm's 32 bit ABI it notes that "Pointer arithmetic should be unsigned." (https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst). So this will be why it didn't show up on that platform.

[al45tair]

I tried to reproduce this issue on Arm 32 bit and couldn't so -

Sadly, on 32-bit platforms where addresses are regarded as signed

Makes sense here.

In Arm's 32 bit ABI it notes that "Pointer arithmetic should be unsigned." (https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst). So this will be why it didn't show up on that platform.

Yeah, @mgorny noticed it on 32-bit x86, where they are treated as signed. In that case, it caused my new test for cross-section branches on AArch64 to fail with an assertion failure, because of the unwanted sign extension. I'm raising a PR to fix the problem at the moment.

[al45tair]

(See the comments on the end of #92245.)