On 01/14/2016 07:43 PM, Simon Marchi wrote:
> On 16-01-14 12:28 PM, Pedro Alves wrote:
> Hmm if I try to put a call to
>
> [remote_file target exists "/home/simark/nonexistent"]
>
> It always returns true somehow. When I dig, I find this error:
>
> {rsh to target failed for test -f /home/s
On 16-01-14 12:28 PM, Pedro Alves wrote:
>> So they would need to be changed:
>>
>> -gdb_run_cmd
>> +if ![gdb_run_cmd] {
>> +fail "Failed to run"
>> +}
>>
>
> That's where the "return -code return" hack would come in. You'd
> do that inside gdb_run_cmd so that would return directly to gdb_run
On 01/14/2016 05:13 PM, Simon Marchi wrote:
> On 16-01-14 11:25 AM, Pedro Alves wrote:
>>> The test will be aborted, runtest will output a detailed error, but the
>>> test will still
>>> pass. Intuitively, I would think that a test that throws an error should
>>> automatically
>>> be failed or u
On 16-01-14 11:25 AM, Pedro Alves wrote:
>> The test will be aborted, runtest will output a detailed error, but the test
>> will still
>> pass. Intuitively, I would think that a test that throws an error should
>> automatically
>> be failed or unresolved, since something unexpected happened.
>
On 01/12/2016 10:51 PM, Simon Marchi wrote:
> Hi!
>
> (x-posting to gdb-patches@ and/or dejagnu@, depending on the point of view)
>
> I am trying to make some improvements in the gdb testsuite, especially when
> testing with
> gdbserver on a remote target board. I'd like to add a check so that
