From: Joseph Myers <joseph@codesourcery.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Carlos O'Donell <carlos@redhat.com>,
Szabolcs Nagy <szabolcs.nagy@arm.com>, nd <nd@arm.com>,
GNU C Library <libc-alpha@sourceware.org>
Subject: Re: PING^N: [PATCH] Add --enable-static-pie to build static PIE [BZ #19574]
Date: Mon, 18 Dec 2017 13:37:00 -0000 [thread overview]
Message-ID: <alpine.DEB.2.20.1712181332140.8805@digraph.polyomino.org.uk> (raw)
In-Reply-To: <CAMe9rOqaWBNa6S5YoMLgOVK4dizSpE+GGOeeWYRROTUUCjfKXA@mail.gmail.com>
On Sat, 16 Dec 2017, H.J. Lu wrote:
> Thanks for your time. I checked it in with the updated commit log.
> I also updated
>
> https://sourceware.org/glibc/wiki/PortStatus
That's missing key information:
* It needs a complete list of architectures that have not yet been
verified to work with static PIE. Architectures would then be removed
from that list one at a time as and when someone verifies them to work and
commits any fixes needed (and if the list becomes empty, the whole
section of the wiki page could be removed at that point).
* It needs instructions on how to test whether static PIE works for an
architecture (or architecture/ABI pair, if appropriate). Is this
"configure --enable-static-pie and make sure test results are as good as
without that option", or "configure --enable-static-pie and make sure
tests X, Y and Z pass", or doing one of those but additionally using GCC 8
or later so -static-pie is supported, or something else? This needs to be
on the wiki page so it's completely clear how someone can test the feature
for an architecture and have confidence in whether it's working.
When new ports are submitted for glibc, you should then seek confirmation
of whether they work with static-PIE, as if they don't and get added to
glibc without such support, they'd need to be added to the list on the
wiki page.
> for static PIE status. Should build-many-glibcs.py be updated to also
> build static PIE for i386, x86_64 and x32? We can't build it by default
> since the recent linker is needed.
A few additional builds for configurations where all the GCC / binutils /
glibc support required is present would be a good idea (but maybe not if
enough support isn't present in the default versions used by
build-many-glibcs.py, which means GCC 7 branch and binutils 2.29 branch).
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2017-12-18 13:37 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-01 12:46 H.J. Lu
2017-11-01 16:04 ` Joseph Myers
2017-11-01 16:06 ` H.J. Lu
2017-11-03 17:57 ` H.J. Lu
2017-11-19 2:40 ` H.J. Lu
2017-11-19 15:39 ` Florian Weimer
2017-11-19 16:17 ` H.J. Lu
2017-11-19 19:52 ` H.J. Lu
2017-11-20 14:17 ` Joseph Myers
2017-11-23 14:09 ` H.J. Lu
2017-11-20 12:16 ` Szabolcs Nagy
2017-11-23 13:59 ` H.J. Lu
2017-11-24 13:07 ` Szabolcs Nagy
2017-11-24 15:03 ` H.J. Lu
2017-11-24 22:24 ` H.J. Lu
2017-11-30 14:00 ` H.J. Lu
2017-11-30 15:28 ` Joseph Myers
2017-11-30 16:24 ` H.J. Lu
2017-11-30 16:37 ` Joseph Myers
2017-11-30 16:56 ` H.J. Lu
2017-11-30 18:45 ` Carlos O'Donell
2017-11-30 21:45 ` Carlos O'Donell
2017-11-30 22:37 ` Maciej W. Rozycki
[not found] ` <CAMe9rOpDRknZANuSvXAqU_qaXzGRjt=uY5BZLJoE_o9Ke+9yfw@mail.gmail.com>
[not found] ` <alpine.DEB.2.00.1711302308170.31156@tp.orcam.me.uk>
2017-12-01 1:08 ` H.J. Lu
2017-12-01 1:58 ` Maciej W. Rozycki
2017-12-01 4:18 ` H.J. Lu
2017-12-01 9:59 ` Maciej W. Rozycki
2017-12-01 12:27 ` Joseph Myers
2017-12-01 13:35 ` H.J. Lu
2017-12-01 18:24 ` H.J. Lu
2017-12-08 13:14 ` H.J. Lu
2017-12-15 21:19 ` Carlos O'Donell
2017-12-16 2:04 ` H.J. Lu
2017-12-16 3:06 ` Carlos O'Donell
2017-12-18 13:37 ` Joseph Myers [this message]
2017-12-19 1:14 ` H.J. Lu
2017-12-15 11:58 H.J. Lu
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=alpine.DEB.2.20.1712181332140.8805@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=carlos@redhat.com \
--cc=hjl.tools@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=nd@arm.com \
--cc=szabolcs.nagy@arm.com \
/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).