Re: [patch] Fix a crash when displaying variables from shared ?library.

Pedro Alves
2009-03-18T04:12:48Z

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