[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug 1858461] Re: Please refactor linux-user/mips/cpu_loop.c

From: Aleksandar Markovic
Subject: [Bug 1858461] Re: Please refactor linux-user/mips/cpu_loop.c
Date: Wed, 08 Jan 2020 16:32:17 -0000


Please take a look at the patch:


Once you apply the patch, it should be straightforward to add
getdents64_x32() (right after clone3()) for all MIPS ABIs.

The thing is, kernel folks recently made some rearrangements of syscall
numbers, so that all architectures have in future "similar" syscall
numbers, but that required some "holes" in syscall numbers schemes for
virtuall all archs, and for MIPS among them. That is why ne array in
linux-user/mips/cpu_loop.c has some elements defined just as "0" - they
are there just to adjust syscall numbers to be in accordance with the
new scheme.

Please let us know if you are able to work with such solution or not.

Happy New Year!


You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

  Please refactor linux-user/mips/cpu_loop.c

Status in QEMU:

Bug description:
  Hello. I am working with qemu on test images. I've added a new syscall
  (436) to qemu but received ENOSYS from mips application.

  Please open "linux-user/mips/cpu_loop.c". I've added at the end of
  "mips_syscall_args" the following:

  MIPS_SYS(sys_getdents64_x32, 3)


  syscall_num = env->active_tc.gpr[2] - 4000;
  if (syscall_num >= sizeof(mips_syscall_args)) {
    ret = -TARGET_ENOSYS;

  returns -TARGET_ENOSYS

  We can see that "linux-user/mips/cpu_loop.c" differs a lot from
  "linux-user/arm/cpu_loop.c". Arm has it's own "ARM_NR_BASE" and etc.

  Can you please refactor mips cpu loop in the same way as arm? Thank

To manage notifications about this bug go to:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]