On 2019-07-25 3:13 p.m., Simon Marchi wrote:
> Hi again!
>
> This is a little reminder about the Cauldron 2019. If you plan on attending,
> please
> take a few minutes to send your registration (instructions are on the wiki
> [1]), it
> helps us greatly if you do
On 2019-03-14 5:28 p.m., Simon Marchi wrote:
> Hi all,
>
> We are very pleased to invite you all to the GNU Tools Cauldron on 12-15
> September 2019. This year's Cauldron will be held in Montreal, Canada.
> See the wiki page for details:
>
> https://gcc.gnu.org/
On 2018-11-27 5:46 p.m., Steve Ellcey wrote:
> I have a question about the special handling of the 'unix' name in
> dejagnu. I am doing some GCC testing which uses dejagnu and I
> want to create a new baseboard (unix-sysroot) which is just like
> unix but sets ldflags so I can run GCC with a newl
On 16-02-14 10:18 PM, Ben Elliston wrote:
> Earlier this year, there was a discussion about the understated
> --status option. This option causes runtest to exit with an exit code
> of 1 ("failure" to the shell) if an error is encountered in any of the
> Tcl scripts. The thread starts here:
>
>
The local "exists" case:
return [file exists $file]
returns 1 when the file exists, 0 otherwise. The remote case does the
opposite, because it returns the process return code directly, where 0
is true/success/exists and non-zero is false/fail/does not exist. This
patch fixes the remote case b
I think that the current form:
if ( !is_remote } {
# Do non-remote stuff and return
}
# Do remote stuff
is not very clear and that this would be more readable.
if ( !is_remote } {
# Do non-remote stuff
} else {
# Do remote stuff
}
That's all.
ChangeLog:
* lib/r
On 16-01-17 03:27 AM, Joel Brobecker wrote:
> I admit that some of it flying a little over my head... Does it
> mean that we will be able to abort a test if we detect a timeout?
> This is one of the things I wanted to do, but didn't have a solution
> for, so it'd be fantastic if it helped with that
On 16-01-14 02:48 PM, Pedro Alves wrote:
>> Anyway, the point is not to fix it for my particular case, but to make the
>> general
>> testsuite more robust. I think I'll send a patch for Dejagnu for the
>> "unresolved"
>> solution, and see what the maintainers think.
>
> If you're willing to do
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 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.
>
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 if the
gdbserver
specified by the user does not exist on
11 matches
Mail list logo
