CVS commit: src

["Taylor R Campbell" <riastradh%netbsd.org@localhost>]

Module Name:    src
Committed By:   riastradh
Date:           Mon Dec 15 02:36:47 UTC 2025

Modified Files:
        src/libexec/ld.elf_so: headers.c
        src/tests/libexec/ld.elf_so: t_dladdr.c

Log Message:
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.75 -r1.76 src/libexec/ld.elf_so/headers.c
cvs rdiff -u -r1.1 -r1.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.