[llvm-commits] ARM ELF disassembly with integrated-as

[Jim Grosbach]

On Nov 28, 2012, at 2:27 AM, Tim Northover <t.p.northover at gmail.com> wrote:

> Hi Greg,
> 
> Thanks for working on this.
> 
>> I could use some help creating a test case for adding mixed-mode support.
>> Adding EmitAssemblerFlag() as Tim suggested was no problem, but creating a
>> test case that gets llc or llvm-mc to generate a file with both Thumb and
>> ARM data sections is.
> 
> I think the llc approach is doomed to failure for now. CodeGen just
> doesn't produce mixed ARM and Thumb code. That's OK though.
> 
> As for llvm-mc, I agree it doesn't seem to emit the required
> DataRegion directives. However, temporarily hacking that into the easy
> places (EmitDataRegion just before EmitValue and EmitInstruction in
> ARMAsmParser) reveals a possibly bigger problem with the approach
> taken.


The assembler shouldn't be inferring anything about data regions. It should be following the directives given it (that's why the new .data_region directives are there).

> 
> Basically, you can't know that the first symbol emitted in a section
> will be a code one until you've got an instruction or .word (etc) in
> front of you, so ChangeSection is too early to actually emit it. For
> example an assembly file like:
>    .text
>    .word 42
>    add r0, r0, r0
> should produce a mapping symbol $d at offset 0, and $a/$t at offset 4.
> I think this is impossible with the patch as it stands.
> 
> As well as ARMAsmParser.cpp, I think parts of
> lib/MC/MCParser/AsmParser.cpp will need to know about the regions
> since they handle directives like .byte, .ascii, …

What am I missing? No changes should be necessary to any of these. The directives (or magic $t/$a/$d symbols in your case) control everything.


> 
> Cheers.
> 
> Tim.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits