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

[Pedro Alves <pedro at codesourcery dot 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