[PATCH] switch ARM modes in inline asm

[Renato Golin]

On 25 November 2013 20:43, Greg Fitzgerald <garious at gmail.com> wrote:

>   I'm starting to think that fixing this bug is a bad idea and that
> reporting an error might be more appropriate.  Fixing the bug opens up a
> can of worms.  Say the user's inline assembly doesn't return to thumb mode.
>  Should the compiler inject the $t mapping symbol?  Should it inject a
> ".code 16" directive?  Should it inject a label and adr to switch back to
> thumb mode?  Where do we draw the line?
>

I think it all depends on the kind of things the user does. The bottom line
is: you should keep the asm/object consistent, which means you'll have to
insert as much boilerplate code as needed (but nothing more) to keep it
working. Since the user can do unimaginable things in inline assembly,
you'll have to either be ultra-smart, or start cutting their wings with
warnings/error messages.

Where you draw the line is just a matter of priorities. Implement what you
need and err what you don't support, yet. ;)


  Also, my test is fragile.  That $a shouldn't be displayed by llvm-objdump
> (and isn't by GNU's objdump).  Also, the CHECK-NEXT assertions are checking
> those bytes in the context of thumb instructions.  Instead there should
> just be one CHECK that matches all 4 bytes on one line.
>

$a, $t and $d symbols are only printed on the assembly output, not the
object file. If objdump recognizes the areas as thumb/arm/data, it *may*
print them back, but they're not in the object itself. This is why
disassembling ARM objects from an arbitrary point is not the easiest of
tasks. If your test was done in asm output, it could be easier to create
the CHECK lines.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131126/509be910/attachment.html>