[Bug 1873898] [NEW] arm linux-user: bkpt insn doesn't cause SIGTRAP

* [Bug 1873898] [NEW] arm linux-user: bkpt insn doesn't cause SIGTRAP
@ 2020-04-20 16:00 Peter Maydell
  2020-04-20 16:45 ` [Bug 1873898] " Peter Maydell
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Peter Maydell @ 2020-04-20 16:00 UTC (permalink / raw)
  To: qemu-devel

Public bug reported:

QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT
insns into SIGTRAP signals. Test case:

===begin bkpt.c===
/* test bkpt insn */

#include <stdlib.h>
#include <stdio.h>

int main(void)
{
    printf("breakpoint\n");
#ifdef __aarch64__
    __asm__ volatile("brk 0x42\n");
#else
    __asm__ volatile("bkpt 0x42\n");
#endif
    printf("done\n");
    return 0;
}
===endit===

Compile with
$ arm-linux-gnueabihf-gcc -g -Wall -o bkpt-aa32 bkpt.c
$ aarch64-linux-gnu-gcc -g -Wall -o bkpt-aa64 bkpt.c

Contrast aarch64 which delivers the SIGTRAP and arm which doesn't:

$ qemu-aarch64 bkpt-aa64
breakpoint
qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped
Trace/breakpoint trap (core dumped)
$ qemu-arm bkpt-aa32
breakpoint
done

This is because in linux-user/arm/cpu-loop.c we incorrectly treat
EXCP_BKPT similarly to EXCP_SWI, which means that we actually perform a
syscall (which one depends on what happens to be in r7...). This code
has been like this (more or less) since commit 06c949e62a098f in 2006
which added BKPT in the first place. This is probably because at the
time the same code path was used to handle both Linux syscalls and
semihosting calls, and (on M profile) BKPT does imply a semihosting
call. But these days we've moved handling of semihosting out to an
entirely different codepath, so we can fix this bug by simply removing
this handling of EXCP_BKPT and instead making it deliver a SIGTRAP like
EXCP_DEBUG (as we do already on aarch64).

** Affects: qemu
     Importance: Undecided
         Status: New

** Tags: arm linux-user

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1873898

Title:
  arm linux-user: bkpt insn doesn't cause SIGTRAP

Status in QEMU:
  New

Bug description:
  QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT
  insns into SIGTRAP signals. Test case:

  ===begin bkpt.c===
  /* test bkpt insn */

  #include <stdlib.h>
  #include <stdio.h>

  int main(void)
  {
      printf("breakpoint\n");
  #ifdef __aarch64__
      __asm__ volatile("brk 0x42\n");
  #else
      __asm__ volatile("bkpt 0x42\n");
  #endif
      printf("done\n");
      return 0;
  }
  ===endit===

  Compile with
  $ arm-linux-gnueabihf-gcc -g -Wall -o bkpt-aa32 bkpt.c
  $ aarch64-linux-gnu-gcc -g -Wall -o bkpt-aa64 bkpt.c

  Contrast aarch64 which delivers the SIGTRAP and arm which doesn't:

  $ qemu-aarch64 bkpt-aa64
  breakpoint
  qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped
  Trace/breakpoint trap (core dumped)
  $ qemu-arm bkpt-aa32
  breakpoint
  done

  This is because in linux-user/arm/cpu-loop.c we incorrectly treat
  EXCP_BKPT similarly to EXCP_SWI, which means that we actually perform
  a syscall (which one depends on what happens to be in r7...). This
  code has been like this (more or less) since commit 06c949e62a098f in
  2006 which added BKPT in the first place. This is probably because at
  the time the same code path was used to handle both Linux syscalls and
  semihosting calls, and (on M profile) BKPT does imply a semihosting
  call. But these days we've moved handling of semihosting out to an
  entirely different codepath, so we can fix this bug by simply removing
  this handling of EXCP_BKPT and instead making it deliver a SIGTRAP
  like EXCP_DEBUG (as we do already on aarch64).

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1873898/+subscriptions

^ permalink raw reply	[flat|nested] 4+ messages in thread