dllist() returns no items on FreeBSD

[ararslan]

With Julia 1.9.2 on FreeBSD 13.2, dllist() returns 42 entries. With 1.10.0-beta1 and master, it incorrectly returns 0 entries. The libdl and binaryplatform tests are failing for this reason. This is a regression introduced by #50162. Specifically, reordering the sources for symbol lookup to put the exe last caused this; the sanitizer parts of that PR are unrelated.

[staticfloat]

Just to make sure we're not barking up the wrong tree, have you tried manually reverting that change (reordering the if statements) and verifying that dllist() then works? I ask because dllist() doesn't seem to touch jl_dlfind.

[ararslan]

Yes, that's how I was able to determine that it was the reordering that caused the breakage. dllist doesn't use jl_dlfind directly but it does use ccall which uses jl_dlfind when dlsym doesn't find what it's looking for in libjulia-internal.

[topolarity]

It seems that dl_iterate_phdr is an overloaded weak symbol on FreeBSD:

$ readelf -sW /lib/libc.so.7 | grep dl_iterate_phdr
   840: 0000000000094fe0   199 FUNC    WEAK   DEFAULT   13 dl_iterate_phdr@@FBSD_1.0 (2)
$ readelf -sW /libexec/ld-elf.so.1 | grep dl_iterate_phdr
    10: 000000000000cfa0   748 FUNC  GLOBAL   DEFAULT   12 dl_iterate_phdr@@FBSD_1.0 (2)

Compare to Linux:

$ readelf -sW /lib/x86_64-linux-gnu/libc.so.6 | grep dl_iterate_phdr
  1138: 0000000000174d30   532 FUNC    WEAK   DEFAULT   15 dl_iterate_phdr@@GLIBC_2.2.5
$ readelf -sW /lib64/ld-linux-x86-64.so.2 | grep dl_iterate_phdr
(nothing)

After #50162, we end up resolving to the dl_iterate_phdr function provided by libc.so.7 rather than ld-elf.so.1 (which is the dynamic linker on FreeBSD).

[ararslan]

In your PR, you noted

During bootstrapping, many internal symbols (e.g. jl_fl_parse) are found in the global EXE namespace leading to an ambiguous lookup in Julia-in-Julia scenarios.

Can you elaborate on what that scenario is and how the prior ordering caused issues? The simplest "solution" to this issue is to add an #ifdef and preserve the previous order for lookups on FreeBSD while retaining the current order elsewhere, but that's not a particularly good solution since it sounds like the PR fixed something that could cause an actual problem, which presumably would also apply to FreeBSD. I don't actually understand what that problem is though.

[vtjnash]

Turned out to be an upstream bug (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272992), now fixed. Found by @topolarity

[topolarity]

I still want to merge a small fix for this on our side, since that fix is not available in any stable FreeBSD release yet