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 08/11/2015 04:04 AM, OndÅej BÃlka wrote:
> 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>
>>> 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.

Not true.  Maybe this isn't how it works right now, maybe this violates
observable ELF semantics, and maybe this would wind up eliminating all
the benefit of lazy loading, but it is *possible* for the dynamic loader
to point the GOT entry for each imported function at a canonical PLT
entry from the library that defines that function.  That is a thing it
could do.

> Simple, we return null. Following causes segmentation fault.

That seems like a bug regardless of whether C function pointer equality
rules are being followed.

>> ...
>>> 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 can't verify any of your claims, because you have not documented
enough of your methodology for me to even *attempt* to reproduce them.
(Whole-system profiling data is inherently unreproducible; nobody else
has the exact same computer and configuration that you do.  When you
have posted benchmark data, they are synthetic results which you have
only *asserted* reflect real-world usage patterns; you have not provided
evidence of any kind for that assertion.)

> Here you should stop talking that its hard to tell whats overhead of plt
> calls and just read benchmark data.

I believe that was Mike's claim, not mine.  Also, every time you tell
someone to shut up and go away, you make people not want to work with you.

>> 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? 

Thank you for again demonstrating my original point, which is that you
are being so abrasive and so adamant about your own correctness that
people come to believe that *if you were wrong* there would be no way to
convince you of that fact.  So they give up trying.

I take no position on whether or not you are wrong about any of your
specific claims.  I merely observe that your debating tactics are
self-defeating.

zw

Attachment: signature.asc
Description: OpenPGP digital signature


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