[LLVMdev] exposing container-specific features in the Object library

[Bendersky, Eli]

Hello,

The ObjectFile class (in Object/ObjectFile.h) presents a format-independent interface for object files. In addition, for COFF and MachO, some internal format details are exposed in special headers. For example, Object/COFF.h exposes coff_file_header and coff_symbol. Object/MachOFormat.h exposes headers, "segment load commands" and so on.
ELF, however, is not exposed and completely hidden behind the ObjectFile.h interface.
My questions is - what is the reasoning behind this design, which apparently takes 2 different approaches. Is the intention to eventually have everything hidden like in the ELF case, or selectively exposed, like for COFF and MachO?

The motivation for my question is a dynamic loader in MC-JIT for ELF. The current RuntimeDyldMachO uses structures exposed outside the ObjectFile interface (for example, macho::SymtabLoadCommand) to do its work. When working on RuntimeDyldELF, I encountered some cases of Elf information I need which wasn't exposed through the ObjectFile interface. Adding additional getters to that interface requires to implement them in COFF and MachO object files as well (perhaps returning "not_implemented" error codes).

So, I'm wondering whether the right approach here is to keep everything behind the ObjectFile interface, or just expose some ELF specific structures via a header file and use those? After all, this is in code that is specifically meant to handle ELF files, so it makes some sense to have a better understanding of ELF for such code, and not only a generic understanding exposed through ObjectFile.

Thanks in advance,
Eli

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120104/2db1e8a9/attachment.html>