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: Eli Zaretskii <eliz at gnu dot org>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org, ARistovski at qnx dot com
- Date: Sun, 09 Mar 2014 21:18:55 +0200
- 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>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Sun, 9 Mar 2014 19:58:03 +0100
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: gdb-patches@sourceware.org, ARistovski@qnx.com
>
> > > +@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.
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?
> > 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.