Plans for ARM support?

[psparc82]

Thanks for the project. Do you have any plans to support exporting ARM programs to ELFs?

[boricj]

Sure, the extension is designed so that support for new ISAs and object file formats can be easily added. For this specifically, it'll require at least the following modifications:

• Adding an analyzer for that instruction set (hopefully it can leverage most of the generic analysis code already in place).
• Adding ARM-specific bits to binary-file-toolkit (mostly spec-mandated constants).
• Adding an ARM relocation table builder for ELF (to project the extension's relocation table to that ISA/object file format combo).
• Add a couple of lines to the ELF exporter to hook up ARM.

I'd say the most important thing is whether the ISA uses atomic or split relocations. If it's the former then all is good, it's straightforward to analyze. If it's the latter... well, let's not worry about what lurks within my MIPS analyzer just yet.

I do have a concern about the size of the extension's support matrix. Specifically, it's getting rather hard to keep juggling in my head all of the minutiae about delinking across it. It's nothing that egregious amounts of regression testing can't soothe, I just need to come to terms with the fact that this extension has already snowballed way beyond what I can handle alone. After all, there are far too many ISAs, object file formats and platforms out there for me to keep track of it all.

I guess what I mean is that I'm happy to answer questions, review stuff and merge contributions, but I'm not going to spearhead the development of features that I do not directly use.

Just to be sure, by ARM what do you mean exactly?

• ARM, the original old-school 32-bit instruction set?
• Thumb?
• Thumb-2?
• Aarch64?
• Jazelle? (I hope not)
• Any combination of the above?

Also, for what platform? I assume it's little-endian, but if it's big-endian then my extension hasn't been exercised much in that area (I did a whole bunch of endianness fixes back when someone asked about IRIX, but that's about it).

[psparc82]

OK, so there's a fair amount of work to be done to support a new ISA which sounds challenging. Ideally support for ARM, Thumb and Thumb-2 targets would be fantastic as they are widely used. I don't think I'll be able to provide an intial stab at implementing this but hopefully someone with better programming skills than me could :)

[boricj]

OK, so there's a fair amount of work to be done to support a new ISA which sounds challenging.

Honestly, I don't think it will be that bad. In the case of ARM, it might be even easier than most architectures I think.

There's a generic relocation synthesizer for absolute data, so constant pools should be already handled. In fact, the relocation synthesizer analyzer should be able to properly process all pointers out of the box, even without actual ARM support. I'd expect that the only thing an ARM analyzer would actually need to do is to process branch instructions, it might end up even shorter than the x86 analyzer: https://github.com/boricj/ghidra-delinker-extension/blob/master/src/main/java/ghidra/app/analyzers/relocations/X86CodeRelocationSynthesizer.java

The exporter doesn't really require much work either. The relocation table builder is just some straightforward glue code that hooks up the generic relocation table data model to binary-file-toolkit, like the one for x86: https://github.com/boricj/ghidra-delinker-extension/blob/master/src/main/java/ghidra/app/util/exporter/elf/relocs/X86_32_ElfRelocationTableBuilder.java

Overall, I'd expect a bare-bones, proof-of-concept support for ARM would probably take less than 300 lines of diff to accomplish and most of these would be copy-pasted. Handling all the features and adding all the tests for a high-quality implementation is another matter of course.