Re: [PATCH 4/4] Fix solib-display.exp remote check

[Simon Marchi <simon dot marchi at polymtl dot ca>]

On 2016-04-11 14:27, Pedro Alves wrote:
> On 04/06/2016 04:15 AM, Simon Marchi wrote:
>
> > The test uses "run"
>
> Does it have to?  Can't we use "kill" followed by runto_main
> again, instead of gdb_start_cmd ?

I tried to change the test so that it uses kill, followed with 
gdb_run_cmd combined with a breakpoint at main (runto_main wouldn't 
work, since it doesn't expect the variable display before the prompt).

The problem with native-gdbserver (and probabley any stub target) is 
that when you run again, it launches a new gdbserver and connects to it. 
 Right after connecting, gdb tries to display the variables, but since 
we're stopped before the libs are loaded, we get:

warning: Unable to display "a_global": No symbol "a_global" in current 
context.
warning: Unable to display "b_global": No symbol "b_global" in current 
context.
warning: Unable to display "c_global": No symbol "c_global" in current 
context.

and gdb trashes the displays.  The rest of the test fails because it 
expects the displays to be there (I think that's the point of that 
test).  So for now at least, I'd keep the test like this, disabled for 
stub targets.

> Why did you move the check to within the loop?  I thought one
> could check [target_info exists use_gdb_stub] at the top?
> I'd find the patch OK with that.  It'd be nicer to avoid
> gdb_start_cmd in the first place, but use_gdb_stub is still
> an improvement.

I have sent a mini-series as an update, including your use_gdb_stub 
procedure suggestion.

  https://sourceware.org/ml/gdb-patches/2016-05/msg00018.html

Thanks,

Simon