This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Remove unnecessary IFUNC dispatch for __memset_chk.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, Andreas Schwab <schwab at linux-m68k dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 11 Aug 2015 10:04:51 +0200
- Subject: Re: [PATCH] Remove unnecessary IFUNC dispatch for __memset_chk.
- Authentication-results: sourceware.org; auth=none
- References: <20150809013434 dot 0B16814B9A at panix1 dot panix dot com> <m28u9lotfk dot fsf at linux-m68k dot org> <55C76FCD dot 5020607 at panix dot com> <CAMe9rOoAWjRma_mG_FazVh3FGOyiGJ=g82=bsfGqa-COnt5p1g at mail dot gmail dot com> <55C78525 dot 40402 at panix dot com> <CAMe9rOrKg8nzB67+OCXz5n1u7ZLnJncpX7J6KkEXqe0Bra843w at mail dot gmail dot com> <55C79AD8 dot 3070301 at panix dot com> <20150810030920 dot GE23550 at vapier> <20150810211200 dot GA17734 at domone> <CAKCAbMia4RCA7X0YHYeXC6eAGCxzDqhWrMiGS4NxA-cDxFioVw at mail dot gmail dot com>
On Mon, Aug 10, 2015 at 07:41:49PM -0400, Zack Weinberg wrote:
> On Mon, Aug 10, 2015 at 5:12 PM, OndÅej BÃlka <neleai@seznam.cz> wrote:
> > On Sun, Aug 09, 2015 at 11:09:20PM -0400, Mike Frysinger wrote:
> >> On 09 Aug 2015 14:24, Zack Weinberg wrote:
> >> > Is an IFUNC's variant-selecting function called only once per process,
> >> > or every time?
> >>
> >> it's once-per-process. if it were every time, it'd defeat the point of the
> >> optimization.
> >
> > No, its once per each shared library.
>
> I don't see how that can possibly be right. Doesn't each shared
> library provide the one true PLT entry for each function it exports?
No, what you said couldn't possibly work as you would need resolver for resolver to see where these plt entries are.
Its completely opposite as each library generates plt stub for each
function it uses to save space of repeatedly setting up tables for
different dso.
> If not, how can we be obeying the C standard's rules about function
> pointer equality?
>
Simple, we return null. Following causes segmentation fault.
gcc -fPIC -shared x.c -o libx.so
void foo (int x) __attribute__ ((ifunc ("resolve_foo")));
int foo_impl(int x)
{
return 42;
}
int bar()
{
foo(5);
void (*f)(int) = foo;
f(42);
}
static void (*resolve_foo (void)) (void)
{
// printf("ifunc\n");
return foo_impl; // we'll just always select this routine
}
gcc main.c -L. -lx
void bar();
int main()
{
bar();
}
> ...
> > thats completely flawed analysis
> ...
>
> I would like to believe you about this, because I would have liked not
> to have to patch 66 files for explicit_bzero, but I don't; not because
> I disbelieve any of your concrete claims - they all sound *plausible*
> - but because your attitude does not admit the possibility that you
> might be wrong.
You don't have to trust, you have to verify. I by default don't trust
unless I become convinced. As I could back my claims by whole system
profiling data I always almost say what you need to do. Here you should
stop talking that its hard to tell whats overhead of plt calls and just
read benchmark data.
> Every time there's a question of string function
> performance, lately, you insist that your analysis of the situation is
> right and everyone else's is wrong, and if challenged you insist that
> the other person's analysis and/or benchmarks are invalid.
Well problem is that they most of time are. What else could I do?
Also could you point out three example where I was wrong with that?