Please help me understand STOP_TRACE bit usage in function cpu_loop_debugger

--===============4528504336537737396==
Content-Type: multipart/alternative; boundary="000000000000bb7b5e062e80414b"

--000000000000bb7b5e062e80414b
Content-Type: text/plain; charset="UTF-8"

Hello,

I'm a UEFI firmware engineer. We sometimes have to do changes very early in
the BIOS flow after cold reset (the few thousands of instructions after the
reset vector) and Bochs and its built-in debugger has been very useful to
test these changes for some years now.

I have upgraded my custom simulator recently to use Bochs 3.0 and I have
run into an issue where the x86 instruction execution loop in function
*cpu_loop_debugger* seems to ignore the STOP_TRACE bit and fetch invalid
instructions beyond taken branches.

More specifically, I'm concerned by this test at line 117 in cpu.cc

      if (BX_CPU_THIS_PTR async_event & ~BX_ASYNC_EVENT_STOP_TRACE) break;

This test breaks the execution loop on all "async events" except STOP_TRACE
so wouldn't it ignore STOP_TRACE bit set by branch instructions?

Moreover this test seems to contradict the purpose of line 93

    // stop tracing after every instruction to handle in internal debugger
    BX_CPU_THIS_PTR async_event |= BX_ASYNC_EVENT_STOP_TRACE;

How can it "stop tracing after every instruction" if the STOP_TRACE bit
isn't tested after executing an instruction?

Hope my question makes sense. Thanks for this very helpful open-source x86
emulator!

--000000000000bb7b5e062e80414b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<div><br></div><div>I&#39;m a UEFI firmware engineer=
. We sometimes have to do changes very early in the BIOS flow after cold re=
set (the few thousands of instructions after the reset vector) and Bochs an=
d its built-in debugger has been very useful to test these changes for some=
 years now.</div><div><br></div><div>I have upgraded my custom simulator re=
cently to use Bochs 3.0 and I have run into an issue where the x86 instruct=
ion execution loop in function <b>cpu_loop_debugger</b> seems to ignore the=
 STOP_TRACE bit and fetch invalid instructions beyond taken branches.</div>=
<div><br></div><div>More specifically, I&#39;m concerned by this test at li=
ne 117 in cpu.cc</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 if (BX_CPU_T=
HIS_PTR async_event &amp; ~BX_ASYNC_EVENT_STOP_TRACE) break;<br></div><div>=
<br></div><div>This test breaks the execution loop on all &quot;async event=
s&quot; except STOP_TRACE so wouldn&#39;t it ignore STOP_TRACE bit set by b=
ranch instructions?</div><div><br></div><div>Moreover this test seems to co=
ntradict the purpose of line 93</div><div><br></div><div>=C2=A0 =C2=A0 // s=
top tracing after every instruction to handle in internal debugger<br>=C2=
=A0 =C2=A0 BX_CPU_THIS_PTR async_event |=3D BX_ASYNC_EVENT_STOP_TRACE;<br><=
/div><div><br></div><div>How can it &quot;stop tracing after every instruct=
ion&quot; if the STOP_TRACE bit isn&#39;t tested after executing an instruc=
tion?</div><div><br></div><div>Hope my question makes sense. Thanks for thi=
s very helpful open-source x86 emulator!</div><div><br></div><div><br></div=
></div>

--000000000000bb7b5e062e80414b--


--===============4528504336537737396==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============4528504336537737396==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
bochs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bochs-developers

--===============4528504336537737396==--