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: Sun, 9 Mar 2014 19:58:03 +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>
On Sun, 09 Mar 2014 17:53:12 +0100, Eli Zaretskii wrote:
> I suggest to say that between these two sentences. Something like
>
> @value{GDBN} expects the build-ids of each shared library and its
> corresponding symbol file to match. If they don't match, then by
> default @value{GDBN} will ...
>
> A question: does "match" here means the build-ids should be identical?
> If so, perhaps use "identical" or "equal" instead of "match".
Yes, identical or equal is correct.
> > +while printing:
> > +
> > +@smallexample
> > + Shared object "libfoo.so.1" could not be validated and will be ignored;
> > + or use 'set solib-build-id-force'.
> > +@end smallexample
>
> Hmm... the text says that GDB will ignore symbol files, but the error
> message you cite complains about the shared library,
"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.
> 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.
Thanks,
Jan