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
0x03FFFFFE masks all but the middle 25 bits and yields a 2-byte aligned address. I may be missing something, but it looks like it's simply a typo for 0x03FFFFFC, which yields a 24 bit value with 4-byte alignment.
The text was updated successfully, but these errors were encountered:
This is my interpretation. I'll try and check with the original author of the document to see if I've missed anything.
Looking at the table. The intent is to calculate Result_Mask. The X is the 32-bit result of normal relocation processing is the result of ((S + A) | T) - P. Result_Mask is (X & 0x03FFFFFE). We then need to look up what to do with Result_Mask in Arm relocation actions by instruction type.
For B, BL<cond> , BL, BLX the Result_Mask is, strictly speaking, not used. Instead we have a special case See Call and jump relocations . This section talks about the various requirements for interworking between Arm and Thumb, including changing a BL to BLX and adding veneers/thunks, but is not specific about encoding the results. This requires looking at the Arm Architecture Reference Manual and deriving what needs to be done from the encodings.
Going back to the relocation mask I think there's two separate cases: R_ARM_CALL (unconditional BL, BLX) can target Thumb instructions, which are 2-byte aligned. If the target is Arm the relocation must ensure that a BL is written with the immediate 4-byte aligned. If the target is Thumb the relocation must ensure BLX is written with the immediate 2-byte aligned. 0x03FFFFFE works for both of these cases, although more precisely it could be "0x03FFFFFE for Thumb destination, 0x03FFFFFC for Arm destination".
For R_ARM_JUMP24 which can only target Arm instructions I agree that 0x03FFFFC would be better.
As mentioned above, I'm not sure if the Result_Mask is that useful. I think it could be used to derive an alignment check, but in that case it would be better to mention that directly in the call-and-jump-relocations section.
ARM32 ELF psABI defines that the result mask for
R_ARM_CALL
andR_ARM_JUMP24
relocations is 0x03FFFFFE (search for0x03FFFFFE
in https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst). But isn't that a typo for 0x03FFFFFC?R_ARM_CALL
andR_ARM_JUMP24
are used forB
,BL
andBLX
instructions whose immediate size is 24. You can see the instruction format at https://developer.arm.com/documentation/ddi0597/2024-12/A32-Instructions-by-Encoding/Branch--branch-with-link--and-block-data-transfer?lang=en.0x03FFFFFE masks all but the middle 25 bits and yields a 2-byte aligned address. I may be missing something, but it looks like it's simply a typo for 0x03FFFFFC, which yields a 24 bit value with 4-byte alignment.
The text was updated successfully, but these errors were encountered: