It gets worse: I am beginning to suspect that this race is what ultimately
causes the "xml for the wrong xlen" mystery (if the timing is unlucky, the CSPR
isn't set yet).
-----"Boris Shingarov via gem5-dev" <gem5-dev@gem5.org> wrote: -----
To: gem5-dev@gem5.org
From: "Boris Shingarov via gem5-dev" <gem5-dev@gem5.org>
Date: 08/06/2020 08:14PM
Cc: "Boris Shingarov" <shinga...@labware.com>
Subject: [gem5-dev] Possible race condition (Remote GDB)
It looks to me that there is a race condition inherent in the design of
DataEvent.
The effect is that, even when CPU.wait_for_gdb attr is set and after the the
RSP socket has connected, the relative timing of gdb's vs gem5's execution may
or may not lead to gdb's presence being ignored. It's like "hey gdb,I know you
already connected, but if you aren't quick enough that the qSupported reaches
the queue within N ms after connecting, I am going ahead without you; (and no I
am not telling you what N is)".
It looks like one fundamental issue here is the historical packet-oriented
nature of RSP. But it also looks like remote_gdb.cc:434,
if (!active) {
active = true;
} else {
// Tell remote host that an exception has occurred.
send(csprintf("S%02x", type).c_str());
}
plays a central role.
Can someone comment on how this is intended to work? I must admit the comment
above that code doesn't make sense to me.
_______________________________________________
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
