offset 0x24 for
the here applicable ELFCLASS32).
See-also: ace3d65459
Signed-off-by: Andreas K. Hüttel
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: WANG Xuerui
Cc: Laurent Vivier
Cc: WANG Xuerui
Cc: Richard Henderson
Cc: Alex Bennee
Cc: Philippe Mathieu-Daudé
Closes: https://gitlab.com/qemu
0x0, 0x0, 0x0, 0x0,
| },
| .e_type = 2 , /* (ET_EXEC) */
| .e_machine = 8 , /* (EM_MIPS) */
| .e_version = 1 , /* (EV_CURRENT) */
| (...)
Signed-off-by: Andreas K. Hüttel
---
scripts/qemu-binfmt-conf.sh | 4 ++--
1 file changed, 2 insertions(+)
This information is given by the EF_MIPS_ABI2 (0x20) bit in the
e_flags field of the ELF header (a 4-byte value at offset 0x24 for
the here applicable ELFCLASS32).
See-also: https://www.mail-archive.com/qemu-devel@nongnu.org/msg732572.html
Signed-off-by: Andreas K. Hüttel
---
scripts/qemu
Re-sending v3 unchanged as requested.
The first patch has already been submitted earlier and is unchanged from v2.
The second patch extends it and resolves issue 843, "duplicate magic mips
patterns".
Tested with various self-bootstrapped Gentoo chroots and in production on
the Gentoo release eng
This information is given by the EF_MIPS_ABI2 (0x20) bit in the
e_flags field of the ELF header (a 4-byte value at offset 0x24 for
the here applicable ELFCLASS32).
See-also: https://www.mail-archive.com/qemu-devel@nongnu.org/msg732572.html
Signed-off-by: Andreas K. Hüttel
---
scripts/qemu
0x0, 0x0, 0x0, 0x0,
| },
| .e_type = 2 , /* (ET_EXEC) */
| .e_machine = 8 , /* (EM_MIPS) */
| .e_version = 1 , /* (EV_CURRENT) */
| (...)
Signed-off-by: Andreas K. Hüttel
---
scripts/qemu-binfmt-conf.sh | 4 ++--
1 file changed, 2 insertions(+)
Two patches; the first one has been under review before, the second builds
on it and extends the binfmt-misc magic to differentiate between o32 and
n32 binaries (see also issue 843).
0x0, 0x0, 0x0, 0x0,
| },
| .e_type = 2 , /* (ET_EXEC) */
| .e_machine = 8 , /* (EM_MIPS) */
| .e_version = 1 , /* (EV_CURRENT) */
| (...)
Signed-off-by: Andreas K. Hüttel
---
v2: Add the same fix for little endian as for big endian
scripts/qemu
= 2 , /* (ET_EXEC) */
| .e_machine = 8 , /* (EM_MIPS) */
| .e_version = 1 , /* (EV_CURRENT) */
| (...)
Signed-off-by: Andreas K. Hüttel
---
scripts/qemu-binfmt-conf.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/qemu-b
Am Mittwoch, 20. Januar 2021, 22:12:30 EET schrieb Andreas K. Hüttel:
> > This patch just passes the waitid status directly back to the guest.
>
> This works at least as well as the previous versions, so ++ from me.
>
> Will do more testing over the next days to see if it maybe
>
> This patch just passes the waitid status directly back to the guest.
>
This works at least as well as the previous versions, so ++ from me.
Will do more testing over the next days to see if it maybe also improves the
additional oddities I observed.
Tested-by: Andreas
Done (took a while to figure out how...)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1906193
Title:
riscv32 user mode emulation: fork return values broken
Status in QEMU:
Confirmed
Bug descri
ttps://bugs.launchpad.net/qemu/+bug/1906193
> Signed-off-by: Alistair Francis
Tested-by: Andreas K. Hüttel
> ---
> linux-user/signal.c | 26 --
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/linux-user/signal.c b/linux-user/signal.
I'm still seeing this with qemu 5.2.0
armv7a-softfp-linux-gnueabi-gcc -O2 -pipe -march=armv7-a -mfpu=vfpv3-d16
-mfloat-abi=softfp -Wl,-O1 -Wl,--as-needed glibc-test.c -o glibc-test
Allocating guest commpage: Operation not permitted
--
You received this bug notification because you are a me
Just as a general remark, while this specific problem seems to be
solved, there may still be issues surrounding waitid().
(With this patch applied, in a rather complex environment I see bash
processes hanging in an infinite loop, with waitid involved. I am
working on isolating the problem and prov
After applying this patch on top of qemu-5.2.0, I can confirm that it
fixes the problem.
Thank you!!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1906193
Title:
riscv32 user mode emulation: fork
Thanks a lot! Will test and post the result on monday when I'm back
home.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1906193
Title:
riscv32 user mode emulation: fork return values broken
Status
Here's qemu's own strace log:
farino ~ # /usr/bin/qemu-riscv32 -strace /chroot/riscv-ilp32/tmp/wait-test-short
10123 brk(NULL) = 0x00073000
10123 brk(0x00073880) = 0x00073880
10123 uname(0x407ffed8) = 0
10123 readlinkat(AT_FDCWD,"/proc/self/exe",0x407feff0,4096) = 39
10123 brk(0x00094880) = 0x0009
Here's the (abbreviated) output of strace'ing qemu:
farino ~ # strace -f /usr/bin/qemu-riscv32
/chroot/riscv-ilp32/tmp/wait-test-short
execve("/usr/bin/qemu-riscv32", ["/usr/bin/qemu-riscv32",
"/chroot/riscv-ilp32/tmp/wait-tes"...], 0x7ffd95fb1330 /* 40 vars */) = 0
[...]
[pid 16569] uname({sy
I can confirm that the same binary works fine with qemu system
emulation:
(riscv-ilp32 qemu) (none) /tmp # ./wait-test-short
(riscv-ilp32 qemu) (none) /tmp #
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net
This is the (statically linked) binary resulting from the source; with
it the problem can be demonstrated "standalone", without any other rv32
libraries or a complete chroot, just running the binary with qemu-
riscv32.
Generated with
(riscv-ilp32 chroot) farino /tmp # gcc -static -o wait-test-sho
Am Donnerstag, 17. September 2020, 00:05:10 EEST schrieb Alistair Francis:
> On Wed, Sep 16, 2020 at 2:09 PM Andreas K. Hüttel
wrote:
> > > My guess is that somewhere in QEMU the types don't match what RV32 is
> > > using. It's probably worth printing out the siz
ight be
> all sorts of issues with it unfortunately.
Would you consider qemu system mode more reliable?
I need to prepare some bootable riscv gentoo images eventually anyway. Might
as well try a riscv32 one for comparison then if that is more promising.
--
Andreas K. Hüttel
dilfri...@gentoo.o
("child wants to return %i (0x%X), parent received %i (0x%X),
difference %i\n",z,z,r,r,r-z);
}
}
}
}
===
Am Montag, 14. September 2020, 11:14:16 EEST schrieb Andreas K. Hüttel:
> Hi,
>
> first of all, sorry for crossposting, but I'm dealing with
ug-bash/2020-09/msg00033.html
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, qa, toolchain, base-system, perl, libreoffice)
signature.asc
Description: This is a digitally signed message part.
25 matches
Mail list logo
