public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
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

  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).