From: Zack Weinberg <zackw@panix.com>
To: Siddhesh Poyarekar <siddhesh@gotplt.org>
Cc: Szabolcs Nagy <szabolcs.nagy@arm.com>,
Wilco Dijkstra <Wilco.Dijkstra@arm.com>,
"libc-alpha@sourceware.org" <libc-alpha@sourceware.org>,
nd <nd@arm.com>
Subject: Re: [PATCH 0/2] Multiarch hooks for memcpy variants
Date: Fri, 11 Aug 2017 18:55:00 -0000 [thread overview]
Message-ID: <CAKCAbMh8=u27ZcS9La4SdQ3UiHi76TZdv_KSCpX0pkY8WMohOQ@mail.gmail.com> (raw)
In-Reply-To: <4072a19f-eecb-8cdd-889f-46b4c8b968b4@gotplt.org>
On Fri, Aug 11, 2017 at 2:53 PM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> On Friday 11 August 2017 11:36 PM, Zack Weinberg wrote:
>>> may be the generic __memcpy_chk should call the ifunced
>>> memcpy so it goes through an extra plt indirection, but
>>> at least less target specific code is needed.
>>
>> I was thinking of making this suggestion myself. I think that would
>> be a better maintainability/efficiency tradeoff. (Of course, I also
>> think we shouldn't bypass ifuncs for intra-libc calls.)
>
> That was my initial approach, but I was under the impression that PLTs
> in internal calls were frowned upon, hence the ifuncs similar to what's
> done in x86. If this is acceptable, I could do more tests to check
> gains within the library if we were to call memcpy via ifunc.
There's been a bunch of inconclusive arguments about this in the past.
If you have the time and the resources to do some thorough testing and
properly resolve the question, that would be really great.
zw
next prev parent reply other threads:[~2017-08-11 18:55 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-11 11:11 Wilco Dijkstra
2017-08-11 11:22 ` Siddhesh Poyarekar
2017-08-11 17:58 ` Szabolcs Nagy
2017-08-11 18:06 ` Zack Weinberg
2017-08-11 18:53 ` Siddhesh Poyarekar
2017-08-11 18:55 ` Zack Weinberg [this message]
2017-08-14 10:36 ` Wilco Dijkstra
2017-08-14 12:14 ` Siddhesh Poyarekar
2017-08-14 13:20 ` Szabolcs Nagy
2017-08-14 13:29 ` Siddhesh Poyarekar
2017-08-14 13:52 ` Szabolcs Nagy
2017-08-14 13:56 ` Siddhesh Poyarekar
2017-08-15 21:55 ` Wilco Dijkstra
2017-08-16 4:29 ` Siddhesh Poyarekar
2017-08-14 13:22 ` Wilco Dijkstra
2017-08-14 13:54 ` Siddhesh Poyarekar
2017-08-15 20:11 ` Patrick McGehearty
[not found] ` <a62a7627-1d1e-6a2b-8197-f4b16bfbdcc6@oracle.com>
2017-08-15 20:14 ` Patrick McGehearty
2017-08-15 21:02 ` Zack Weinberg
2017-08-15 21:41 ` Wilco Dijkstra
2017-08-15 22:06 ` Zack Weinberg
2017-08-16 4:40 ` Siddhesh Poyarekar
2017-08-16 5:10 ` Siddhesh Poyarekar
2017-08-15 20:52 ` Zack Weinberg
2017-08-16 12:28 ` Wilco Dijkstra
2017-08-17 1:09 ` Zack Weinberg
-- strict thread matches above, loose matches on Subject: below --
2017-08-11 7:14 Siddhesh Poyarekar
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='CAKCAbMh8=u27ZcS9La4SdQ3UiHi76TZdv_KSCpX0pkY8WMohOQ@mail.gmail.com' \
--to=zackw@panix.com \
--cc=Wilco.Dijkstra@arm.com \
--cc=libc-alpha@sourceware.org \
--cc=nd@arm.com \
--cc=siddhesh@gotplt.org \
--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).