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 resece 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
