public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Zack Weinberg <zackw@panix.com>
Cc: "H.J. Lu" <hjl.tools@gmail.com>,
	GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH] Mark internal functions with attribute_hidden
Date: Thu, 17 Aug 2017 13:35:00 -0000	[thread overview]
Message-ID: <54d3d74b-a3db-570c-eecd-c14a5a78a28c@redhat.com> (raw)
In-Reply-To: <CAKCAbMjfq=8JNz=-aJ10MRfafDGnMf6+M2+KzSMAc+JQ5c=Syw@mail.gmail.com>

On 08/17/2017 03:12 PM, Zack Weinberg wrote:
> On Thu, Aug 17, 2017 at 8:43 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Thu, Aug 17, 2017 at 5:37 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>> On 08/17/2017 02:25 PM, H.J. Lu wrote:
>>>> Mark internal functions with attribute_hidden to allow direct access to
>>>> internal functions within libc.a without using GOT when the compiler
>>>> defaults to -fPIE.
>>>
>>> This explanation is a bit confusing.  I think this benefits other
>>> architectures, too.
>>
>> Yes, this is target independent.   It should benefit static PIE build for all
>> targets.  On x86, it bypasses GOT/PLT.
> 
> Should internal_function just imply attribute_hidden?  Or is this
> inappropriate for some things marked internal_function?

I want to remove internal_function completely because it serves no
useful purpose whatsoever because it has never been used consistently.
Currently, it expands to an empty string on all builds.

Thanks,
Florian

  parent reply	other threads:[~2017-08-17 13:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-17 12:25 H.J. Lu
2017-08-17 12:37 ` Florian Weimer
2017-08-17 12:43   ` H.J. Lu
2017-08-17 13:12     ` Zack Weinberg
2017-08-17 13:19       ` H.J. Lu
2017-08-17 13:35       ` Florian Weimer [this message]
2017-08-17 14:02     ` Joseph Myers
2017-08-17 18:58       ` H.J. Lu
2017-08-22 17: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=54d3d74b-a3db-570c-eecd-c14a5a78a28c@redhat.com \
    --to=fweimer@redhat.com \
    --cc=hjl.tools@gmail.com \
    --cc=libc-alpha@sourceware.org \
    --cc=zackw@panix.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).