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 | <CADYdroM9eUJ9TCG829xR_-GbBk+Sfr9m3z4+XOkhydC7oRWqQw@mail.gmail.com> |
Hmm, How do I read the list at https://src.fedoraproject.org/rpms/gdb/tree/master. Are all patches applied, or are the ones starting with 'gdb-6.6' only for that version? Yeah, if all of them are missing, upstream is lacking alot. An a different note, I dont know if you are a GDB maintainer, but the topic should be the upstream version? It was not clear to me Redhat gdb and sourceware gdb are two different things. Am Mo., 6. Apr. 2020 um 13:49 Uhr schrieb Jan Kratochvil <[email protected]>: > > On Mon, 06 Apr 2020 13:31:43 +0200, Norbert Lange wrote: > > 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. > > What you describe is behaving correctly on Fedora with my off-trunk patches > (I have not tested it now but I was fixing exactly this problem in its initial > version many years ago). If you run FSF GDB maybe Red Hat should upstream more > of the Fedora patches. > > > Jan >