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