qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Erik van der Kouwe" <vdkouwe@cs.vu.nl>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Porting QEMU to Minix - op_goto_tb1 segfaults because tb_next[1] is NULL
Date: Wed, 22 Aug 2007 20:34:58 +0200	[thread overview]
Message-ID: <000301c7e4eb$24b81600$0200a8c0@Feanor> (raw)

Dear all,

I have been attempting to get QEMU to run on the Minix operation system 
(running on x86, see http://www.minix3.org/ for more info on the OS) for 
some time now. I have gotten the program to compile and have added the 
Minix-specific a.out-like format to dyngen. I am quite certain this bit 
works, as I have been looking at the generated relocated code in the 
disassebler at length.

My problem is the following: quickly after starting I get a segmentation 
fault while the generated code is running.

This happens in the code generated from op_goto_tb1 and is caused by jumping 
to a NULL pointer. This NULL pointer originates from the tb_next[1] field of 
the translation block data structure passed as a parameter. I have verified 
in the disassembler that the parameter in the generated code is processed 
correctly and the field is indeed tb_next[1].

I would like to know what would be the normal place for tb_next[1] to be 
initialized, and perhaps if anyone has a suggesting why that might not be 
happening in this case.

I found that (but please correct me if I am wrong) the assignment can only 
take place in tb_set_jmp_target, which in turn is called only by tb_add_jump 
and tb_reset_jump. When stepping through the code I found that neither of 
these functions is ever called either.

Versions i'm using:
- Qemu 0.8.2 (newest when i started, but from changelog ISTM upgrading to 
0.9.0 would not help)
- Minix 3.1.2 (current release version)
- GCC 3.4.3 (version that comes with Minix)

Compilation settings:
- Target: i386-softmmu (must use soft MMU, Minix does not support paging)
- target_user_only enabled
- CONFIG_SOFTFLOAT enabled (Minix does not support FPU, everything is 
emulated anyways)
- USE_DIRECT_JUMP disabled (but had similar problem before disabling, and 
this seems easier to debug)

Virtual machine:
- The Linux image at http://fabrice.bellard.free.fr/qemu/linux-0.2.img.bz2

If you need any more information to answer my question (or at least guide me 
in the right direction) do not hesitate to ask.

Thanks in advance for any answers, suggestions or other advice you may have.

With kind regards,
Erik van der Kouwe 

             reply	other threads:[~2007-08-22 18:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-22 18:34 Erik van der Kouwe [this message]
2007-08-23  9:37 ` [Qemu-devel] Porting QEMU to Minix - op_goto_tb1 segfaults because tb_next[1] is NULL Ulrich Hecht
2007-08-23 19:38   ` [Qemu-devel] Porting QEMU to Minix - op_goto_tb1 segfaultsbecause " Erik van der Kouwe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000301c7e4eb$24b81600$0200a8c0@Feanor' \
    --to=vdkouwe@cs.vu.nl \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).