On Fri, 28 Feb 2014 14:46:38 +0100, Pedro Alves wrote:
> On 02/27/2014 09:32 PM, Jan Kratochvil wrote:
> >    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?

Yes, it could be moved to gdb/common/ and called also from linux-nat.c.
I have not done so.

My goal of this patch series was not the validation as described below.
In fact I am not aware in which cases it is needed.  Or rather I am aware of
it for a different use case as it partially overlaps my non-upstreamed "locate
files by their build-id from a core file":
	http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-6.6-buildid-locate.patch


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

No.  If related I find right to extend gdbserver to support cores, it would be
useful for ABRT to prevent needless uploads of many MBs of compressed core
files.  I have added "core file loading " to:
	https://sourceware.org/gdb/wiki/LocalRemoteFeatureParity?action=diff&rev2=56&rev1=55

From this patch series I needed only the 'build-id' attribute generator in
gdbserver (Red Hat internal #1068777), this is why I took over this patchset.
I just found unfair to skip the validator part of it when I have taken the
other parts so I am pushing it all now.


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

OK, added to

* New features in the GDB remote stub, GDBserver

new text:

  ** qXfer:libraries-svr4 contains also optional attribute 'build-id'
     for each library.  GDB does not load library with build-id
     that does not match such attribute.


> 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

Done.


> > --- 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.

Why?  It counts since the first post to gdb-patches?


Thanks,
Jan