This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Remove unnecessary IFUNC dispatch for __memset_chk.


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? 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]