Re: Appending program headers to existing ELFs?

[Matheus Afonso Martins Moreira <matheus.a.m.moreira@gmail.com>]

Hello Nick,

> Why can't you add the data at link time ?

I'd like to add a section to the executable
that users can freely modify after the binary
has been built and distributed without needing
to recompile or relink anything.

In concrete terms:

I'm building a small programming language interpreter
and would like to add support for embedding programs
into the executable. My intention is to treat the
embedded programs section as an additional load path
for libraries and modules as well as the main function.

> could you create a new symbol for the section
> and reference the data that way

That is indeed possible but as you noted
it would require access to the symbol table
at runtime and that's not guaranteed.
That information may have been stripped away
and the kernel does not load it to begin with.
I'm also not using libc so I don't have access
to dlopen and dlsym.

> At the moment this can only be done by the linker

I see. I suspected as much but hoped there would be a way.
Thanks for clarifying that.

> With a linker script you can layout a PHDRS structure

Yes. It's one of the solutions I tried.

I copied ld's internal linker script
and customized it with a PHDRS command:

    PHDRS
    {
        headers PT_PHDR FILEHDR PHDRS;
        text PT_LOAD;
        rodata PT_LOAD;
        data PT_LOAD;
        bss PT_LOAD;
        extra PT_LOAD; /* meant to be empty */
                       /* size/offset will be set later */
    }

I was not successful. I keep getting the following error:

    error: could not allocate headers

I was unable to determine the cause and fix it.

For ease of maintenance, I don't intend to mess with
the sections and segments generated by the GNU tools.
I would have liked to merely append a custom header
to the ones generated by ld. Unfortunately, merely
including a PHDRS command disables ld's program header
generation logic which sensibly maps the sections
to the headers.

A linker script directive that applies defaults
while allowing further customization would be
a great new feature.

In the meantime, I'm trying to work around the problem
by placing a statically allocated packed structure
into an isolated section so that its entire contents
can be overwritten by objcopy:

    objcopy --update-section .structure=./file
            lang lang+file

This reduces the problem to a binary file format problem
and seems like the way forward for me at the moment.
Would have been nice to be able to reuse the ELF machinery though...

Thanks for the guidance,

    Matheus