All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hunter Laux <hunterlaux@gmail.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: riku.voipio@iki.fi, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] linux-user: Handle new ARM breakpoint instruction
Date: Wed, 25 Jun 2014 09:11:56 -0700	[thread overview]
Message-ID: <CAMQF8Mi53VzoLV5fO-zRnOaLbjCv07DPc4rY3JLzANQjJx0U4Q@mail.gmail.com> (raw)
In-Reply-To: <CAFEAcA-fdcUZoCbie6ofxN2ECznHSZn+wQ8Tg6T2YDtLW7JeMA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3175 bytes --]

Isn't the instruction decoder really the wrong place to do that since that
exception is handled differently in user space and kernel space. It's my
understanding that the instruction decoder is also shared by machine
emulation. If you're doing machine emulation you'll still want to throw
EXCP_UDEF because that's what Linux is expecting.

http://lxr.free-electrons.com/source/arch/avr32/kernel/traps.c#L212

It fixed by signal 4 problem during my SBCL build, but there might be a
better way to fix this. I think they use every trick in the book to get
that thing working.

-Hunter Laux
On Jun 25, 2014 2:18 AM, "Peter Maydell" <peter.maydell@linaro.org> wrote:

> On 25 June 2014 05:08, Hunter Laux <hunterlaux@gmail.com> wrote:
> > This instruction space is guaranteed to be undefined.
> > ARM:   xxxx 0111 1111 xxxx xxxx xxxx 1111 xxxx
> > Thumb: 1101 1110 xxxx xxxx
> >
> > The breakpoint instructions were selected from this instruction space.
> > Linux traps the illegal instruction and sends a SIGTRAP if it is a
> breakpoint.
> >
> > Here is the Linux implementation:
> > http://lxr.free-electrons.com/source/arch/arm/kernel/ptrace.c#L221
> >
> > Signed-off-by: Hunter Laux <hunterlaux@gmail.com>
> > ---
> >  linux-user/main.c | 18 ++++++++++++++++++
> >  1 file changed, 18 insertions(+)
> >
> > diff --git a/linux-user/main.c b/linux-user/main.c
> > index 900a17f..91f2681 100644
> > --- a/linux-user/main.c
> > +++ b/linux-user/main.c
> > @@ -688,11 +688,29 @@ void cpu_loop(CPUARMState *env)
> >                  uint32_t opcode;
> >                  int rc;
> >
> > +                const uint32_t arm_bkpt_mask        = 0x0FFFFFFF;
> > +                const uint32_t arm_bkpt             = 0x07F001F0;
> > +                const uint32_t arm_bkpt_thumb_mask  = 0x0000FFFF;
> > +                const uint32_t arm_bkpt_thumb       = 0x0000DE01;
> > +                const uint32_t arm_bkpt_thumb2_mask = 0xFFFFFFFF;
> > +                const uint32_t arm_bkpt_thumb2      = 0xF7F0A000;
> > +
> >                  /* we handle the FPU emulation here, as Linux */
> >                  /* we get the opcode */
> >                  /* FIXME - what to do if get_user() fails? */
> >                  get_user_code_u32(opcode, env->regs[15],
> env->bswap_code);
> >
> > +                if (env->thumb) {
> > +                    if ((opcode & arm_bkpt_thumb_mask) == arm_bkpt_thumb
> > +                        || (opcode & arm_bkpt_thumb2_mask) ==
> arm_bkpt_thumb2) {
> > +                        goto excp_debug;
> > +                    }
> > +                } else {
> > +                    if ((opcode & arm_bkpt_mask) == arm_bkpt) {
> > +                        goto excp_debug;
> > +                    }
> > +                }
> > +
> >                  rc = EmulateAll(opcode, &ts->fpa, env);
> >                  if (rc == 0) { /* illegal instruction */
> >                      info.si_signo = SIGILL;
>
> This shouldn't be necessary, because our instruction decoder
> causes the BKPT instructions to generate an EXCP_BKPT
> (see target-arm/translate.c). So we should never go through
> this code path for these instructions...
>
> thanks
> -- PMM
>

[-- Attachment #2: Type: text/html, Size: 4500 bytes --]

  reply	other threads:[~2014-06-25 16:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-25  4:08 [Qemu-devel] [PATCH] linux-user: Handle new ARM breakpoint instruction Hunter Laux
2014-06-25  9:18 ` Peter Maydell
2014-06-25 16:11   ` Hunter Laux [this message]
2014-06-25 18:07     ` Peter Maydell

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=CAMQF8Mi53VzoLV5fO-zRnOaLbjCv07DPc4rY3JLzANQjJx0U4Q@mail.gmail.com \
    --to=hunterlaux@gmail.com \
    --cc=peter.maydell@linaro.org \
    --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.