Re: eu-addr2line only searches by build-id?

[Roland McGrath <roland at redhat dot com>]

> This has always been the way we do this in Debian since we started
> using it (in 2003), and we never had any problem with this.
> Adding an extention was never needed, because other tools don't look
> in the same directory as the executable itself.  Only elfutils seems
> to have a problem with this so far, because it has a different
> search path.

I thought I'd made the original searching behavior match what gdb did at
the time.  Looking at gdb/symfile.c:find_separate_debug_file_by_debuglink
today, and observing gdb's behavior, I was right.

However, gdb (at least today) does appear to explicitly check for the case
of the debuglink leading back to the same original file, and skip that.
So I guess I should make libdwfl do that too.

> I've also mailed about a simular problem using systemtap, which
> basicly has the same issue, trying to open the same file twice.

Systemtap uses libdw, so we're talking about the same code.
(It might supply a different debuginfo path, is all.)

> One argument I have against adding an extention is that this might
> result in a file conflict for debug files where a file conflict
> doesn't exist for the non-debug files.

I don't understand this.

> I'm also not sure why the default search path includes the path
> where the executable is in.  It doesn't make sense to store those
> debug files in something like /usr/bin/ to me.  And if it's not
> installed, it's probably also not stripped.  So maybe changing
> the default search path is an option?

Well, I didn't choose the original search path behavior, I just followed
the gdb behavior.  So I don't have my own justifications, just guesses
about what motivated it.  I don't imagine that anyone ever expected distro
packages to use places like that.  But people/sites/organizations
installing their own binaries in other places might use /some/place/foo and
/some/place/foo.debug or /some/place/.debug/foo.debug.


Thanks,
Roland