This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Fix a crash when displaying variables from shared ?library.
- From: Pedro Alves <pedro at codesourcery dot com>
- To: Paul Pluzhnikov <ppluzhnikov at google dot com>
- Cc: Joel Brobecker <brobecker at adacore dot com>, gdb-patches at sourceware dot org, tromey at redhat dot com
- Date: Wed, 18 Mar 2009 04:12:43 +0000
- Subject: Re: [patch] Fix a crash when displaying variables from shared ?library.
- References: <20090205030257.8A6073A6B7A@localhost> <20090318031516.GL31979@adacore.com> <8ac60eac0903172024g4e381249t43bac2b4c9769a04@mail.gmail.com>
On Wednesday 18 March 2009 03:15:16, Joel Brobecker wrote:
> If I understand the original issue correctly, we need to restart
> the execution of our program in order to demonstrate the issue.
> Except with the extended-remote protocol, we can't do that when
> using the gdbserver, right? In other words, the "run" command with
> target remote doesn't restart the program like in the native case.
> So I'd say we kill the test for remote targets.
Right, target remote doesn't support "run" at all:
(gdb) run
The "remote" target does not support "run". Try "help target" or "continue".
You'd have to disconnect/kill, and then reconnect perhaps. Maybe
using rerun_to_main.
On Wednesday 18 March 2009 03:24:04, Paul Pluzhnikov wrote:
> On Tue, Mar 17, 2009 at 8:15 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>
> > If I understand the original issue correctly, we need to restart
> > the execution of our program in order to demonstrate the issue.
>
> Well, not really. You could also
> dlopen foo.so
> break in foo.so
> display something referring to foo.so symbols
> dlclose foo.so
> re-display
>
> But writing a portable test for that is harder.
Or that. It may not be so hard for most targets we care
about. See unload.exp or watchpoint-solib.exp.
> Is it as simple as removing changing fail to untested:
>
> if { [gdb_start_cmd] < 0 } {
> - fail "Can't run to main (2)"
> + untested "Can't run to main (2)"
> return 0
> }
Or not that. :-)
>
> Of course we might just as well skip the test, since it's not going
> to test much in that case.
Or that is fine with me too.
--
Pedro Alves