Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org, Aleksandar Ristovski <ARistovski@qnx.com>
Subject: Re: [patchv3 0/8] Validate binary before use
Date: Mon, 03 Mar 2014 13:27:00 -0000	[thread overview]
Message-ID: <53148332.7010600@redhat.com> (raw)
In-Reply-To: <20140302183659.GA11910@host2.jankratochvil.net>

On 03/02/2014 06:36 PM, Jan Kratochvil wrote:

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.  

OK.  I think it'd be useful, so that GDB can warn/reject in the
common scenario of the user not pointing at a sysroot with the
correct DSOs.

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

Thanks.  I think that feature may be a little beyond borderline
for that project page though, as core loading is not really part
of the native target.  IMO it'd good if this had its own project
page, where it'd give answer to questions like the below.

#0 - If implemented by gdbserver, it seems like it'd involve further user
action to trigger the feature?  How does one tell GDB/gdbserver to load the
ore on the remote side rather than locally?

#1 - couldn't this be addressed by just using fuse/ssh/somesuch to
access the core?  (that is, transparently from GDB).

#2 - if not, could we perhaps tweak the target stratum bits a little to
allow sitting core_ops on top of extended-remote, and have it read the
necessary bits off the remote core with target_fileio_xxx.  So we'd
still have host-side core_ops / bfd.  You'd load the core with e.g.,
"core remote:/.../core.pid").

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

https://sourceware.org/ml/gdb-patches/2014-02/msg00859.html

-- 
Pedro Alves


  reply	other threads:[~2014-03-03 13:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-27 21:33 Jan Kratochvil
2014-02-28 13:47 ` Pedro Alves
2014-02-28 14:17   ` Aleksandar Ristovski
2014-03-02 18:37   ` Jan Kratochvil
2014-03-03 13:27     ` Pedro Alves [this message]
2014-03-08 17:33       ` Jan Kratochvil
2014-03-10  9:57         ` Joel Brobecker
2014-03-10 10:12           ` Jan Kratochvil
2014-03-10 14:27         ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53148332.7010600@redhat.com \
    --to=palves@redhat.com \
    --cc=ARistovski@qnx.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox