Hello Stanislav, Jim,
On 22/10/06, Stanislav Shwartsman <stl@...> wrote:
> Please check with current CVS snapshot.
I'll try in a few moments to see what it does and whether it contains
everything. I'd most like to see one mode in which it prints rax-rdi
and r8-r15, plus possibly fsbase and gsbase, similar for others (all
segments and gpr's), one for printing FP-ish registers (fp0-fp7/15 or
mm0-mm15), one for printing SSE registers (xmm0-xmm15) and one for
printing control, debug and CPU-based registers. Also, I'm wondering
whether there's a command for reading MSR's from the debugger?
> 4. 'info registers' and 'info cpu' now will be pre/processor based in SMP
> mode instead of printing state for all the CPUs.
How can you properly debug multiple cpu's in a single debugger? And if
you do find something out, please recommend it to Borland and
Microsoft ;)
Just for a mental reminder, on a 64-bit cpu CR8 and EFER are pretty
important in adding to the full state.
For the rest, my intense compliments on the quality of Bochs over the
past years. I've been making a whole load of mistakes in my code and
everytime I tried it in bochs, it was spot on in telling me what was
wrong. The only main difference between using plain bochs and a real
computer is the memory initialization, where I would like an option
for bochs to init it with /dev/urandom or /dev/random for testing just
a tad more like a real computer.
Oh, another tidbit, when the cpu crashes due to some triple fault, the
cpu values are lost because the cpu is reset first and then the prompt
for the fault is given. If you can swap these around that would be
great. The memory isn't blanked in between though. Also, there's a bug
in handling a triple fault in paged code. I'd made a mistake in
loading my kernel code making it a few bytes off (240 to be exact) so
the jump to the entry point ended up jumping on 0xFF 0xFF, which is
invalid. All registers were reset, the memory wasn't but the next
instruction was fetched before CS/EIP were reset. CS was 0, EIP
pointed to 0xFFFFFFFFC0006768 which was truncated to 0xC0006768 for
lookup, resulting in an "reading bogus memory" instead of properly
rebooting after the triple fault.
There's also an issue with lbreak in longmode when accessing the
kernel-mode section of memory, it reads the address as 32-bits in all
cases, then figuring out that it doesn't work.
Regards and if there's something that I can help bochs with (aside
from using and implicitly testing it), just shout and I'll try what I
can.
Regards,
Peter
|
