[LLVMdev] Implementing the ldr pseudo instruction in ARM integrated assembler

[Jim Grosbach]

On Nov 1, 2013, at 1:34 PM, David Peixotto <dpeixott at codeaurora.org> wrote:

>> There's still a problem for Darwin, or any other platform that use
>> subsections-via-symbols type layout tricks, though. There's no assembler-
>> time way to know how far apart the atoms in the section will be at
>> runtime, as the linker can, and will, move things around.
> 
> Hmm, yes that does sound quite tricky. How do we currently deal with that
> for other pc-relative loads. Say the programmer writes something like this
> 
> _foo:
> 	ldr r1, [pc, #392]
> _bar:
> 	.space 200
> _baz:
> 	.space 200
> _some_important_constants: .word 0x12345678
> 
> If bar and baz get deleted by the linker the offset would obviously be
> wrong. Do we do anything special for this or just rely on the programmer not
> to write this code?

That code is basically undefined behaviour with subsections-via-symbols. PC-relative loads can’t cross atoms. This is why, for example, that all labels inside a function must be assembler-local labels. You’ll see all sorts of “interesting” code sequences and relocation tricks for pc-relative stuff.

> 
>> We could, perhaps, always require an explicit directive for all constant
>> pools when using subsections-via-symbols and add a diagnostic check at the
>> end of parsing (when we're spitting out the non-empty pools) to see if
>> there was a subsections-via-symbols directive in there anywhere.
> 
> This seems to be a reasonable choice. It seems it would still be difficult
> to detect all the cases where we could run into trouble. For example,
> something like
> 
> _foo:
>  ldr r1, =0x12345678
> _bar:
>  ...
> .ltorg
> 
> If bar gets deleted we would still have the wrong offsets.

Yeah, that would need to be illegal as well. Fun times…

It sounds like this is getting constrained to a pretty reasonable set of features for the assembler to deal with. It’ll definitely be a good usability thing and will make lots of existing code a lot happier with clang, which is a good thing. Thanks for taking on the challenge and working on it.

-Jim

> 
>> Anyways, the main point of all of this is to reinforce the "there be
>> dragons here" nature of this feature. It interacts with other parts of the
>> assembler and the underlying assumptions of the platform in interesting
>> ways. Lots of *really* careful test cases will be necessary.
> 
> Yes I see your point. Thanks for brining .subsections_via_symbols to my
> attention.
> 
>