qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Laurent Desnogues" <laurent.desnogues@gmail.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] alpha ldl_l stl_c fix
Date: Fri, 7 Nov 2008 11:58:14 +0100	[thread overview]
Message-ID: <761ea48b0811070258w7c3cfabdt30353a458ff82156@mail.gmail.com> (raw)
In-Reply-To: <20081106230635.U85421@stanley.csl.cornell.edu>

On Fri, Nov 7, 2008 at 5:10 AM, Vince Weaver <vince@csl.cornell.edu> wrote:
>
> The following patch is needed for a hello world binary to run under
> alpha-linux-user.

Could you please provide me with the binary?

> The issue is the ldl_l and stl_c instructions.  The current implementation
> is a bit confused.
>   ldl_l should set the lock bit, and write the address to a table
>   stl_c should write to memory only if lock bit is set, then return the
>         lock_bit, then reset the lock_bit to zero
>
> The current code does a weird mix of these things that don't seem to work.
>
> This patch fixes things enough for me for hello_world to work, but it still
> isn't correct if we ever want to use these instructions to implement atomic
> loads/stores or run multithreaded code.
>
> Note... the patch includes a commented out branch.  For proper emulation
> that branch should be included, but for some reason on my x86_64 system if
> the branch is included, then the memory address calculation is converted to
> nops for some reason (leading to a segfault).  I'm not sure why that is
> happening.

Comments below.

> Index: target-alpha/translate.c
> ===================================================================
> --- target-alpha/translate.c    (revision 5643)
> +++ target-alpha/translate.c    (working copy)
> @@ -138,13 +138,13 @@
>
>  static always_inline void gen_qemu_ldl_l (TCGv t0, TCGv t1, int flags)
>  {
> -    tcg_gen_mov_i64(cpu_lock, t1);
> +    tcg_gen_movi_i64(cpu_lock, 1);
>     tcg_gen_qemu_ld32s(t0, t1, flags);
>  }

OK.

>  static always_inline void gen_qemu_ldq_l (TCGv t0, TCGv t1, int flags)
>  {
> -    tcg_gen_mov_i64(cpu_lock, t1);
> +    tcg_gen_movi_i64(cpu_lock, 1);
>     tcg_gen_qemu_ld64(t0, t1, flags);
>  }

OK.

>  static always_inline void gen_qemu_stl_c (TCGv t0, TCGv t1, int flags)
>  {
> -    int l1, l2;
> +    int l1;
>
>     l1 = gen_new_label();
> -    l2 = gen_new_label();
> -    tcg_gen_brcond_i64(TCG_COND_NE, cpu_lock, t1, l1);
> +//    tcg_gen_brcondi_i64(TCG_COND_EQ, cpu_lock, 0, l1);
>     tcg_gen_qemu_st32(t0, t1, flags);
> -    tcg_gen_movi_i64(t0, 0);
> -    tcg_gen_br(l2);
>     gen_set_label(l1);
> -    tcg_gen_movi_i64(t0, 1);
> -    gen_set_label(l2);
> -    tcg_gen_movi_i64(cpu_lock, -1);
> +    tcg_gen_mov_i64(t0, cpu_lock); +    tcg_gen_movi_i64(cpu_lock, 0);

It's not the first time your mailer seems to merge diff lines.  Or
is it mine that is wrong?

> +
>  }
>
>  static always_inline void gen_qemu_stq_c (TCGv t0, TCGv t1, int flags)
>  {
> -    int l1, l2;
> +    int l1;
>
>     l1 = gen_new_label();
> -    l2 = gen_new_label();
> -    tcg_gen_brcond_i64(TCG_COND_NE, cpu_lock, t1, l1);
> +//    tcg_gen_brcondi_i64(TCG_COND_EQ, cpu_lock, 0, l1);
>     tcg_gen_qemu_st64(t0, t1, flags);
> -    tcg_gen_movi_i64(t0, 0);
> -    tcg_gen_br(l2);
>     gen_set_label(l1);
> -    tcg_gen_movi_i64(t0, 1);
> -    gen_set_label(l2);
> -    tcg_gen_movi_i64(cpu_lock, -1);
> +    tcg_gen_movi_i64(t0, cpu_lock);
> +    tcg_gen_movi_i64(cpu_lock, 0);
>  }

Both brcond you commented out are wrong;  they should be:

   tcg_gen_brcondi_i64(TCG_COND_NE, cpu_lock, 1, l1);

at least if one follows the spec blindly :-)  But that's not the
root cause of the problem;  they are equivalent given the
way we set lock in ld[ql]_c;  however lock is also used by
helpers;  I need to take a closer look;  so to be on the safe
side using != 1 seems the way to go.

The issue here is that the st[ql]_c routine is called indirectly
by gen_store_mem which allocates the address as a temp
variable;  st[ql]_c generates a brcond before using that
temp and so the liveness analysis phase gets rid of the
temp.  That temp should be replaced by a local temp.
I will propose a patch for that separately including your
modifications.

The remainder looks OK (except of course atomicity is not
respected as you wrote).


Laurent

      reply	other threads:[~2008-11-07 10:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-07  4:10 [Qemu-devel] [PATCH] alpha ldl_l stl_c fix Vince Weaver
2008-11-07 10:58 ` Laurent Desnogues [this message]

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=761ea48b0811070258w7c3cfabdt30353a458ff82156@mail.gmail.com \
    --to=laurent.desnogues@gmail.com \
    --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).