qemu-user issue

41 views
Skip to first unread message

Roger Ferrer Ibanez

unread,
Oct 25, 2019, 1:43:54 PM10/25/19
to sw-...@groups.riscv.org, Ferran Pallarès

Hi all,

we are using the ucontext_t from a signal handler in a program being run under qemu-user.

We have found that there seems to be a discrepancy between the context structure of the glibc and the one in qemu-user.

My understanding is that the one used by the glibc

The one used by qemu-user under riscv is here

qemu’s structure struct target_sigcontext should, at least, be aligned to 16 because this is what ends happening to the glibc’s union __riscv_mc_fp_state (because of the __f array in struct __riscv_mc_q_ext_state).

Also we believe one of the fields is in the wrong order and there should be a padding field, mimicking what the glibc does.

In the time being, the patch below in qemu fixes this issue for us (we can now access the context correctly).

We are not sure, however, whether this is a bug in qemu-user or we’re actually seeing some other problem elsewhere. Can anyone confirm?

Thanks!

-struct target_sigcontext {
+struct __attribute__((aligned(16))) target_sigcontext {
     abi_long pc;
     abi_long gpr[31]; /* x0 is not present, so all offsets must be -1 */
     uint64_t fpr[32];
     uint32_t fcsr;
 }; /* cf. riscv-linux:arch/riscv/include/uapi/asm/ptrace.h */

 struct target_ucontext {
     unsigned long uc_flags;
     struct target_ucontext *uc_link;
     target_stack_t uc_stack;
-    struct target_sigcontext uc_mcontext;
     target_sigset_t uc_sigmask;
+    uint8_t __unused[1024 / 8 - sizeof(target_sigset_t)];
+    struct target_sigcontext uc_mcontext;
 };
​
-- 
Roger Ferrer Ibáñez - roger....@bsc.es
Barcelona Supercomputing Center - Centro Nacional de Supercomputación


WARNING / LEGAL TEXT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received.

http://www.bsc.es/disclaimer

Kito Cheng

unread,
Oct 25, 2019, 2:24:20 PM10/25/19
to Roger Ferrer Ibanez, Palmer Dabbelt, Chih-Min Chao, RISC-V SW Dev (sw-dev@groups.riscv.org), Ferran Pallarès
Add qemu related guys to CC.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/df82702e-4f4d-734d-6fc5-3bc5599157d0%40bsc.es.

Jim Wilson

unread,
Oct 25, 2019, 2:31:02 PM10/25/19
to Kito Cheng, Roger Ferrer Ibanez, Palmer Dabbelt, Chih-Min Chao, RISC-V SW Dev (sw-dev@groups.riscv.org), Ferran Pallarès
On Fri, Oct 25, 2019 at 11:24 AM Kito Cheng <kito....@gmail.com> wrote:
> On Sat, Oct 26, 2019 at 1:43 AM Roger Ferrer Ibanez <roger....@bsc.es> wrote:
>> we are using the ucontext_t from a signal handler in a program being run under qemu-user.
>> We have found that there seems to be a discrepancy between the context structure of the glibc and the one in qemu-user.

This is certainly possible. There are some signal related gcc
testsuite testcases that work on hardware but not under qemu-user. I
suspect problems with qemu-user. ucontext_t has changed at least once
when the RISC-V linux kernel and glibc ports were upstreamed, and
possibly more than once. I know that Michael Clark tried to fix a
related issue in riscv/riscv-qemu once, but Andreas Schwab pointed out
that it broke rv32 support, so I think that patch never went upstream.
This is one of the many problems I haven't had time to try to fix yet.
We really need more people volunteering to fix stuff like this.

See for instance
https://github.com/riscv/riscv-gnu-toolchain/blob/master/test/whitelist/gcc/glibc.log
they were marked as siginfo_t but I think it is really ucontext_t.

Jim
Reply all
Reply to author
Forward
0 new messages