public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Matheus Afonso Martins Moreira <matheus.a.m.moreira@gmail.com>
To: binutils@sourceware.org
Subject: Feature request: spare program headers
Date: Fri, 17 Nov 2023 21:18:21 -0300	[thread overview]
Message-ID: <a14576df198e1ebe98e3028fed9205b3@gmail.com> (raw)
In-Reply-To: <765a162a-e44d-45c2-95d0-28c0ca47114f@hogyros.de>

> You can specify PHDRs in your linker script.

That's true but I ran into complications
when I tried to use the PHDRS directive.
I described my attempt in a previous email:

https://sourceware.org/pipermail/binutils/2023-November/130561.html

> 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

Perhaps it is possible to do it via linker script
but I couldn't get it to work no matter what I tried.

It's also not possible to do *only* this.
Using PHDRS disables the linker's defaults
and forces users to specify all the segments.

https://sourceware.org/binutils/docs-2.41/ld/PHDRS.html

> The linker will create reasonable program headers by default.
> When the linker sees the PHDRS command in the linker script,
> it will not create any program headers other than the ones specified.

As a result of inhibiting those defaults, it also requires us to map
all the sections to all the custom segments we created instead of
simply letting the linker do it. The result is we have to maintain
customized copies of the linker's default scripts in our repositories.

An option that adds PT_NULL segments would be much easier to use.
Custom post processing tools can later customize those segments
with much greater flexibility after the link. I just implemented
such a tool for my project.

      reply	other threads:[~2023-11-18  0:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-17  3:23 Matheus Afonso Martins Moreira
2023-11-17  8:08 ` Simon Richter
2023-11-18  0:18   ` Matheus Afonso Martins Moreira [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a14576df198e1ebe98e3028fed9205b3@gmail.com \
    --to=matheus.a.m.moreira@gmail.com \
    --cc=binutils@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).