Alex said:
I'm sure this has been considered since the beginning of time so
please feel free to link me to where this has been previously
answered...
it is OT here, but oh well...
What would stop (in principle) one from including function prototypes
(in text format a-la header files) inside a text segment of an object
file (ELF or otherwise)? Obviously this would require a C compiler
that could be directed to a text segment of some .o file instead of
a .h file, and a linker that would know to ignore this text portion.
Is there anything that would prevent this in principle?
what would prevent this: the tools, ...
one would need, after all, a compiler that knows both how to produce such
files, as well as to look into the files.
Would anything prevent a similar scheme being implemented for shared
objects?
much better would be to not do it this way.
instead, better would likely be to make the library contain pre-cooked
metadata, similar to that found in .NET / CLI images.
advantages:
it would save space;
it would allow a faster compiler;
it would allow more easily interfacing with non-C languages.
now, for ELF-based shared objects, most likely people would try to kludge
this into being done with DWARF, if at all.
personally, I would rather see a separate format for metadata and debugging
info, mostly so that one can still have the metadata without the debugging
info (and, also, because DWARF would be overly complicated for the task
IMO).
for my uses, mostly on Windows, I had spec'ed out an idea for embedding
abitrary binary "chunks" into PE/COFF images (high on the list was for
metadata info in the form used in my VM, which is at present stored if files
separate from the DLL's).
the idea could be trivially adapted to ELF.
not that embedding arbitrary binary data in PE/COFF or ELF images is
difficult, but there is no real "standardized" way to do so. my strategy was
mostly to have a special section filled with "chunk headers" which are
followed by "chunk data", with the idea that the linker would naively put
them end-to-end during linking (the usage of a special section is not
strictly necessary, as this would still work even if they were put in the
".data" or ".rodata" section or similar...).
mostly, magic numbers and a header checksum are used to identify them, and a
FOURCC is used to identify the payload type. the interface for accessing
these chunks would be to use a function to query for a given FOURCC and
return a list of chunk pointers (likely all chunks of a given type within
the running process). (this would be implemented using the ToolHlp API on
Windows, or some libdl extensions on Linux).
along with this was the possibility of a WAD-like format (built on top of
the prior mechanism), which could also be embedded (all of the loaded WAD's
would combine their contents). this would still be intended for
special-purpose info though, not for general-purpose file storage (and would
probably not support directories or similar).
embedded ZIP could potentially support general-purpose file storage (note,
the mechanism and behavior would differ some in some notable ways from that
typically used in self-extracting archives).
....
or such...
