This was an issue that came up with libabigail which uses the Dwfl_Callbacks debuginfo_path when Dwarf has been split off into separate debuginfo and the binary root and the debuginfo root are different. That setup makes sense in general when inspecting binaries/debuginfo not normally installed and/or comes from a different distro/installation originally. In that case build-id searches might fail and you fall back on the debuginfo path search.
The issue is that the standard dwfl debuginfo patch search doesn't cope with separate roots/subpaths for the binaries and debug files. It expects them to line up exactly the same. The solution Dodji came up with is to not just search the exact absolute binary path under the debuginfo path, but also the sub-subdirs of the binary path. That makes sense to me. It is essentially a simple/more flexible way of supporting chroots when the bin dir and debug dir are using separate chroots. An alternative would be to add full support for chroots. But that seemed a lot more work than simply making the default debuginfo path search more flexible. I changed the implementation slightly from what Dodji suggested (it now only searches real sub-subdirs by using / as separator instead of using all full subpath prefixes) and added some documentation to explain what is going on. Dodji could you check if the changes still make sense to you? I also added a testcase that uses eu-addr2line --debuginfo-path in a similar situation as what libabigail is using. [PATCH 1/2] Fix finding split debug info files not located by the [PATCH 2/2] tests: Add a testcase for dwfl debuginfo-path with Cheers, Mark
