On 29.02.2020 21:58, Joerg Sonnenberger wrote: > On Sat, Feb 29, 2020 at 07:36:00PM +0100, Kamil Rytarowski wrote: >> On 29.02.2020 19:00, Taylor R Campbell wrote: >>>> Module Name: src >>>> Committed By: kamil >>>> Date: Sat Feb 29 04:27:01 UTC 2020 >>>> >>>> Modified Files: >>>> src/doc: CHANGES >>>> >>>> Log Message: >>>> ld.elf_so(1): Implement DT_GNU_HASH >>> >>> Was this discussed anywhere? >> >> In the toolchain circles, for some time now (2+ years). >> >> It was one of the pending task to modernize our ELF loader on par with >> at least FreeBSD. > > Can we please stop with this "we must need XXX to be on par with YYY" > nonsense without actually looking at the details first and discuss them? > Practically speaking, there was moderately little discussion about the > actual design choices of DT_GNU_HASH, especially some of its deficits. > Especially because we already have some important improvements in our > tree *without breaking compatibility*. Especially the size claims are > questionable at best as justification are weak at best. It also ignores > that by design DT_GNU_HASH conflicts with at least one platform ABI. > > Joerg > Just keeping DT_GNU_HASH support around does not break compat. Full replacement of HASH algorithm would break compat but nobody wants to do it (at least in NetBSD). Improvement. I presume we are talking about enhancements such as fast_divide32_prepare(3). This is reused also in DT_GNU_HASH. DT_GNU_HASH is still not fully supported on MIPS ABI with our basesystem toolchain (as it is not recent enough). Paper work stopped it for some years and it is now in mainline GNU as DT_MIPS_XHASH. https://github.com/bminor/binutils-gdb/commit/f16a9783c5f085443d806646074e9c06fdee9a88 So, I presume it is good to ifdef DT_GNU_HASH for __mips__ in the loader.
Attachment:
signature.asc
Description: OpenPGP digital signature