This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v4 0/8] Validate binary before use
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: gdb-patches at sourceware dot org, ARistovski at qnx dot com
- Date: Wed, 19 Mar 2014 23:32:58 +0100
- Subject: Re: [PATCH v4 0/8] Validate binary before use
- Authentication-results: sourceware.org; auth=none
- References: <20140302195248 dot 10290 dot 22958 dot stgit at host1 dot jankratochvil dot net> <837g8ctjkj dot fsf at gnu dot org> <20140308195717 dot GA2333 at host2 dot jankratochvil dot net> <837g83pb47 dot fsf at gnu dot org> <20140309185803 dot GA24593 at host2 dot jankratochvil dot net> <834n37p4dc dot fsf at gnu dot org>
On Sun, 09 Mar 2014 20:18:55 +0100, Eli Zaretskii wrote:
> > "Shared object" is terminology in GDB, it is in fact the symbol file because
> > GDB never modifies the inferior itself where the real target shared object
> > exists.
> >
> > Just with the build-id comparisons I used "shared library" (as the target
> > in-memory data) vs. "symbol file" to highlight this difference.
>
> Sorry, I don't follow: libfoo.so.1 is a shared library, isn't it?
> There's no reference in the message to any symbol file, right?
target in-memory data:
Found by iterating memory structures like link_map.
Name like "libfoo.so.1" is found in link_map->l_name in target memory.
symbol file:
Found on host disk, from transforming the target name "libfoo.so.1"
(such as by adding "set sysroot" prefix).
These two files do not have to match. This patch ensures that if they do not
match then the second file is not loaded.
I do not think there is currently any established term for the first file
so it is questionable how to communicate the non-matching situation to user.
> > > and doesn't even mention the fact that the problem is a mismatch of the
> > > 2 build-ids. Why not say explicitly that the build-id of the symbol file
> > > doesn't match that of the shared library?
> >
> > This comes from the API, I can rework the patch. The API currently uses
> > method "validate" which can validate it in arbitary way. The current only
> > implmentation in solib-svr4 implements the validation using build-ids but the
> > error/warning message is currently handled by the caller, not the
> > build-id-specific implementation in solib-svr4.
>
> I think it's fine to leave the validation details unspecified, if you
> want. But then we shouldn't reveal that its actual implementation is
> comparing the build-ids. If we want to leave it opaque, let's do it
> consistently, i.e. both in the warnings printed by GDB and in the
> manual. OTOH, if we do want to tell that build-ids should be
> identical, then let's say that in the warning/error messages as well,
> again for consistency.
I have changed the code to print the build IDs instead.
Thanks,
Jan