[Qemu-devel] qemu-mips on x86: stat() broken in 0.8.2

[Qemu-devel] qemu-mips on x86: stat() broken in 0.8.2

[Dave Denholm]

Hi,
   I think emulation of stat() on qemu-mips (big-endian) hosted on x86
is broken. Or more generally, probably either-endian mips on the
opposite-endian host.


In linux-user/syscall.c around line 2892 in the 0.8.2 release, it uses
tswapl() for ppc, and tswap16() for all other targets. But target_stat.t_mode
is 32-bit on both mips and ppc, and so I think mips also needs a 32-bit
swap.My local fix is just to change

#if defined(TARGET_PPC)

to

#if defined(TARGET_PPC) || defined(TARGET_MIPS)

and that seems to fix the problem I was seeing. A slightly more
general test might be

  if (sizeof(target_st->st_mode) == 4) {
     ... tswapl();
  } else {
     ... tswap16();
  }

but I'll leave that up to you.


I was confused about why the busybox executable in the prebuilt tests
seemed to work, and worked the same with both the original executable
and my modified version, but it uses fstat64() rather than stat(), and
that of course is a different code path. (fstat64() uses the put_user
macro which automatically senses the width of the target. Any particular
reason for the difference ?)


Another small change I have locally is to suppress warnings about
unimplemented mips system call 4147 (cache flush). Since qemu handles
self-modifying code transparently (in effect, a coherent cache, or
no cache at all), the flush can be implemented as a no-op.

In fact, it might be mildly interesting if the detection of
self-modifying code was turned off for non-x86 targets, and
cache-flush calls were required to discarded generated code, since
that would make it possible to detect missed calls to cache-flush on
programs with self-modifying code. But perhaps I have a different
agenda from other users in this area ;-)


diff below

dd
-- 
Dave Denholm              <ddenholm@esmertec.com>       http://www.esmertec.com


$ diff --unified syscall.c.~1~ syscall.c
--- syscall.c.~1~       2006-07-22 18:23:34.000000000 +0100
+++ syscall.c   2006-10-10 13:00:56.695069058 +0100
@@ -2889,7 +2889,7 @@
                 lock_user_struct(target_st, arg2, 0);
                 target_st->st_dev = tswap16(st.st_dev);
                 target_st->st_ino = tswapl(st.st_ino);
-#if defined(TARGET_PPC)
+#if defined(TARGET_PPC) || defined(TARGET_MIPS)
                 target_st->st_mode = tswapl(st.st_mode); /* XXX: check this */
                 target_st->st_uid = tswap32(st.st_uid);
                 target_st->st_gid = tswap32(st.st_gid);
@@ -3785,6 +3785,12 @@
        break;
     }
 #endif
+#ifdef TARGET_NR_cacheflush
+    case TARGET_NR_cacheflush:
+        /* self-modifying code is handled automatically, so nothing needed */
+        ret = 0;
+        break;
+#endif
 #ifdef TARGET_NR_security
     case TARGET_NR_security:
         goto unimplemented;

[Qemu-devel] gdb support for qemu-mips (user mode)

[Dave Denholm]

Hi,
   user-mode emulation of mips allows gdb to connect and set
breakpoints, but when the breakpoint is reached, the emulator bombs
out with an unhandled cpu exception 0x10002 (or something like that).

I think it's just a missing  case EXCP_DEBUG in the mips-specific
cpu_loop in linux-user/main.c (around line 1301 in 0.8.2)

Since all the other archs do exactly the same thing for EXCP_DEBUG, I
just pasted that code into the mips version, and it seemed to work, at
least a bit - when I was single-stepping through a fn, gdb got stuck
complaining that it couldn't find a fn for a given ip address.

dd
-- 
Dave Denholm              <ddenholm@esmertec.com>       http://www.esmertec.com


--- linux-user/main.c.~1~	2006-07-22 18:23:34.000000000 +0100
+++ linux-user/main.c	2006-10-25 11:14:30.752887950 +0100
@@ -1350,6 +1350,20 @@
         case EXCP_INTERRUPT:
             /* just indicate that signals should be handled asap */
             break;
+        case EXCP_DEBUG:
+            {
+                int sig;
+
+                sig = gdb_handlesig (env, TARGET_SIGTRAP);
+                if (sig)
+                  {
+                    info.si_signo = sig;
+                    info.si_errno = 0;
+                    info.si_code = TARGET_TRAP_BRKPT;
+                    queue_signal(info.si_signo, &info);
+                  }
+            }
+            break;
         default:
             //        error:
             fprintf(stderr, "qemu: unhandled CPU exception 0x%x - aborting\n", 

[Qemu-devel] qemu user mode spins when stopped at a breakpoint

[Dave Denholm]

Hi,
   I've just noticed that if qemu is used in user mode, with a gdb
attached, and it stops at a breakpoint, qemu spins consuming 100% cpu.
Observed with both arm and mips (after applying the patch I sent
earlier).

The problem is in gdb_handlesig() in gdbstub.c - it uses a simple loop
to read blocks from the gdb connection, but the socket has been set in
non-blocking mode (around line 920 in gdb_accept), so this loop is an
active spin.

Simple fix is to put in a blocking call to poll() in the loop, either
each time round, or whenever read() returns EWOULDBLOCK. However,
it's not immediately clear to me why the socket needs to be set
non-blocking..?



I don't think user-mode currently allows gdb to interrupt the vm while
it's running. That presumably wouldn't be too hard to do - either
poll() the socket from the main loop (perhaps it's sufficient to check
on system calls only ?), or arrange for a SIGIO to be delivered when
data is recived on the socket.


dd
-- 
Dave Denholm              <ddenholm@esmertec.com>       http://www.esmertec.com

Re: [Qemu-devel] gdb support for qemu-mips (user mode)

[Daniel Jacobowitz]

On Wed, Oct 25, 2006 at 01:04:12PM +0100, Dave Denholm wrote:
> Since all the other archs do exactly the same thing for EXCP_DEBUG, I
> just pasted that code into the mips version, and it seemed to work, at
> least a bit - when I was single-stepping through a fn, gdb got stuck
> complaining that it couldn't find a fn for a given ip address.

I can confirm that this patch is correct - I have a bit for bit
identical copy in my working directory (I tend to batch on submitting
things...).

-- 
Daniel Jacobowitz
CodeSourcery