hypothetical: headers inside object files

Discussion in 'C Programming' started by Alex, Mar 15, 2010.

  1. Alex

    Alex Guest

    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

    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?

    Would anything prevent a similar scheme being implemented for shared
    Alex, Mar 15, 2010
    1. Advertisements

  2. it is OT here, but oh well...

    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.

    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.

    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

    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...
    BGB / cr88192, Mar 15, 2010
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.