Re: bin/60472 (ld.elf_so(1) changes cause a segmentation fault in dlopen(3))

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR bin/60472; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Matthias Scheler <tron%zhadum.org.uk@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, gnats-bugs%NetBSD.org@localhost
Subject: Re: bin/60472 (ld.elf_so(1) changes cause a segmentation fault in
	dlopen(3))
Date: Mon, 20 Jul 2026 20:40:49 +0000

 > Date: Mon, 20 Jul 2026 21:02:16 +0100
 > From: Matthias Scheler <tron%zhadum.org.uk@localhost>
 > 
 > On Mon, Jul 20, 2026 at 07:17:28PM +0000, Taylor R Campbell wrote:
 > > If you still have the core dump and
 > > /usr/libdata/debug/usr/lib/ld.elf_so.debug, that should be enough to
 > > get a stack trace.  (If all you have is the core dump, you can just
 > > rebuild ld.elf_so from the same source date as before and the
 > > ld.elf_so.debug should work.)
 > 
 > The core dump was in the work directory of the "textproc/libxslt" package
 > which got cleaned in the meantime unfortunately.
 
 OK, no worries.
 
 > Is there a way e.g. by setting an environment variable to use an
 > alternative "ld.elf_so" to execute a binary?
 
 No, unfortunately not: it is rigidly fixed to execute the path it
 finds in the PT_INTERP program header.
 
 As an alternative (which I've sometimes done in the past while hacking
 ld.elf_so), you could:
 
 1. ^Z in any terminals where you're running builds
 2. install the new ld.elf_so into /libexec/ld.elf_so.new
 3. /rescue/ln /libexec/ld.elf_so /libexec/ld.elf_so.old
 4. /rescue/ln /libexec/ld.elf_so.new /libexec/ld.elf_so.tmp
 5. /rescue/mv -f /libexec/ld.elf_so.tmp /libexec/ld.elf_so
 6. [test the reproducer]
 7. /rescue/ln /libexec/ld.elf_so.old /libexec/ld.elf_so.tmp
 8. /rescue/mv -f /libexec/ld.elf_so.tmp /libexec/ld.elf_so
 9. fg in the terminals where you're running builds
 
 (In this case, the use of /rescue may not be necessary, if the bug is
 what I'm guessing it is and doesn't actually affect /bin/ln or /bin/mv
 or anything like that, but /rescue has saved me in the past when doing
 shenanigans like this.)
 
 You could also take a snapshot of / just before messing with it and
 mount it so you can recover with /rescue/pax or /rescue/tar if
 anything goes wrong.  If you're using ffs:
 
 1. ^Z builds
 2. mkdir /.snap /.snap/20260720
 3. fssconfig fss0 / /.snap/20260720.snap
 4. mount /dev/fss0 /.snap/20260720
 5. [screw up /libexec and test the reproducer]
 6. cd /.snap/20260720/libexec && /rescue/pax -rw -pe . /libexec/.
 7. umount /.snap/20260720
 8. fssconfig -u fss0
 9. rm /.snap/20260720.snap
 10. fg builds
 
 If you're using zfs, probably something like `zfs snap -r
 rpool/ROOT@20260720' and then either `zfs rollback' or fish it out of
 /.zfs/snapshot/20260720 instead.