This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: core dump build id
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Jeffrey Chen <cpthk at live dot com>
- Cc: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Wed, 26 Oct 2016 08:07:10 +0200
- Subject: Re: core dump build id
- Authentication-results: sourceware.org; auth=none
- References: <CY4PR13MB141401CB3B10969E11D4E5D5C7A80@CY4PR13MB1414.namprd13.prod.outlook.com> <CY4PR13MB14140C5384111B9FA715EEFCC7A80@CY4PR13MB1414.namprd13.prod.outlook.com>
On Wed, 26 Oct 2016 00:25:23 +0200, Jeffrey Chen wrote:
> However, I noticed that when gdb loads the core dump and binaries, if we
> provide a wrong version of the binaries, it will not complain. gdb would
> still load them fine without any warning. Do you know if this is a bug, or
> is it purposely done this way? If so, what's the reason behind it? Thanks.
Upstream/FSF GDB does not have support for _locating_ binaries (I talk about
/usr/bin/ + /usr/lib{,64}/, not about /usr/lib/debug/ ). FSF GDB supports
only verification that /usr/lib/debug/ files match by their build-id.
Locating the binaries+libraries by build-id is present in Fedora+RHEL GDB in
patches:
http://pkgs.fedoraproject.org/cgit/rpms/gdb.git/tree/
gdb-6.6-buildid-locate-*.patch
In Fedora+RHEL GDB you can use just:
gdb -c corefile
In fact in Fedora+RHEL GDB it is even enough to run just:
gdb corefile
Which both locate even the main executable. The more common case of:
gdb executable corefile
disables the verification of build-ids in binaries as Fedora+RHEL GDB behavior
must not diverge much from upstream/FSF GDB behavior.
There was an attempt to upstream this feature after it works for 9+ years in
Fedora+RHEL GDB. A last version of the newly rewritten implementation for FSF
GDB has been posted more than a year ago:
[PATCH v12 00/32] Validate binary before use
https://sourceware.org/ml/gdb-patches/2015-08/msg00590.html
Message-ID: <20150821212006.6673.35100.stgit@host1.jankratochvil.net>
But it never got any response by upstream maintainers.
Jan