[LLVMdev] Possible issue with ARM/MC/MachO fixup

[Jim Grosbach]

On Jan 19, 2011, at 10:41 AM, Jason Kim wrote:

> Hi everyone.
> 
> In ARMAsmBackend.cpp, in routine DarwinARMAsmBackend::ApplyFixup()
> there is a curious call to getFixupKindNumBytes() - which can return
> 1,2, 3, or 4 depending upon the FixupKind
> 
> The code in ApplyFixup() seems to be lifted from the X86.
> 
> AFAIK, the initial Fixup.Offset() is always divisible by 4, at least
> for ARM mode - i.e. it is always at the instruction boundary.
> 
> it looks like adjustFixupValue() is meant to create a mask that can be
> bitwise OR'ed into the full instruction, which is 2 or 4 bytes
> So what does it mean to patch 1 or 3 bytes starting from the
> instruction boundary?
> 

It's just unused in the current implementation. The Fixup offset (the one that originates from the addFixup()) should always be zero.

> I don't know enough about Macho to tell whether this is a bug or not.
> If it isn't, apologies for the noise.

It's not a bug, per se, but the way the ARM fixups are handled needs some refactoring. The fixups shouldn't be quite as "smart" as they are and instead there should be one fixup per contiguous range of bits that need adjusted, and instructions with non-contiguous regions that need fixing up should use multiple fixups on the same instructions. In that situation, it'll be important to use the Fixup offset field to specify the starting byte for the fixup. Otherwise MC gets confused (it wants the fixups in order). The idea is that the adjustFixupValue() function will go away entirely and the MCExpr attached to the fixup will do all of the necessary value fiddling to get the right bits to apply to the instruction.

-Jim