Christophe Lyon wrote:
I've been debugging a problem where we clear "isremote" with:
unset_board_info isremote
set_board_info isremote 0
but this isn't taken into account correctly by is_remote (in
framework.exp), when we use target variants, because is_remote removes
the target variant specifications.
For instance, if we use --target-board=qemu, everything works well,
but if we use --target-board=qemu/-mcpu=XXX, then:
==========
unset_board_info isremote
set_board_info isremote 0
==========
clear the "isremote" flag for board=="qemu/-mcpu=XXX", but subsequent
calls to is_remote actually check the isremote flagfor board=="qemu"
(after removing the part after the "/")
Is that a bug in is_remote, or is there a clean way of setting "isremote"?
I am still unsure about exactly what a "board" is supposed to be in
DejaGnu (perhaps someone else can clarify) but I suspect that you may be
misunderstanding the variant feature. As far as I can tell, a "board"
is supposed to be a physical device with some kind of hard-wired or
network connection to the machine running DejaGnu, or a virtual device
that behaves similarly. As such, *all* QEMU system emulator targets are
"remote" in this sense -- isremote is set if the target is *not*
localhost. A simulator running on localhost is *not* localhost -- it is
a separate (virtual) machine. (For QEMU, things get interesting when
you consider its user mode emulation feature, which is *not* remote in
the sense that DejaGnu uses, but *does* require special handling to run
programs, unless binfmt_misc is being used to test something else using
an installed QEMU.) For similar reasons, the "unix" board is special
and magic in various places -- "unix" *is* localhost in DejaGnu.
I have been working around default_target_compile lately (just finished
the local-compile tests; although the tests are verifying the
currently-known-broken Ada support, the goal is to have solid regression
tests to enable rewriting default_target_compile to more explicitly
express the flag-ordering constraints it follows so that the broken Ada
support can be cleanly fixed instead of further tangling the
"spaghetti") and it seems to me that the actual criteria for a "remote"
board is that files must be explicitly transferred between the machine
running DejaGnu and the remote target. There is also different handling
for executing programs on a remote board: on localhost, programs are
run using Expect's "spawn" command, while on remote boards, programs are
run by using Expect to interact with a remote shell. A
single-system-image cluster (as I understand that HURD is supposed to
eventually support) makes this all kinds of "fun" to explain, because
"localhost" will not always be local anymore!
There also seems to be an abstraction layer for particular targets to
override normal remote handling -- QEMU may need that, depending on what
you are testing. (In theory, you could use DejaGnu and QEMU to test
Linux kernels if you override certain procedures.)
-- Jacob
_______________________________________________
DejaGnu mailing list
DejaGnu@gnu.org
https://lists.gnu.org/mailman/listinfo/dejagnu
