From: Mark Wielaard <mark@klomp.org>
To: gnu-gabi@sourceware.org, binutils@sourceware.org
Subject: binutils ld and new PT_GNU_PROPERTY segment
Date: Wed, 01 Jan 2020 00:00:00 -0000 [thread overview]
Message-ID: <a7078f74881daf23ca4af4983bac212a6c971b5a.camel@klomp.org> (raw)
Hi,
binutils 2.32 ld emits a new PT_GNU_PROPERTY (PT_LOOS + 0x474e553)
segment that overlaps with the PT_NOTE segment covering the
.note.gnu.property section data.
I cannot tell if this is an accident/experiment that happened to end up
in a release or if it is proposed as an official new segment type.
As far as I can tell binutils ld is the only linker which adds this
extra segment and there is no runtime loader which uses it. It doesn't
provide any new information that cannot be found in the existing
PT_NOTE segment.
On 64 bit architectures it simply covers the extra existing PT_NOTE
with 8 byte alignment (normal PT_NOTE segments are 4 byte aligned). On
32bit architectures it covers a sub-range of the existing PT_NOTE
segment.
It isn't clear to me how other tools should handle this. It seems to
prevent normal merging of note sections. Since some notes are probably
special if they need to be covered by this new segment type. And it
isn't clear how the linker knows which of the SHT_NOTE sections is what
needs to be covered by the new segment type. Or is the idea that this
will eventually come with a new section type too and GNU properties
will no longer use NOTE sections?
Thanks,
Mark
next reply other threads:[~2020-02-18 12:38 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-01 0:00 Mark Wielaard [this message]
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` Fangrui Song via gnu-gabi
2020-01-01 0:00 ` Zhang, Annita
2020-01-01 0:00 ` Mark Wielaard
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` Mark Wielaard
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` Mark Wielaard
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` Fangrui Song
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` Mark Wielaard
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` Mark Wielaard
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` Fangrui Song
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` Mark Wielaard
2020-01-01 0:00 ` Fangrui Song
2020-04-01 8:46 ` Florian Weimer
2020-04-01 9:22 ` Szabolcs Nagy
2020-04-01 9:29 ` Florian Weimer
2020-04-01 10:10 ` Szabolcs Nagy
2020-04-01 10:21 ` Florian Weimer
2020-01-01 0:00 ` Mark Wielaard
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=a7078f74881daf23ca4af4983bac212a6c971b5a.camel@klomp.org \
--to=mark@klomp.org \
--cc=binutils@sourceware.org \
--cc=gnu-gabi@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).