CVS commit: [netbsd-11] src

["Martin Husemann" <martin%netbsd.org@localhost>]

Module Name:    src
Committed By:   martin
Date:           Thu Dec 18 18:17:32 UTC 2025

Modified Files:
        src/distrib/sets/lists/debug [netbsd-11]: mi
        src/distrib/sets/lists/tests [netbsd-11]: mi
        src/libexec/ld.elf_so [netbsd-11]: headers.c
        src/tests/libexec/ld.elf_so [netbsd-11]: Makefile
Added Files:
        src/tests/libexec/ld.elf_so [netbsd-11]: t_dladdr.c

Log Message:
Pull up following revision(s) (requested by riastradh in ticket #129):

        distrib/sets/lists/tests/mi: revision 1.1404
        libexec/ld.elf_so/headers.c: revision 1.76
        tests/libexec/ld.elf_so/t_dladdr.c: revision 1.1
        tests/libexec/ld.elf_so/t_dladdr.c: revision 1.2
        tests/libexec/ld.elf_so/Makefile: revision 1.31

        distrib/sets/lists/debug/mi: revision 1.493

dl_addr(3): Add some automatic tests.

XXX Should also test the libc stubs, maybe move this into
tests/lib/libc/dlfcn and test both static and (for MKPIC=yes)
dynamic, but this'll do for now.

PR lib/59567: dladdr(3) doesn't work properly especially when main
executable is loaded at high memory address

dladdr(3): Fix determination of object address intervals.

This appears to have been broken in rev. 1.62 back in 2017 with a
change to compute the largest distance from the first LOAD segment's
starting address to the maximum address of any LOAD segment -- we
started by finding the distance from _zero_ to the maximum address of
the first LOAD segment because we subtracted obj->vaddrbase which
wasn't initialized yet, so we would overshoot obj->mapsize and
obj->textsize by whatever the value of obj->vaddrbase turned out to
be.

XXX The commit message for 1.62 suggests we are dropping the
assumption that the LOAD segments appear in order.  But it looks to
me like we still assume the _first_ load segment has the lowest
virtual address, because we keep it as obj->vaddrbase/obj->mapbase
and use it as a reference point for measuring the size of an object
by subtracting it from each load segment's maximum address.  Is the
original assumption that LOAD segments appear in order valid after
all, or do we need to do extra work here to handle objects whose LOAD
segments are so much out of order that the first LOAD segment isn't
lowest in virtual address space?  Unclear!

Might help with wine.
Based on a patch by Akihiro Sagawa, thanks!

PR lib/59567: dladdr(3) doesn't work properly especially when main
executable is loaded at high memory address


To generate a diff of this commit:
cvs rdiff -u -r1.485.2.5 -r1.485.2.6 src/distrib/sets/lists/debug/mi
cvs rdiff -u -r1.1387.2.4 -r1.1387.2.5 src/distrib/sets/lists/tests/mi
cvs rdiff -u -r1.75 -r1.75.2.1 src/libexec/ld.elf_so/headers.c
cvs rdiff -u -r1.28.2.2 -r1.28.2.3 src/tests/libexec/ld.elf_so/Makefile
cvs rdiff -u -r0 -r1.2.2.2 src/tests/libexec/ld.elf_so/t_dladdr.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.