Re: [patchv3 0/8] Validate binary before use

[Pedro Alves <palves at redhat dot com>]

On 02/27/2014 09:32 PM, Jan Kratochvil wrote:
> Hi,
> 
> git://sourceware.org/git/archer.git
> jankratochvil/gdbserverbuildid
>  - although it is not properly separated into 1..8 there as in this series

Thanks.  Personally for review, I prefer a git branch with the
exact same contents as posted.

(BTW, git am caught a couple whitespace issues:

$ git am /tmp/jan1
Applying: Move utility functions to common/
Applying: Merge multiple hex conversions
Applying: Create empty common/linux-maps.[ch] and common/common-target.[ch]
Applying: Prepare linux_find_memory_regions_full & co. for move
Applying: Move linux_find_memory_regions_full & co.
Applying: gdbserver build-id attribute generator
Applying: Validate symbol file using build-id
Applying: Tests for validate symbol file using build-id
/home/pedro/gdb/mygit/src/.git/rebase-apply/patch:256: trailing whitespace.

/home/pedro/gdb/mygit/src/.git/rebase-apply/patch:271: trailing whitespace.
# Keep previous so for debugging puroses
/home/pedro/gdb/mygit/src/.git/rebase-apply/patch:274: trailing whitespace.
# Copy loaded so over the one gdb will find
warning: 3 lines add whitespace errors.)

I looked through the whole series, and sent out a few minor comments,
but it all looked good to me otherwise.

I think this is a quite nice feature.  Thanks for doing this (you both).

> 
> the is a follow-up to never checked in series:
> 	Message-ID: <1366127096-5744-1-git-send-email-ARistovski@qnx.com>
> 	https://sourceware.org/ml/gdb-patches/2013-04/msg00472.html

To save others the same, I followed a few links to find the description
of the series, here:

  https://sourceware.org/ml/gdb-patches/2013-04/msg00220.html

>    Implementing new feature into gdbserver and not linux-nat seems correct to
>    me according to:
>    https://sourceware.org/gdb/wiki/LocalRemoteFeatureParity
>    I will list there this local/remote difference after check-in but that
>    should be OK after the final switch to gdbserver.

If only one side can be implemented, then yes, agreed, let's prefer the
GDBserver side.  However, if not hard, I'd rather we did both, as we
can't tell how long it will take until we finally share the
backends.  It's only the case of only implementing something _only_ on
the native side and not in gdbserver that puts us further away
from the end goal.  With that in mind, how hard would it be to support
this on current native as well?  Can we do it by sharing most of
the build id code, say by splitting out most of the Linux build
id stuff out a linux-buildid.c file that is built by both gdb
and gdbserver?

BTW, do you plan on contributing support for validation with
cores too?

I think this should be mentioned in NEWS.

The new attribute of the xml of qXfer:libraries-svr4 should
be mentioned in NEWS too.

Also, I think somewhere in the manual we should explain this:

+      warning (_("Shared object \"%s\" could not be validated "
+		 "and will be ignored."), so->so_name);

I wonder whether we'll need to let the user force-disable
this validation?  I think so.  Sometimes it might be useful to
force GDB into taking the symbols even if it's not an exact match
(say, if one rebuilds to get back symbols, or to get around
potential tooling problems).

> --- a/gdb/testsuite/gdb.base/solib-mismatch.exp> +++ b/gdb/testsuite/gdb.base/solib-mismatch.exp
> @@ -1,4 +1,4 @@
> -# Copyright 2013 Free Software Foundation, Inc.
> +# Copyright 2014 Free Software Foundation, Inc.

These need to be 2013-2014.

-- 
Pedro Alves