From: Pedro Alves <palves@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org,
Aleksandar Ristovski <ARistovski@qnx.com>,
Joel Brobecker <brobecker@adacore.com>
Subject: Re: [patchv3 0/8] Validate binary before use
Date: Mon, 10 Mar 2014 14:27:00 -0000 [thread overview]
Message-ID: <531DCBA5.8010608@redhat.com> (raw)
In-Reply-To: <20140308173316.GA18331@host2.jankratochvil.net>
On 03/08/2014 05:33 PM, Jan Kratochvil wrote:
> On Mon, 03 Mar 2014 14:27:14 +0100, Pedro Alves wrote:
>> On 03/02/2014 06:36 PM, Jan Kratochvil wrote:
>>>> 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.
>
> Yes, may extensions would be useful.
> The question is if it should be a blocker for this patch series.
Not at all, IMO. I was just really asking whether that was
already in the works. If not, fine, it's still forward progress
without it.
>> 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.
>
> Created:
> https://sourceware.org/gdb/wiki/GDBserverCoreFiles
> And removed it from:
> https://sourceware.org/gdb/wiki/LocalRemoteFeatureParity?action=diff&rev2=57&rev1=56
Thanks.
>
>
>> #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?
>
> I did not think more about it as I have never started that project.
>
> The basic functionality would be:
> $ gdbserver -c :1234 corefile
> $ gdb executable
> (gdb) target remote :1234
> And if I did not forget anything it could work.
Yeah. I was more thinking of (persistent) extended-remote, like:
$ gdbserver --multi :1234
$ gdb
(gdb) target extended-remote :1234
(gdb) ???
Just "core COREFILE" at that point currently makes GDB disconnect
from the remote, and load the core itself (on the host). Ideally
we'd have some way to tell GDB we actually want to load the core on
the currently connected remote end. I guess a new knob ('set core
host/target/auto'), plus a new option to the "core" command,
like "core -target" or some such. Seems doable.
--
Pedro Alves
prev parent reply other threads:[~2014-03-10 14: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
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 [this message]
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=531DCBA5.8010608@redhat.com \
--to=palves@redhat.com \
--cc=ARistovski@qnx.com \
--cc=brobecker@adacore.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