All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mikhail Ilin <m.ilin@samsung.com>
To: qemu-devel@nongnu.org
Cc: riku.voipio@iki.fi
Subject: Re: [Qemu-devel] [PATCH] linux-user: qemu treats TLS pointer in the wrong way when spicifying cpu cotrex-a15.
Date: Mon, 16 Mar 2015 14:32:08 +0300	[thread overview]
Message-ID: <5506BF38.6040503@samsung.com> (raw)
In-Reply-To: <1426505198-2411-1-git-send-email-m.ilin@samsung.com>


Here is a sample to prove the issue

$ echo "int main() { return 0; }" > /tmp/prog.c
$ arm-linux-gnueabi-gcc -g -o /tmp/prog /tmp/prog.c
$ qemu-arm -cpu cortex-a15 -L 
/home/michail/arm/arm-linux-gnueabi/sys-root /tmp/prog
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)

prog backtrace look the following way

$ qemu-arm -g 1234 -cpu cortex-a15 -L 
/home/michail/arm/arm-linux-gnueabi/sys-root /tmp/prog

$ arm-linux-gnueabi-gdb -ex 'set sysroot 
/home/michail/arm/arm-linux-gnueabi/sys-root/' -ex 'file /tmp/prog' -ex 
'target remote :1234'
(gdb) c

Program received signal SIGSEGV, Segmentation fault.
0xf6690290 in __GI___ctype_init () at ctype-info.c:31
31        *bp = (const uint16_t *) _NL_CURRENT (LC_CTYPE, 
_NL_CTYPE_CLASS) + 128;
(gdb) bt
#0  0xf6690290 in __GI___ctype_init () at ctype-info.c:31
#1  0xf67e62e4 in call_init (l=0xf67d5708, argc=1, argv=0xf6ffef14, 
env=0xf6ffef1c) at dl-init.c:69
#2  0xf67e6434 in _dl_init (main_map=0xf67fe960, argc=1, 
argv=0xf6ffef14, env=0xf6ffef1c) at dl-init.c:132
#3  0xf67d6d74 in _dl_start_user () from 
/home/michail/arm/arm-linux-gnueabi/sys-root/lib/ld-linux.so.3
(gdb) disassemble
Dump of assembler code for function __GI___ctype_init:
    0xf669026c <+0>:     ldr     r12, [pc, #88]  ; 0xf66902cc 
<__GI___ctype_init+96>
    0xf6690270 <+4>:     strd    r4, [sp, #-12]!
    0xf6690274 <+8>:     mrc     15, 0, r3, cr13, cr0, {3}
    0xf6690278 <+12>:    str     lr, [sp, #8]
    0xf669027c <+16>:    ldr     r0, [pc, #76]   ; 0xf66902d0 
<__GI___ctype_init+100>
    0xf6690280 <+20>:    ldr     r1, [pc, #76]   ; 0xf66902d4 
<__GI___ctype_init+104>
    0xf6690284 <+24>:    ldr     r2, [pc, #76]   ; 0xf66902d8 
<__GI___ctype_init+108>
    0xf6690288 <+28>:    ldr     r12, [pc, r12]
    0xf669028c <+32>:    ldr     r0, [pc, r0]
=> 0xf6690290 <+36>:    ldr     r12, [r3, r12]
    0xf6690294 <+40>:    ldr     r12, [r12]
(gdb) p $r3
$1 = 0

Register r3 comes from mrc and should contain pointer to TLS. In runtime
cp15.tpidruro_ns contains a valid pointer that is assigned with
__ARM_NR_set_tls, cp.tpidruro_s is 0 and its value is returned with mrc.

-- Mikhail

On 16.03.2015 14:26, Mikhail Ilyin wrote:
> From: Mikhail Ilyin <m.ilin@samsung.com>
>
> At present there are two copies of TPIDRURO register for secure and unsecure
> access. TLS is set via a system call __ARM_NR_set_tls and its handler
> (cpu_set_tls) always assigns a provided value to unsecure register
> tpidrro_el[0]/tpidruro_ns. But during execution for cortex-a15 mrc instruction
> returns TLS from secure rigester tpidruro_s which is 0 and causes SIGSEGV.
>
> Signed-off-by: Mikhail Ilyin <m.ilin@samsung.com>
> ---
>   linux-user/arm/target_cpu.h | 15 ++++++++++++++-
>   linux-user/main.c           |  2 +-
>   2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/linux-user/arm/target_cpu.h b/linux-user/arm/target_cpu.h
> index d8a534d..6832262 100644
> --- a/linux-user/arm/target_cpu.h
> +++ b/linux-user/arm/target_cpu.h
> @@ -29,7 +29,20 @@ static inline void cpu_clone_regs(CPUARMState *env, target_ulong newsp)
>
>   static inline void cpu_set_tls(CPUARMState *env, target_ulong newtls)
>   {
> -    env->cp15.tpidrro_el[0] = newtls;
> +    if (access_secure_reg(env)) {
> +        env->cp15.tpidruro_s = newtls;
> +    } else {
> +        env->cp15.tpidrro_el[0] = newtls;
> +    }
> +}
> +
> +static inline target_ulong cpu_get_tls(CPUARMState *env)
> +{
> +    if (access_secure_reg(env)) {
> +        return env->cp15.tpidruro_s;
> +    } else {
> +        return env->cp15.tpidrro_el[0];
> +    }
>   }
>
>   #endif
> diff --git a/linux-user/main.c b/linux-user/main.c
> index 6bd23af..6e446de 100644
> --- a/linux-user/main.c
> +++ b/linux-user/main.c
> @@ -566,7 +566,7 @@ do_kernel_trap(CPUARMState *env)
>           end_exclusive();
>           break;
>       case 0xffff0fe0: /* __kernel_get_tls */
> -        env->regs[0] = env->cp15.tpidrro_el[0];
> +        env->regs[0] = cpu_get_tls(env);
>           break;
>       case 0xffff0f60: /* __kernel_cmpxchg64 */
>           arm_kernel_cmpxchg64_helper(env);
>

  reply	other threads:[~2015-03-16 11:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-16 11:26 [Qemu-devel] [PATCH] linux-user: qemu treats TLS pointer in the wrong way when spicifying cpu cotrex-a15 Mikhail Ilyin
2015-03-16 11:32 ` Mikhail Ilin [this message]
2015-03-16 12:05 ` Peter Maydell
2015-03-16 12:14   ` Mikhail Ilin

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=5506BF38.6040503@samsung.com \
    --to=m.ilin@samsung.com \
    --cc=qemu-devel@nongnu.org \
    --cc=riku.voipio@iki.fi \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.