Sorry, I have been very behind on patch reviews. Bob and Jim, do you have any opinions about this?
Evan
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.
On a minor note:
You probably want dyn_cast<> instead of cast<> so you can do something like:
if (const MCSectionELF* SectionELF = dyn_cast(Section)) {
// …
}
-Jim
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.
cheers,
--renato
On the BuildBot results, I see just one ARM Build Slave -- ranby1. It's for an armv5tej1 machine.
How do the other arm instructions sets get tested? Are there test results produced by something other than BuildBot? I don't see any on the llvm-test mailing list.
I might be able to provide resources for testing if needed (as per http://llvm.org/docs/TestingGuide.html)
Thanks much!!