[PATCH v2 5/5] Extend "set cwd" to work on gdbserver
Pedro Alves
palves@redhat.com
Fri Sep 22 10:47:00 GMT 2017
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
More information about the Gdb-patches
mailing list