[LLVMdev] Adding fixups and relocations late in code generation

[Jim Grosbach]

On Oct 10, 2011, at 11:41 AM, Carter, Jack wrote:

> Jim,
> 
> Both the branch and the branch target are in the same function. This is known delta and should not matter where it is relocated because the delta will remain the same once it is a .o or later.

OK. You're likely falling into the case in EvaluateFixup() that contains:
        IsResolved =
          getWriter().IsSymbolRefDifferenceFullyResolvedImpl(*this, DataA,
                                                             *DF, false, true);
 
Double check that and step through in a debugger and see why it doesn't think the expression is resolved.

> I just want to know how to tell the compiler that this expression is target offset - branch offset.
> 
> More generally, I want to know the rules for setting up expressions in general. I have no idea if one uses post fix, in fix or pre fix.

What do you mean? An MCExpr is a tree. We generally print the tree using an infix traversal, but that's not related to the representation.

See MCExpr.h and associated files for the details.

> How does one layer different relocations? This will really come in to play for embedded assembler where the gentle user can be as perverse as they want with expressions, resulting with possibly multiple relocations and an immediate for a given instruction operand.
> 

This is all going to be very target specific, and is typically handled in the ResolveRelocation() hooks. The x86 backend is probably the best place to look for examples. ARM currently represents fixups in a pretty messed-up way, so I wouldn't look there for this part of things.

> Is expression layering described in the documentation anywhere?

Nope. :(


-Jim

> Cheers,
> 
> Jack
> ________________________________________
>> 
>> Later in MipsAsmBackend.cpp:ApplyFixup() I find the value is the offset
>> of the target value from the beginning of the section and not the delta
>> from the branch address.
>> 
> 
> I'm not sure I follow. Wouldn't that still require a relocation from the start of the section?
> 
>> I also get a relocation request even though the label should be
>> resolved.
>> 
> 
> The logic for which cases are considered resolved and which require relocations is in MCAssembler::EvaluateFixup(). It's currently not factored all that well, with some target-specific knowledge embedded in the generic code. It's entirely possible we need to create a target hook there to handle any special cases.
>