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

Tim Northover t.p.northover at gmail.com
Thu Nov 29 12:31:55 PST 2012


Hi Jim,

> 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).

That's not actually what happens in ELF land (perhaps unfortunately).
Assemblers use the traditional data inserters to deduce where regions
begin and end, and there are no explicit data directives (depending on
how you classify .word etc).

>> 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.

The directives may control everything, but when some of those
directives are handled in AsmParser.cpp...

I wrote my part assuming the assembler would have to explicitly drive
the streamer to do that. Greg's patch today suggests that a
sufficiently intelligent Streamer might be able to do the job instead.
I think it would be a system completely independent of the DataRegion
code used by MachO though; I can't quite see how to make the two play
nicely together.

I'm also a little concerned about some equivalent of armasm's "DCI"
cropping up later; DCI inserts a given hex value, to be interpreted as
an instruction rather than data. If the ARMELFStreamer always took
EmitValue as a data, things could get complicated.

Tim.




More information about the llvm-commits mailing list