Re: ld.elf_so compatibility for ancient ELF binaries (pre-2.0)

2018-10-14 Thread Joerg Sonnenberger
On Thu, Oct 11, 2018 at 07:15:30PM +0200, Joerg Sonnenberger wrote: > On Wed, Oct 03, 2018 at 10:40:32PM +0200, Joerg Sonnenberger wrote: > > Otherwise I would strictly reduce the compatibility hack to the above > > mentioned five architectures. The difference is 132-256 Bytes in .data > > and a co

Re: ld.elf_so compatibility for ancient ELF binaries (pre-2.0)

2018-10-11 Thread Joerg Sonnenberger
On Wed, Oct 03, 2018 at 10:40:32PM +0200, Joerg Sonnenberger wrote: > Otherwise I would strictly reduce the compatibility hack to the above > mentioned five architectures. The difference is 132-256 Bytes in .data > and a couple of relocations. The attached patch implements this. Testing from non-x

Re: ld.elf_so compatibility for ancient ELF binaries (pre-2.0)

2018-10-04 Thread Martin Husemann
On Wed, Oct 03, 2018 at 10:40:32PM +0200, Joerg Sonnenberger wrote: > The list of platforms where ELF was enabled by default can be found in > https://anonhg.netbsd.org/src/file/897109941a9a/share/mk/bsd.own.mk#l96 > Note that this also includes sparc64. This makes no sense as the dynamic > linker

ld.elf_so compatibility for ancient ELF binaries (pre-2.0)

2018-10-03 Thread Joerg Sonnenberger
Hello all, there is a compatiblity hack in ld.elf_so for early ELF binaries that I would like to restructure and restrict to those architectures that actually need it. Short version is that crt0.o would contain dlopen(3) and friends and implement them by calling a pointer stored in the handle passe