Re: Automatically fetching Build ID from remote libraries and resole them locally?

[Norbert Lange <nolange79@gmail.com>]

Am Mo., 30. März 2020 um 11:19 Uhr schrieb Jan Kratochvil
<jan.kratochvil@redhat.com>:
>
> On Mon, 30 Mar 2020 11:04:30 +0200, Norbert Lange wrote:
> > I would want to use 'set sysroot /path/to/staging/dir', but the downside is that
> > mismatches will not be detected and can badly mess up debugging.
>
> You should have setup symlinks in /usr/lib/debug/.build-id/
> (or where you 'set debug-file-directory') for all build-ids you ever build.
> That works for core-files.

Thats the plan.

I verified that the coredump contains all Build-Ids with
eu-unstrip -n --core /tmp/core

But Id have to first locate the binary manually, then starting
gdb PATH_TO_BINARY PATH_TO_CORE

Whats worse is, that gdb seems to lookup for the library first (filepath),
if it exists it will use the Build-Id from this potentially unrelated
version (and use the wrong debug info if one exists),
if it does not exist, then it wont even try searching in the
debug-library (neither via name or build-id).

In other words, its completely broken unless the system you debug is
the very same (and in the same state) as the executable did run on.

If I'd want to debug a coredump now, I would have to inspect the
buildids, copy the debug-infos under the name they where used on the
target in a own sysroot.
(Almost the same as for remote debug now).

I tried both with sysroot unset (default) and set to a directory with
partially missing/outdated versions.

> > GDB 9.0 certainly does not use *Build-Ids from the 'remote'*,
>
> According to a test I have made now I agree. Maybe Gary Benson will suggest
> more.

Norbert