Closed unknown321 closed 8 months ago
Hi @unknown321, I like the code you've added here, but I don't see it used on the client side. What exactly is the purpose of adding this api endpoint?
When https://github.com/lief-project/LIEF/issues/213 is resolved, this endpoint could be used by client to build ELF without gcc.
Right now it is used by my client - https://github.com/unknown321/decompelf.
Since it doesn't cause any harm, I'm for merging it. Ideally, if you learn anything about better caching in your project, I'd appreciate the backport here since you'll be the main user of this API :).
Ideally, if you learn anything about better caching in your project, I'd appreciate the backport here since you'll be the main user of this API :).
There is no need to cache on client side at all; Ghidra has all tools to build ELF by itself (most likely with DWARF).
Possible implementation:
.text, symtab, strtab, shstrtab
sections, cache this object/get_elf
endpoint./changed
endpoint. If there were no changes, no need to download the binary.In fact, you can just slap new symbols into original binary without having to recreate elf from scratch.
This solves following problems:
check
and pull+load
functionsNot sure about DWARF, but as far as I can see, Ghidra has some utility to work with it.
However, this api will be unique to Ghidra only - no idea if other decompilers can produce binary with built-in tools (angr, binja, ida).
@unknown321 I'm not sure what your full use-case is, but maybe you would be interested in a tool more like this: https://github.com/cesena/ghidra2dwarf
It uses the Ghidra API to actually construct a DWARF (though it relies on libdwarf
to do the actual building). In general, I've stayed closer to the client machine constructing the ELF because the client may be running on a different arch than the decompiler. That is nearly always true for me at least: I debug on an x86 machine, but my host is arm.
This method provides info required to build ELF file accepted by gdb:
It also provides: