Hi everyone, happy new year.
This note is to announce that support for PC relative reloc tags for
movw/movt is nearing completion (hopefully <48hrs!). This work is is
from Jan Voung, David Meyer and myself.
Unfortunately, to test this change, we need to patch ARM/AsmParser to
address http://llvm.org/bugs/show_bug.cgi?id=8721
Locally, we have hacked up a solution to 8721, but its not ideal since
VK_ARM_HI16 and VK_ARM_LO16 should apply to any MCExpr, not just
MCSymbolRef like it is now.
The proper fix to 8721 looks to be nontrivial, so what I will do is
commit the "hack" patch to 8721 separately, and then the main patch,
as 8721 is blocking the testing.
The interim hack for 8721 can then be rolled back separately once
someone (ddunbar? pdox? me? 
get around to refactoring MCExpr so
that :lower16: and :upper16: can apply to arbitrary expressions.
Thanks
-jason
Hi Jason,
Happy new year!
That seems a long patch... with many changes... can't wait for it. 
Btw, I know this is for ELF printing, but can the same infrastructure
you're using to print the hi/lo be used to print relocation in Asm
output? Or is this a completely separate subject?
cheers,
--renato
-llvmcommits
Btw, I know this is for ELF printing, but can the same infrastructure
you're using to print the hi/lo be used to print relocation in Asm
output? Or is this a completely separate subject?
Hi Renato,
If I am understanding you correctly, then the answer is no, because .s
output doesn't care about relocations per se... BUT..
its also yes because sometimes, the asmwriter will sometimes need to
generate sequences like below
foo:
movw r0, :lower16:bar-foo
movt r0, :upper16:bar-foo
The subtraction implies that the value bar-foo is implicitly
pc-relative (at least according to GNU as).
Thanks!
-jason
If I am understanding you correctly, then the answer is no, because .s
output doesn't care about relocations per se...
Hi Jason,
That's not entirely true. If you only use the GNU toolchain, that
is correct. However, CodeSourcery's GCC changed a bit on how it works
for ARM because the ARM toolchain is a bit more strict in build
attributes and relocation information.
The static constructor symbol relocation (target1) and exception
handling table symbols (prel31) are clearly disregarded by gas and
subsequently discarded by armlink.
its also yes because sometimes, the asmwriter will sometimes need to
generate sequences like below
foo:
movw r0, :lower16:bar-foo
movt r0, :upper16:bar-foo
The subtraction implies that the value bar-foo is implicitly
pc-relative (at least according to GNU as).
That was the other part of my question: will your new
MC-relocationator also print the current ASM relocations?
cheers,
--renato
That was the other part of my question: will your new
MC-relocationator also print the current ASM relocations?
Doesn't look like AsmParser understands RELOC command yet. Sorry:-(