[LLVMdev] R_ARM_ABS32 disassembly with integrated-as

Renato Golin rengolin at systemcall.org
Sun Oct 7 03:14:15 PDT 2012


On 5 October 2012 17:48, Jim Grosbach <grosbach at apple.com> wrote:
> The recent MachO data-in-code support should have fixed a lot of the problems. There's probably still some quirks in the specifics ($a vs. $t and making sure the symbols get into the ELF properly), but the core functionality to know how to mark data regions is there and works very well.

Hi Jim,

I'm trying to help Greg crack it down. From your recent commits, I
take it you're re-using a data-in-code detection previously used only
for ASM output, to object output, via the
EmitDataRegion/EmitDataRegionEnd.

I haven't looked too deep in the MC, but I'm supposing that will work
automatically when the output streamer is printing object code and
meets a non-code region, so in theory, changing MCELFStreamer
accordingly (overriding those functions in there) would take care of
data vs. code issue in ELF.

Assuming LLVM doesn't generate ARM/Thumb veneers inside the same
function (ie. a Thumb function has only Thumb code), Greg could use
the EmitDataRegion and EmitDataRegionEnd, with the former saving the
state of the current code (Thumb/Arm) and the latter restoring it, by
emiting the $d and $a/t respectively.

Does it seem like a good initial approach?

Continuing... It seems MCELFStreamer already has a EmitThumbFunc,
which looks to me as the wrong place to be. I'd imagine MCELFStreamer
would have EmitFunc and MCARMELCStreamer (or whatever) would identify
its type and call the appropriate EmitThumbFunc/EmitARMFunc. Being
pedantic, even that is still too high level because of the ARM/Thumb
veneers, but we don't want to worry about that if LLVM doesn't even
try to mix ARM and Thumb (and assuming external libraries would have
the symbols, if they do).

Generating or not, LLVM's disassembler should know about those symbols
and should be able to mark them accordingly. Where would be the best
part to put those symbols (in an enum or table), so that the
MCStreamer and the disassembler could reference a single place?


-- 
cheers,
--renato

http://systemcall.org/




More information about the llvm-dev mailing list