1 |
dpavlin |
22 |
$Id: BUGS,v 1.41 2006/02/18 13:15:20 debug Exp $ |
2 |
dpavlin |
2 |
|
3 |
dpavlin |
22 |
If you experience a CRASH, then please run gdb on the core dump, do a back |
4 |
|
|
trace, and send it to me. |
5 |
dpavlin |
20 |
|
6 |
dpavlin |
22 |
Some of the known bugs are: |
7 |
dpavlin |
20 |
|
8 |
dpavlin |
22 |
x) Floating point coprocessor stuff is buggy. Writing a new (portable) |
9 |
|
|
framework for fp emulation is in the TODO. |
10 |
dpavlin |
2 |
|
11 |
dpavlin |
22 |
x) Linux/DECstation (Debian) oopses extremely often unless -U is used at |
12 |
|
|
run-time. I'm not sure yet why it bugs out. With -U, the risk is lower, |
13 |
|
|
but not completely gone. _Maybe_ this is a bug in Linux. Why? Because the |
14 |
|
|
oops message contains things like ANSI escape codes and characters in |
15 |
|
|
registers (including the pc and return address register); this looks like |
16 |
|
|
a buffer overflow in the serial driver. (Another thing that gives weight |
17 |
|
|
to this theory is that the serial driver in Linux is still being |
18 |
|
|
developed.) But this is just a guess. |
19 |
dpavlin |
2 |
|
20 |
dpavlin |
22 |
x) Binary-translated 64-bit stuff checks to see if the top 32 bits are |
21 |
dpavlin |
2 |
all zeroes or all ones, and then uses 32-bit tables and such. This |
22 |
|
|
is a bug. It should check the top 33 bits, not 32. (Alpha only, already |
23 |
|
|
fixed for i386?) |
24 |
|
|
|
25 |
dpavlin |
22 |
x) NetBSD/arc 2.0 uses the ASC controller in a way which GXemul cannot yet |
26 |
|
|
handle. (NetBSD 1.6.2 works ok.) (Possibly a problem in NetBSD itself, |
27 |
|
|
http://mail-index.netbsd.org/source-changes/2005/11/06/0024.html suggests |
28 |
|
|
that.) |
29 |
dpavlin |
2 |
|