[LLVMdev] [PATCH] ARM MC relocations

Renato Golin renato.golin at arm.com
Thu Jun 17 01:34:06 PDT 2010

On 17 June 2010 00:06, Jim Grosbach <grosbach at apple.com> wrote:
> Is there a way to handle this entirely in the ARM AsmPrinter bits? Adding
> pieces to the generic MC stuff feels a bit like overkill at first
> impression.

Hi Jim and Evan,

At first, I thought I could do that, but it is MCAsmStreamer that is
printing the final value of most symbols together with their EOL. So,
unless I start using rewinding streams or print the symbols myself, I
can't see other way.

I could add a call-back there, instead of calling it
Relocation->print(OS), call it TargetSpecific->prePrint(OS) and
posPrint(OS), just before and after printing the value. Or even make
them simple methods in ARM/MCAsmInfo, but then it'd be more than just
"info" in there. Or have a reference on MAI to the target's asm
printer, that might be the easiest, non-intrusive change...

Also, I noted all relocation is dealt with by the backend. Just like
GCC ignoring Clang's exception table completely or assigning the
correct relocation information even when no information is available
in the asm file. I understand that there are some default values we
can omit from the assembly output (initialisation areas are one
example of that), but when you start using multiple tool chains to get
stuff done, it's better be explicit than rely on "defaults".

In that example, for instance, I compiled with clang to IR, llc to
asm, gcc to object and armlink to executable. Most of the examples I
tested worked fine, but the missing relocation information made it
difficult to interoperate.

> You probably want dyn_cast<> instead of cast<> so you can do something like:
> if (const MCSectionELF* SectionELF = dyn_cast<MCSectionELF>(Section)) {
>  // ...
> }

Precisely. I didn't want to use c++ dynamic_cast directly, but I only
found out about dyn_cast after I sent the patch. Apologies.


More information about the llvm-dev mailing list