llvm dev - Jan 2012 - [LLVMdev] exposing container-specific features in the Object library

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>