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