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