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

Norbert Lange via Gdb <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <CADYdroPyrFuxmOW5idVmfY9N0Yrpma0CNORZiEkzuX+EmV8e6A@mail.gmail.com>
Am Mo., 30. März 2020 um 11:19 Uhr schrieb Jan Kratochvil
<[email protected]>:
>
> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.