[PATCH v2] Fix random dejagnu test abort with simulator target

[Bernd Edlinger]

On 4/22/24 15:49, Andrew Burgess wrote:
> Bernd Edlinger <bernd.edlinger@hotmail.de> writes:
>> +# The test-case relies on "run" from the command line, so it only works
>> +# with "target native", so we need host == target.
> 
> I'm currently reading and rereaching the V1 series to try and understand
> what's going on here, but I don't understand this comment.
> 
>   # The test-case relies on "run" from the command line, so it only works
>   # with "target native", so we need host == target.
> 
> Just doesn't make sense to me: 'target extended-remote' will also
> support the `run` command, as will 'target sim'.
> 
> The conclusion might well be valid, but I think the logic used to
> justify it is incorrect.   Can we rephrase this comment so it makes
> sense?
> 

I probably don't know how to properly explain that.
But would very much appreciate any advice how to.

The test case ties to do this:
The gdb host/build environment is x86_64-pc-linux-gnu,
and the target environment is riscv-unknown-elf
with newlib so the run command would work but only
to run a program that was built with my riscv-unknown-elf-gcc.
But the test case ties to run "/usr/bin/sleep 3",
therefore the gdb is unable to run that, and since
the stdin is redirected to /dev/null the gdb terminates
immediately, so the test script terminates with one FAIL
and one PASS test case, BUT the after 1000 is still hanging
on, and interrupts the whole test run, or just one test case
that depends on some kind of race condition, and maybe also
a bit on the dejagnu version.
It is interesting that the gdb_pid is no longer known, when
the after 1000 executes, and creates the cryptic message
ERROR: (DejaGnu) proc "bgerror {can't read "gdb_pid": no such variable}" does not exist.

Please feel free to ask if I can give more information.


Thanks
Bernd.