[PATCH] Add support for parsing ARM symbol variants on ELF targets

David Peixotto dpeixott at codeaurora.org
Mon Dec 2 13:34:05 PST 2013


> Hi David,
> 
> > ARM symbol variants are written with parens instead of @ like this:
> >
> >   .word __GLOBAL_I_a(target1)
> 
> I don't think this is universally true. At least Joerg today was talking
> about an @GOT symbol that we didn't support.

The underlying problem that I'm trying to solve is to have the integrated
assembler be able to parse its own output. The symbol above appears in any
c++ program that includes iostream and so I was seeing a large number of
failures when parsing assembly files generated by the integrated assembler.

Do you mean that we should support using @ to specify the variants instead
of using ()? It currently does not work, but I think we could do this by
modifying the printer to use @ to print the variant and the parser to use @
for the arm variants as well. The parser would need to be modified to return
the arm variant instead of the generic variant (e.g VK_ARM_GOT instead of
VK_GOT). There is a comment in MCExpr.h that says it would be nice to use
the generic variant, but I'm not sure exactly what the difference between
the two are.

I just tried a small example with gcc-4.6, and it produces a R_ARM_GOT32 for
bar(got), and a R_ARM_ABS32 for bar at got. It looks like gcc just treats the @
as a comment, but our lexer currently will include @ in the symbol name.

> Separately I think the relocation in the @PLT case is dodgy.
> R_ARM_PLT32 is deprecated according to the ARM ELF ABI. R_ARM_CALL should
> be used instead (much like R_ARM_THM_CALL is used in the thumb case). I'd
> advocate this regardless of what binutils did, but it appears my copy of
> binutils-2.23 agrees.

I see that we already generate the R_ARM_PLT32 relocation for pic calls in
ARM. My patch just parses the variant and creates the symbol with a variant
kind of VK_ARM_PLT. For ARM this generates a an R_ARM_PLT32 relocation and
for thumb it generates R_ARM_THM_CALL.

I'm not opposed to changing that behavior, but I think it is a separate fix
from my patch.





More information about the llvm-commits mailing list