port-hppa/56881: hppa: backtrace_symbols() delivers bogus results for some dynloaded functions

[tgl%sss.pgh.pa.us@localhost]

>Number:         56881
>Category:       port-hppa
>Synopsis:       hppa: backtrace_symbols() delivers bogus results for some dynloaded functions
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-hppa-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jun 12 23:40:00 +0000 2022
>Originator:     Tom Lane
>Release:        HEAD/202206101540Z
>Organization:
PostgreSQL Global Development Group
>Environment:
NetBSD sss2.sss.pgh.pa.us 9.99.97 NetBSD 9.99.97 (SD0) #1: Sat Jun 11 17:32:11 EDT 2022  tgl%nuc1.sss.pgh.pa.us@localhost:/home/tgl/netbsd-H-202206101540Z/obj.hppa/sys/arch/hppa/compile/SD0 hppa
>Description:
The lib/libexecinfo/t_backtrace test case fails for me, reporting that the output of backtrace_symbols_fmt() looks like

tc-so:backtrace is:
tc-so:#0: myfunc3
tc-so:#1: myfunc2
tc-so:#2: myfunc1
tc-so:#3: myfunc1
tc-so:#4: myfunc1
tc-so:#5: myfunc1
tc-so:#6: myfunc1
tc-so:#7: myfunc1
tc-so:#8: myfunc1
tc-so:#9: myfunc1
tc-so:#10: myfunc1
tc-so:#11: myfunc1
tc-so:#12: myfunc1
tc-so:#13: myfunc1
tc-so:#14: myfunc
tc-so:#15: atfu_backtrace_fmt_basic_body
tc-so:#16: _fini
tc-so:#17: _fini
tc-so:#18: _fini
tc-so:#19: main
tc-so:#20: ___start

That is, it's reporting "_fini" instead of symbols from libatf-c.so.  I poked into this and found out that backtrace_symbols depends on symtab_find(), which compares the results from dladdr() and a main-program symtab search to see which address is closer.  However, dladdr() is returning a PLABEL which AFAICT could be almost anywhere in memory.  In this case, the manufactured PLABEL is below the start of libatf-c.so, causing the "dd" delta computed by symtab_find to be negative, which wraps around to a large unsigned value making it look further away than the "_fini" address extracted from the main symbol table.  Depending on memory layout of shared libraries, it seems likely that some cases would accidentally work; but this one reliably fails for me.

>How-To-Repeat:
$ /usr/tests/lib/libexecinfo/t_backtrace backtrace_fmt_basic

>Fix:
This seems like a real mess.  The only somewhat-principled solution I can think of is for backtrace_symbols to use a variant of dladdr() that never calls _rtld_function_descriptor_alloc.  That would likely be an improvement anyway, since the current arrangement can wind up manufacturing a lot of completely useless PLABELs.