Re: [PATCH v2 5/5] Extend "set cwd" to work on gdbserver

[Pedro Alves <palves@redhat.com>]

On 09/21/2017 12:49 AM, Sergio Durigan Junior wrote:
> On Wednesday, September 20 2017, Pedro Alves wrote:

>> This all looks stale to me.
> 
> Indeed, sorry about this mistake.  I will rewrite the entry as follows:
> 
> * New features in the GDB remote stub, GDBserver
> 
>   ** GDBserver is now able to enter a directory before starting an
>      inferior.
> 
>      The user can set the desired working directory to be used by the
>      remote inferior on GDB, using the new "set cwd" command, which
>      will instruct GDB to tell GDBserver about this directory change
>      the next time an inferior is run.

I still think this is talking too much in terms of implementation
detail, but I'll reply again to v3.

>>> --- a/gdb/testsuite/gdb.base/set-cwd.exp
>>> +++ b/gdb/testsuite/gdb.base/set-cwd.exp
>>> @@ -15,10 +15,16 @@
>>>  # You should have received a copy of the GNU General Public License
>>>  # along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>>  
>>> -if { ![isnative] || [is_remote target] || [is_remote host]
>>> -     || [target_info gdb_protocol] == "extended-remote" } then {
>>> -    untested "not implemented on gdbserver"
>>> -    return
>>> +if { [target_info exists gdb_protocol] } {
>>> +    if { [target_info gdb_protocol] == "remote" } {
>>> +	untested "not implemented on native-gdbserver"
>>> +	return
>>> +    }
>>> +
>>> +    load_lib gdbserver-support.exp
>>> +    if { [skip_gdbserver_tests] } {
>>> +	return
>>> +    }
>>>  }
>>
>> This drops the is_remote host and target checks, but the test is
>> using  "$::env(HOME)", so it really can't work when
>> remote-host/target testing, because that is accessing HOME in the
>> build machine (where dejagnu runs) not of the host machine
>> (where gdb runs) or the target machine (where gdbserver runs):
>>
>> proc test_tilde_expansion { } {
>>     if { [info exists ::env(HOME)] } {
>> 	with_test_prefix "test tilde expansion" {
>> 	    set home $::env(HOME)
> 
> OK, that makes sense, but I wasn't aware that there is a problem between
> "host" and "build" machines.  This is becoming absurdly confuse to me,
> sorry.

We've discussed this off list already.

> 
> In this case, I'd have to check for ![is_remote host], is that right?
> 
>> I don't understand the explicit check for gdbserver in
>> skip_gdbserver_tests.
> 
> I was thinking of the following scenario:
> 
> - The users wants to skip gdbserver tests
> 
> - He runs the test as "make check-gdb TESTS=gdb.base/set-cwd.exp"
> 
> - Because of the unconditional call to "skip_gdbserver_tests", the test
>   doesn't run at all, even though the test *should* run because the user
>   hasn't specified any remote board, etc.

And that's what I don't understand at all.  skip_gdbserver_tests
is useful for the gdb.server/ tests that spawn gdbserver even
if testing with the local/unix board, i.e., the native target.
But this testcase isn't spawning gdbserver manually, unlike e.g., the
gdb.server/ tests.  It just runs against whatever target is
specified by --target_board.

> 
>> Seems to me that instead of that, and the "remote" check we should skip
>> the test if use_gdb_stub, because that's what indicates that when you
>> connect to a target, you're already debugging something, like with
>> plain remote debugging.
> 
> OK, so a simple check to "[use_gdb_stub]" would suffice, you say?  That
> doesn't solve the problem with calling ::env above, right?

Thanks,
Pedro Alves