From: Szabolcs Nagy <szabolcs.nagy@arm.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Fangrui Song <i@maskray.me>,
GNU C Library <libc-alpha@sourceware.org>,
gnu-gabi <gnu-gabi@sourceware.org>,
Mark Wielaard <mark@klomp.org>,
"Zhang, Annita" <annita.zhang@intel.com>,
Binutils <binutils@sourceware.org>,
Cary Coutant <ccoutant@gmail.com>,
"Liu, Hongtao" <hongtao.liu@intel.com>
Subject: Re: binutils ld and new PT_GNU_PROPERTY segment
Date: Wed, 1 Apr 2020 11:10:02 +0100 [thread overview]
Message-ID: <20200401101002.GO27072@arm.com> (raw)
In-Reply-To: <87ftdnzh8q.fsf@oldenburg2.str.redhat.com>
The 04/01/2020 11:29, Florian Weimer wrote:
> * Szabolcs Nagy:
> > why only -r is problematic?
> >
> > i thought linking exactly one marked object and other non-marked
> > ones with an old linker will have the (incorrect) marking on the
> > output that cannot be recognised as wrong.
>
> Where do you get that single marked object?
>
> If you are on a CET-enabled distribution, the startup files are marked,
> so you have multiple marked objects right there.
assume your toolchain is not cet enabled (and has an old
linker) but you link in a library archive that is cet
enabled (because it was given to you that way) and exactly
one .o from it gets used during the link.
the resulting binary will have the marking and if deployed
on a cet enabled system it won't work. (at least this is
my current understanding.)
next prev parent reply other threads:[~2020-04-01 10:10 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-01 0:00 Mark Wielaard
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 ` 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 ` 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 [this message]
2020-04-01 10:21 ` Florian Weimer
2020-01-01 0:00 ` Fangrui Song
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` H.J. Lu
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=20200401101002.GO27072@arm.com \
--to=szabolcs.nagy@arm.com \
--cc=annita.zhang@intel.com \
--cc=binutils@sourceware.org \
--cc=ccoutant@gmail.com \
--cc=fweimer@redhat.com \
--cc=gnu-gabi@sourceware.org \
--cc=hongtao.liu@intel.com \
--cc=i@maskray.me \
--cc=libc-alpha@sourceware.org \
--cc=mark@klomp.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).