From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54873) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qta6h-0005FU-9U for qemu-devel@nongnu.org; Wed, 17 Aug 2011 03:00:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qta6g-0001Wu-46 for qemu-devel@nongnu.org; Wed, 17 Aug 2011 03:00:07 -0400 Received: from mail-fx0-f45.google.com ([209.85.161.45]:64049) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qta6f-0001WJ-Qc for qemu-devel@nongnu.org; Wed, 17 Aug 2011 03:00:06 -0400 Received: by fxbb27 with SMTP id b27so557058fxb.4 for ; Wed, 17 Aug 2011 00:00:05 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4E493EAF.3090207@twiddle.net> References: <1313407533-25740-1-git-send-email-khansa@kics.edu.pk> <1313407533-25740-3-git-send-email-khansa@kics.edu.pk> <4E493EAF.3090207@twiddle.net> Date: Wed, 17 Aug 2011 12:00:04 +0500 Message-ID: From: Khansa Butt Content-Type: multipart/alternative; boundary=00151747bb28be5d4704aaae0b7f Subject: Re: [Qemu-devel] [PATCH 2/4] Octeon cpu definitions in target-mips and Octeon specific changes in set_thread_area syscall List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: qemu-devel@nongnu.org --00151747bb28be5d4704aaae0b7f Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 15, 2011 at 8:43 PM, Richard Henderson wrote: > On 08/15/2011 04:25 AM, khansa@kics.edu.pk wrote: > > ((CPUMIPSState *) cpu_env)->tls_value = arg1; > > + if (((CPUMIPSState *) cpu_env)->insn_flags & CPU_OCTEON) { > > + /* tls entry is moved to k0 so that this can be used later > > + currently this thing is tested only for Octeon */ > > + ((CPUMIPSState *) cpu_env)->active_tc.gpr[26] = arg1; > > + } > > You wanted INSN_OCTEON, not CPU_OCTEON, which includes CPU_MIPS64R2. > > That said, this is *not* in the current linux kernel. And I question > the wisdom of changing the user-space ABI for TLS for a single CPU. > > I think you'd better leave this out until it's actually accepted upstream. > with out above fix Octeon user mode binary can not be correctly run on QEMU. This was the behavior on actual hardware which we noticed when we were debugging the user mode binary on Octeon board. (there are instructions in user mode ELF of Octeon which read k0 and k1 values) > > > r~ > --00151747bb28be5d4704aaae0b7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Aug 15, 2011 at 8:43 PM, Richard= Henderson <rth@twi= ddle.net> wrote:
On 08/15/2011 04:25 AM, khansa@kics.edu.pk wrote:
> =A0 =A0 =A0 =A0((CPUMIPSState *) cpu_env)->tls_value =3D arg1;
> + =A0 =A0 =A0if (((CPUMIPSState *) cpu_env)->insn_flags & CPU_O= CTEON) {
> + =A0 =A0 =A0 =A0 =A0/* tls entry is moved to k0 so that this can be u= sed later
> + =A0 =A0 =A0 =A0 =A0 =A0 currently this thing is tested only for Octe= on */
> + =A0 =A0 =A0 =A0 =A0((CPUMIPSState *) cpu_env)->active_tc.gpr[26] = =3D arg1;
> + =A0 =A0 =A0}

You wanted INSN_OCTEON, not CPU_OCTEON, which includes CPU_MIPS64R2.<= br>
That said, this is *not* in the current linux kernel. =A0And I question
the wisdom of changing the user-space ABI for TLS for a single CPU.

I think you'd better leave this out until it's actually accepted up= stream.

with out above fix Octeon user = mode binary can not be correctly run on QEMU.
This was the=A0beha= vior on actual hardware which we noticed when we were debugging the=A0
user mode binary on Octeon board.=A0
(there are instructions= in user mode ELF of Octeon which read k0 and k1 values)=A0


r~

--00151747bb28be5d4704aaae0b7f--