I asked about the rationale behind the 2-PLT scheme to H. J. Lu who proposed the design. I was not convinced one of the reasons he presented, which is that the 2-PLT scheme provides compatibility with old systems, because clearly the 2-PLT scheme breaks compatibility by changing the semantics of the existing .plt section and adding the second PLT. The other reason was more convincing, which is, it was designed with performance in mind, and it was an effort to reduce the size of the hot code path. With the 2-PLT scheme, the second PLT is in theory hot and the first PLT is relatively cold, as the first PLT is used only when a symbol is resolved lazily. That being said, there was not evidence or benchmark results supporting the claim, so I cannot really buy that argument.
@ruiu Is this good to go? Any other changes you see?
Used clang-format-diff against the patch is requested by @aganea.
Wed, Feb 20
Hi dear ruiu:
The Second PLT in x86-64 psABI has been settled more than one year ago, considering the compatibility and performance, the designers carefully selected this way at that time.
And there seems no overwhelming reason to change the SPEC, for many people think the Second PLT way is more flexible and compatible.
I think it would be ill-advised to let LLD keep different with GCC in this point for the GCC has adopt this way for one year.
I wish you can reconsider the technology of Second PLT, and we also wish you can join us in discussing this point at https://groups.google.com/forum/#!topic/x86-64-abi/nWA7tcnjPnk.
Thank you very much!
Sorry for all the updates. Fixed typo in COFF/InputFiles.h.
Adressed all comments. Added tests as suggested by @pcc
Tue, Feb 19
The 2nd reason will be obvious in the case that the program with many dynamic calls.
I think SPLT has better compatibility compared to change the original PLT entry. Given the platform is old, and use the old dynamic linker, the new library that build with SPLT can still be linked by dynamic linker. I am not sure if it still works if we change the struct of PLT entry.
The second issue is GNU toolchain has already adopt SPLT, if we want to change the design, we need also influence the GNU community to revise the design and all their libraries which are built with CET enabled toolchain.
- Fixed function arguments' names
- Added test for the PT_MIPS_OPTIONS segment creation
Thanks for review.
Thanks, Alexey! This patch looks good to me, but since it was me who suggested to commit it as a separate test for LLD,
I would like somebody else to look and give the final approvement.
George, Thank you for the comments. I should not rely on context and needed to put detailed description from the scratch. I changed test description and used your compacted asm now.
It is not clear from the description, so for other reviewers:
Mon, Feb 18
Sun, Feb 17
Fri, Feb 15
Hi ruiu, I asked its designer. This is really specified in x86-64 psABI SPEC, Please refer https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-draft.pdf 13.2 DynamicLinking
I think we need to be very careful how to implement the feature. Currently it is very easy to understand what lld prints out as an error message and how to construct an error message. Basically, what you see in the source code is what you get at runtime. This patch added an abstraction layer between the current code and stderr, and now it is not easy to figure out what is the actual output and how to construct a desired error message.
I really don't think we should introduce a new PLT (.splt) if the reason of adding it is to keep the compatibility of the existing .plt format. Second PLT is too complicated and would become a technical debt.
Hi friends, And I find GCC used Second PLT too. I am trying to contact its designer. One of the reviewer Lu Hongjiu.