Re: [PATCH 0/3] target/arm: Set FPSCR.LTPSIZE for user-mode

Hi Peter, Thanks for the prompt patches! On Tue, Sep 14, 2021 at 2:08 PM Peter Maydell wrote: > This patchset fixes https://gitlab.com/qemu-project/qemu/-/issues/613 > which is a bug where we weren't setting FPSCR.LTPSIZE correctly > out of reset for the user-mode emulator. The effect is that

[Bug 1883268] Re: random errors on aarch64 when executing __aarch64_cas8_acq_rel

Opened ticket on gitlab: https://gitlab.com/qemu- project/qemu/-/issues/333 ** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #333 https://gitlab.com/qemu-project/qemu/-/issues/333 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed

[Bug 1927530] Re: qemu-aarch64 MTE fails to report tag mismatch

*** This bug is a duplicate of bug 1921948 *** https://bugs.launchpad.net/bugs/1921948 ** Attachment added: "libgcc_s.so.1" https://bugs.launchpad.net/qemu/+bug/1927530/+attachment/5495299/+files/libgcc_s.so.1 -- You received this bug notification because you are a member of qemu-

[Bug 1927530] Re: qemu-aarch64 MTE fails to report tag mismatch

*** This bug is a duplicate of bug 1921948 *** https://bugs.launchpad.net/bugs/1921948 Sorry, I didn't think about rpath when I tried to execute what I had extracted. Here are the additional libstdc++.so.6 and libgcc_s.so.1. I am using a more recent qemu version than 6.0, almost head:

[Bug 1878348] Re: --static build fails in v5.0 (since 5010cec2bc87dafab39b3913c8ca91f88df9c540)

I have re-tested at commit d45a5270d075ea589f0b0ddcf963a5fea1f500ac, and the build succeeded, so it looks like the problem has been fixed. ** Changed in: qemu Status: Incomplete => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is

[Bug 1927530] [NEW] qemu-aarch64 MTE fails to report tag mismatch

Public bug reported: Hi, While running the GCC testsuite with qemu-6.0 as simulator, I noticed several errors in the hwasan testsuite (output pattern tests). I am attaching: bitfield-2.exe ld-linux-aarch64.so.1 libc.so.6 libdl.so.2 libhwasan.so.0 libm.so.6 libpthread.so.0 librt.so.1 The

[Bug 1883268] Re: random errors on aarch64 when executing __aarch64_cas8_acq_rel

Hi Richard, Thanks for taking a look and confirming that you managed to reproduce the problem. I forgot to mention that I'm using x86_64 hosts, not i686. I hope there are not two unrelated issues... -- You received this bug notification because you are a member of qemu- devel-ml, which is

[Bug 1883268] Re: random errors on aarch64 when executing __aarch64_cas8_acq_rel

** Attachment added: "QEMU traces" https://bugs.launchpad.net/qemu/+bug/1883268/+attachment/5383274/+files/sync-4.qemu.log.xz -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1883268 Title:

[Bug 1883268] [NEW] random errors on aarch64 when executing __aarch64_cas8_acq_rel

Public bug reported: Hello, Since I upgraded to qemu-5.0 when executing the GCC testsuite, I've noticed random failures of g++.dg/ext/sync-4.C. I'm attaching the source of the testcase, the binary executable and the qemu traces (huge, 111MB!) starting at main (with qemu-aarch64 -cpu cortex-a57

[Bug 1883268] Re: random errors on aarch64 when executing __aarch64_cas8_acq_rel

** Attachment added: "Binary" https://bugs.launchpad.net/qemu/+bug/1883268/+attachment/5383273/+files/sync-4.exe -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1883268 Title: random errors on

[Bug 1878348] Re: --static build fails in v5.0 (since 5010cec2bc87dafab39b3913c8ca91f88df9c540)

Maybe --static should be ignored for system emulators and accepted for user-mode emulators? That would enable to have a single build, otherwise if we want both, we'd need to configure & build QEMU twice. -- You received this bug notification because you are a member of qemu- devel-ml, which is

[Bug 1878348] Re: --static build fails in v5.0 (since 5010cec2bc87dafab39b3913c8ca91f88df9c540)

OK I wasn't aware that static linking was not supported by system emulators, thanks for the heads-up. I've updated our build scripts not to use static link, so you can close this PR unless you want to keep track that configure needs improvements. Thanks. -- You received this bug notification

[Bug 1878348] Re: --static build fails in v5.0 (since 5010cec2bc87dafab39b3913c8ca91f88df9c540)

Right, after a make distclean + configure, I managed to complete the build after installing libffi-dev libselinux1-dev. However, I think there's a bug in configure: it should either complain when these packages are missing, or disable the module that needs them. Without libffi-dev and

[Bug 1878348] [NEW] --static build fails in v5.0 (since 5010cec2bc87dafab39b3913c8ca91f88df9c540)

Public bug reported: Hi, Since commit 5010cec2bc87dafab39b3913c8ca91f88df9c540, building qemu fails when configured with --static (eg ../configure --target- list=x86_64-softmmu,x86_64-linux-user --enable-debug --static). On ubuntu 16.04, it fails to find -lffi and -lselinux. After I apt-get

Re: [PING] [PATCH 1/1] target/arm: Add support for cortex-m7 CPU

On Tue, 5 Nov 2019 at 21:23, Peter Maydell wrote: > > On Mon, 4 Nov 2019 at 16:41, Christophe Lyon > wrote: > > > > ping? > > This is on my list to review, but it's missed softfreeze so > as a new feature it will go into 5.0 once trunk reopens for > developmen

Re: [PING] [PATCH 1/1] target/arm: Add support for cortex-m7 CPU

ping? http://patchwork.ozlabs.org/patch/1183934/ On Fri, 25 Oct 2019 at 11:08, Christophe Lyon wrote: > > This is derived from cortex-m4 description, adding DP support and FPv5 > instructions with the corresponding flags in isar and mvfr2. > > Checked that it could succe

[Bug 1849879] [NEW] qemu-arm should accept vmrs apsr_nzcv, fpscr on M-profile

Public bug reported: I've noticed that qemu-arm for cortex-M considers vmrs apsr_nzcv, fpscr as an illegal instruction. In this case, rt==15 means APSR, and the instruction should be accepted and executed like for A-profile. I posted a small patch:

[PATCH 1/1] target/arm: Allow reading flags from FPSCR for M-profile

rt==15 is a special case when reading the flags: it means the destination is APSR. This patch avoids rejecting vmrs apsr_nzcv, fpscr as illegal instruction. Signed-off-by: Christophe Lyon --- target/arm/translate-vfp.inc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 1/1] target/arm: Add support for cortex-m7 CPU

This is derived from cortex-m4 description, adding DP support and FPv5 instructions with the corresponding flags in isar and mvfr2. Checked that it could successfully execute vrinta.f32 s15, s15 while cortex-m4 emulation rejects it with "illegal instruction". Signed-off-by: Chris

[Bug 1721275] Re: Support more ARM CPUs

Good news, I thought at least some of them were not implemented because for instance I couldn't find where VRINTA is handled (I noticed code for NEON_2RM_VRINTA, but I thought there should be something in vfp.decode for VRINT[ANPM]) -- You received this bug notification because you are a member

[Bug 1721275] Re: Support more ARM CPUs

It seemed "easy" to add cortex-m7 based on cortex-m4 (copy m4 description, update ID register values), but I realized that QEMU does not support FPv5 which not only supports DP, but also adds new instructions that QEMU does not handle yet (see section A2.5 of the ARMv7-M ARM). * Are there plans

[Qemu-devel] [Bug 1721275] Re: Support more ARM CPUs

How do I activate it since --cpu cortex-m7 isn't supported? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1721275 Title: Support more ARM CPUs Status in QEMU: Won't Fix Bug description: Hi,

[Qemu-devel] [Bug 1721275] Re: Support more ARM CPUs

Regarding Cortex-M7, I've noticed that unlike Cortex-M4, it supports double precision floating-point. Is DP supported by qemu? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1721275 Title: Support

[Qemu-devel] [Bug 1840922] Re: qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8

Thanks Peter and Richard for the quick patch. It works for me. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1840922 Title: qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8 Status

[Qemu-devel] [Bug 1840922] Re: qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8

** Attachment added: "qemu trace at -O2" https://bugs.launchpad.net/qemu/+bug/1840922/+attachment/5283732/+files/2822-1.trace.O2 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1840922 Title:

[Qemu-devel] [Bug 1840922] Re: qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8

** Attachment added: "qemu trace at -Os" https://bugs.launchpad.net/qemu/+bug/1840922/+attachment/5283731/+files/2822-1.trace.Os -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1840922 Title:

[Qemu-devel] [Bug 1840922] [NEW] qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8

Public bug reported: Hi, While experimenting with running the GCC testsuite with cortex-m33 as target (to exercise v8-m code), I came across this failure: qemu: unhandled CPU exception 0x8 - aborting R00=fffeaf58 R01=fffeaf58 R02= R03=fffeaf5d R04=fffeaf5c R05=fffeaf9c R06=

[Qemu-devel] [Bug 1840922] Re: qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8

** Attachment added: "executable at -O2" https://bugs.launchpad.net/qemu/+bug/1840922/+attachment/5283730/+files/2822-1.exe.O2 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1840922 Title:

[Qemu-devel] [Bug 1840922] Re: qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8

** Attachment added: "executable at -Os" https://bugs.launchpad.net/qemu/+bug/1840922/+attachment/5283729/+files/2822-1.exe.Os -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1840922 Title:

[Qemu-devel] [Bug 1840922] Re: qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8

** Attachment added: "asm at -O2" https://bugs.launchpad.net/qemu/+bug/1840922/+attachment/5283728/+files/2822-1.s.O2 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1840922 Title: qemu-arm

[Qemu-devel] [Bug 1840922] Re: qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8

** Attachment added: "asm at -Os" https://bugs.launchpad.net/qemu/+bug/1840922/+attachment/5283727/+files/2822-1.s.Os -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1840922 Title: qemu-arm

[Qemu-devel] [Bug 1834496] Re: Regressions on arm target with some GCC tests

I confirm this patch fixes the problem I reported. Thanks! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1834496 Title: Regressions on arm target with some GCC tests Status in QEMU: In Progress

[Qemu-devel] [Bug 1836078] Re: Regressions on arm-linux-gnueabihf target with some GCC tests

I confirm this patch fixes the problem I reported. Thanks! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1836078 Title: Regressions on arm-linux-gnueabihf target with some GCC tests Status in

[Qemu-devel] [Bug 1836192] Re: Regressions on arm926 target with some GCC tests

I confirm this patch fixes the problem I reported. Thanks! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1836192 Title: Regressions on arm926 target with some GCC tests Status in QEMU: In

Re: [Qemu-devel] [PATCH v2 for-4.1] target/arm: Set VFP-related MVFR0 fields for arm926 and arm1026

120827fa182f0e76 and 266bd25c485597c, > which accidentally disabled VFP short-vector support and > double-precision support on these CPUs. > > Reported-by: Christophe Lyon > Signed-off-by: Peter Maydell > Fixes: 1120827fa182f0e > Fixes: 266bd25c485597c > Fixes: https:/

[Qemu-devel] [Bug 1836192] [NEW] Regressions on arm926 target with some GCC tests

Public bug reported: Hi, After trying qemu master: commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde Merge: 68d7ff0 14f5d87 Author: Peter Maydell Date: Fri Jun 21 15:40:50 2019 +0100 even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496, I've noticed several regressions compared to

[Qemu-devel] [Bug 1836078] [NEW] Regressions on arm-linux-gnueabihf target with some GCC tests

Public bug reported: Hi, After trying qemu master: commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde Merge: 68d7ff0 14f5d87 Author: Peter Maydell Date: Fri Jun 21 15:40:50 2019 +0100 even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496, I've noticed several regressions compared to

Re: [Qemu-devel] [PATCH for-4.1] tcg: Fix constant folding of INDEX_op_extract2_i32

> > Signed-off-by: Richard Henderson > > Reviewed-by: Alex Bennée > Tested-by: Alex Bennée > Tested-by: Christophe Lyon Hi, I ran GCC validations with your fix, it does fix the problems I reported with the arm-none-linux-gnueabi target. Unfortunately, we are unlucky because there

[Qemu-devel] [Bug 1834496] [NEW] Regressions on arm target with some GCC tests

Public bug reported: Hi, After trying qemu master: commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde Merge: 68d7ff0 14f5d87 Author: Peter Maydell Date: Fri Jun 21 15:40:50 2019 +0100 I found several regressions compared to qemu-3.1 when running the GCC testsuite. I'm attaching a tarball

Re: [Qemu-devel] [PATCH] tcg: Fix mmap lock assert on translation failure

On Sun, 16 Jun 2019 at 23:05, Richard Henderson wrote: > > Check page flags before letting an invalid pc cause a SIGSEGV. > > Prepare for eventially validating PROT_EXEC. The current wrinkle being > that we have a problem with our implementation of signals. We should > be using a vdso like the

[Qemu-devel] [Bug 1832353] Re: cpu_exec: Assertion !have_mmap_lock() failed

It's fairly recent: qemu-arm version 4.0.50 (v4.0.0-1215-ga578cdf-dirty) Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers commit a578cdfbdd8f9beff5ced52b7826ddb1669abbbf Merge: 19735c8 43b3952 Author: Peter Maydell Date: Mon Jun 10 16:09:19 2019 +0100 Merge

[Qemu-devel] [Bug 1832353] [NEW] cpu_exec: Assertion !have_mmap_lock() failed

Public bug reported: Hi, I have isolated a testcase from the GCC testsuite (actually gfortran, test proc_ptr_51.f90) which produces tons of: qemu-arm: /home/christophe.lyon/src/qemu/accel/tcg/cpu-exec.c:701: cpu_exec: Assertion `!have_mmap_lock()' failed. including with master qemu as of

Re: [Qemu-devel] [Bug 1813305] [NEW] trace-root.h is not regerenerated after re-configure

On Tue, 29 Jan 2019 at 03:55, Stefan Hajnoczi wrote: > > On Fri, Jan 25, 2019 at 02:03:39PM -, Christophe Lyon wrote: > > I've just realized that after I reconfigured my qemu with > > ../configure > > --target-list=arm-softmmu,arm-linux-user,aarch64-softmmu,aarch64-

[Qemu-devel] [Bug 1813307] [NEW] util/path.c/follow_path() does not handle "/" well

Public bug reported: Hello, I noticed that qemu does not handle "/" very well in follow_path(). Specifically, I was trying to run gdbserver under qemu, and it failed inside its implementation of __getcwd. Indeed it does something like if (__lstat ("/", ) < 0) . and then loops from

[Qemu-devel] [Bug 1813305] [NEW] trace-root.h is not regerenerated after re-configure

Public bug reported: Hi, I've just realized that after I reconfigured my qemu with ../configure --target-list=arm-softmmu,arm-linux-user,aarch64-softmmu,aarch64-linux-user --enable-trace-backends=simple $ make did rebuild some stuff for the 'simple' trace, but it did not update trace-root.h

Re: [Qemu-devel] [ARM/FDPIC v4 0/4] FDPIC ABI for ARM

On 30 April 2018 at 14:03, Laurent Vivier wrote: > Le 30/04/2018 à 11:46, Peter Maydell a écrit : >> On 30 April 2018 at 10:28, Laurent Vivier wrote: >>> Le 30/04/2018 à 11:12, Peter Maydell a écrit : Great. Riku/Laurent -- I'm assuming you're going to

Re: [Qemu-devel] [ARM/FDPIC v4 0/4] FDPIC ABI for ARM

On 30 April 2018 at 10:59, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 30 April 2018 at 09:40, Christophe Lyon <christophe.l...@linaro.org> wrote: >> On 30 April 2018 at 10:11, Peter Maydell <peter.mayd...@linaro.org> wrote: >>> On 30 April 2018 at

Re: [Qemu-devel] [ARM/FDPIC v4 0/4] FDPIC ABI for ARM

On 30 April 2018 at 10:11, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 30 April 2018 at 09:03, Christophe Lyon <christophe.l...@st.com> wrote: >> Hello, >> >> This patch series implements the QEMU contribution of the FDPIC >> ABI for ARM targets.

[Qemu-devel] [ARM/FDPIC v4 3/4] linux-user: ARM-FDPIC: Add support of FDPIC for ARM.

Add FDPIC info into image_info structure since interpreter info is on stack and needs to be saved to be accessed later on. Co-Authored-By: Mickaël Guêné <mickael.gu...@st.com> Signed-off-by: Christophe Lyon <christophe.l...@st.com> diff --git a/linux-user/elfload.c b/linux-user/elf

[Qemu-devel] [ARM/FDPIC v4 4/4] linux-user: ARM-FDPIC: Add support for signals for FDPIC targets

-By: Mickaël Guêné <mickael.gu...@st.com> Signed-off-by: Christophe Lyon <christophe.l...@st.com> diff --git a/linux-user/signal.c b/linux-user/signal.c index 8d9e6e8..6dbc699 100644 --- a/linux-user/signal.c +++ b/linux-user/signal.c @@ -2045,13 +2045,13 @@ struct sigframe_v1 {

[Qemu-devel] [ARM/FDPIC v4 2/4] linux-user: ARM-FDPIC: Identify ARM FDPIC binaries

Define an ARM-specific version of elf_is_fdpic: FDPIC ELF objects are identified with e_ident[EI_OSABI] == ELFOSABI_ARM_FDPIC. Co-Authored-By: Mickaël Guêné <mickael.gu...@st.com> Signed-off-by: Christophe Lyon <christophe.l...@st.com> diff --git a/include/elf.h b/include/elf.h i

[Qemu-devel] [ARM/FDPIC v4 1/4] Remove CONFIG_USE_FDPIC.

would prevent QEMU from building precisely because elf_is_fdpic is not defined. Signed-off-by: Christophe Lyon <christophe.l...@st.com> diff --git a/linux-user/elfload.c b/linux-user/elfload.c index c77ed1b..bbe93b0 100644 --- a/linux-user/elfload.c +++ b/linux-user/elfload.c @@ -1681,7 +1

[Qemu-devel] [ARM/FDPIC v4 0/4] FDPIC ABI for ARM

ckael-guene/fdpic_manifest [3] https://github.com/mickael-guene/fdpic_doc/blob/master/abi.txt [4] https://git.linaro.org/people/christophe.lyon/gcc.git/log/?h=fdpic-upstream [5] https://git.linaro.org/people/christophe.lyon/uclibc.git/log/?h=uClibc-0.9.33.2-fdpic-upstream Christophe Lyon (

[Qemu-devel] [ARM/FDPIC v3 4/4] linux-user: ARM-FDPIC: Add support for signals for FDPIC targets

: setup_return() now returns an error if the FDPIC function description isn't readable. Callers of setup_return() are updated to force_sigsegv in such cases. Co-Authored-By: Mickaël Guêné <mickael.gu...@st.com> Signed-off-by: Christophe Lyon <christophe.l...@st.com> diff --git a/linux-use

[Qemu-devel] [ARM/FDPIC v3 3/4] linux-user: ARM-FDPIC: Add support of FDPIC for ARM.

.gu...@st.com> Signed-off-by: Christophe Lyon <christophe.l...@st.com> diff --git a/linux-user/elfload.c b/linux-user/elfload.c index 76d7718..fad3c42 100644 --- a/linux-user/elfload.c +++ b/linux-user/elfload.c @@ -78,6 +78,11 @@ enum { */ #define personality(pers) (pers &

Re: [Qemu-devel] [ARM/FDPIC v2 4/4] linux-user: ARM-FDPIC: Add support for signals for FDPIC targets

On 23/04/2018 15:05, Peter Maydell wrote: On 23 April 2018 at 08:51, Christophe Lyon <christophe.l...@st.com> wrote: The FDPIC restorer needs to deal with a function descriptor, hence we have to extend 'retcode' such that it can hold the instructions needed to perform this. The re

Re: [Qemu-devel] [ARM/FDPIC v2 3/4] linux-user: ARM-FDPIC: Add support of FDPIC for ARM.

On 23/04/2018 14:49, Peter Maydell wrote: On 23 April 2018 at 08:51, Christophe Lyon <christophe.l...@st.com> wrote: Add FDPIC info into image_info structure since interpreter info is on stack and needs to be saved to be accessed later on. Co-Authored-By: Mickaël Guêné <mickael.gu.

Re: [Qemu-devel] [ARM/FDPIC v2 2/4] linux-user: ARM-FDPIC: Identify ARM FDPIC binaries

On 23/04/2018 14:17, Peter Maydell wrote: On 23 April 2018 at 08:51, Christophe Lyon <christophe.l...@st.com> wrote: Define an ARM-specific version of elf_is_fdpic: FDPIC ELF objects are identified with e_ident[EI_OSABI] == ELFOSABI_ARM_FDPIC. Co-Authored-By: Mickaël Guêné <m

[Qemu-devel] [ARM/FDPIC v2 3/4] linux-user: ARM-FDPIC: Add support of FDPIC for ARM.

Add FDPIC info into image_info structure since interpreter info is on stack and needs to be saved to be accessed later on. Co-Authored-By: Mickaël Guêné <mickael.gu...@st.com> Signed-off-by: Christophe Lyon <christophe.l...@st.com> diff --git a/linux-user/elfload.c b/linux-user/elf

[Qemu-devel] [ARM/FDPIC v2 2/4] linux-user: ARM-FDPIC: Identify ARM FDPIC binaries

Define an ARM-specific version of elf_is_fdpic: FDPIC ELF objects are identified with e_ident[EI_OSABI] == ELFOSABI_ARM_FDPIC. Co-Authored-By: Mickaël Guêné <mickael.gu...@st.com> Signed-off-by: Christophe Lyon <christophe.l...@st.com> diff --git a/include/elf.h b/include/elf.h i

[Qemu-devel] [ARM/FDPIC v2 1/4] Remove CONFIG_USE_FDPIC.

would prevent QEMU from building precisely because elf_is_fdpic is not defined. Signed-off-by: Christophe Lyon <christophe.l...@st.com> diff --git a/linux-user/elfload.c b/linux-user/elfload.c index c77ed1b..bbe93b0 100644 --- a/linux-user/elfload.c +++ b/linux-user/elfload.c @@ -1681,7 +1

[Qemu-devel] [ARM/FDPIC v2 4/4] linux-user: ARM-FDPIC: Add support for signals for FDPIC targets

-By: Mickaël Guêné <mickael.gu...@st.com> Signed-off-by: Christophe Lyon <christophe.l...@st.com> diff --git a/linux-user/signal.c b/linux-user/signal.c index 8d9e6e8..d01b459 100644 --- a/linux-user/signal.c +++ b/linux-user/signal.c @@ -2045,13 +2045,13 @@ struct sigframe_v1 {

[Qemu-devel] [ARM/FDPIC v2 0/4] FDPIC ABI for ARM

to the previous patch #2, and uses TaskState instead of CPUARMState - patch #4 corresponds to the previous patch #3, and fixes guest pointer dereferencing Is this now OK? Thanks, Christophe Christophe Lyon (4): Remove CONFIG_USE_FDPIC. linux-user: ARM-FDPIC: Identify ARM FDPIC binaries

[Qemu-devel] [PATCH] linux-user: Add ARM get_tls syscall support

Co-Authored-By: Mickaël Guêné <mickael.gu...@st.com> Signed-off-by: Christophe Lyon <christophe.l...@st.com> diff --git a/linux-user/arm/target_syscall.h b/linux-user/arm/target_syscall.h index 94e2a42..afc0772 100644 --- a/linux-user/arm/target_syscall.h +++ b/linux-user/arm/targ

Re: [Qemu-devel] [ARM/FDPIC 0/4] FDPIC ABI for ARM

On 13/04/2018 17:18, Peter Maydell wrote: On 6 April 2018 at 16:17, Christophe Lyon <christophe.l...@st.com> wrote: Hello, This patch series implements the QEMU contribution of the FDPIC ABI for ARM targets. I am currently working on updating the patches for the other toolchain comp

Re: [Qemu-devel] [ARM/FDPIC 2/4] linux-user: ARM-FDPIC: Add support of FDPIC for ARM.

On 13/04/2018 17:07, Peter Maydell wrote: On 6 April 2018 at 16:17, Christophe Lyon <christophe.l...@st.com> wrote: Add FDPIC info into image_info structure since interpreter info is on stack and needs to be saved to be accessed later on. Co-Authored-By: Mickaël Guêné <mickael.gu.

Re: [Qemu-devel] [ARM/FDPIC 1/4] linux-user: ARM-FDPIC: Add configure option to support loading of FDPIC binaries

On 13/04/2018 17:04, Peter Maydell wrote: On 6 April 2018 at 16:17, Christophe Lyon <christophe.l...@st.com> wrote: Adds --enable-fdpic and --disable-fdpic configure options. This feature is disabled by default, that's why it is not described in the "Optional features" hel

Re: [Qemu-devel] [ARM/FDPIC 4/4] linux-user: ARM-FDPIC: Add arm get tls syscall support

On 13/04/2018 17:03, Peter Maydell wrote: On 6 April 2018 at 16:17, Christophe Lyon <christophe.l...@st.com> wrote: Co-Authored-By: Mickaël Guêné <mickael.gu...@st.com> Signed-off-by: Christophe Lyon <christophe.l...@st.com> diff --git a/linux-user/arm/target_syscall.

[Qemu-devel] [Bug 1761401] Re: ARM/Neon: vcvt rounding error

I updated my QEMU git tree such that it includes commit bd49e6027cbc207c, and the test now passes. Thanks for the prompt fix! ** Changed in: qemu Status: New => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [ARM/FDPIC 4/4] linux-user: ARM-FDPIC: Add arm get tls syscall support

Co-Authored-By: Mickaël Guêné <mickael.gu...@st.com> Signed-off-by: Christophe Lyon <christophe.l...@st.com> diff --git a/linux-user/arm/target_syscall.h b/linux-user/arm/target_syscall.h index 94e2a42..afc0772 100644 --- a/linux-user/arm/target_syscall.h +++ b/linux-user/arm/targ

[Qemu-devel] [ARM/FDPIC 0/4] FDPIC ABI for ARM

kael-guene/fdpic_doc/blob/master/abi.txt [4] https://git.linaro.org/people/christophe.lyon/gcc.git/log/?h=fdpic-upstream [5] https://git.linaro.org/people/christophe.lyon/uclibc.git/log/?h=uClibc-0.9.33.2-fdpic-upstream Christophe Lyon (4): linux-user: ARM-FDPIC: Add configure option to support

[Qemu-devel] [ARM/FDPIC 2/4] linux-user: ARM-FDPIC: Add support of FDPIC for ARM.

Add FDPIC info into image_info structure since interpreter info is on stack and needs to be saved to be accessed later on. Co-Authored-By: Mickaël Guêné <mickael.gu...@st.com> Signed-off-by: Christophe Lyon <christophe.l...@st.com> diff --git a/linux-user/elfload.c b/linux-user/elf

[Qemu-devel] [ARM/FDPIC 3/4] linux-user: ARM-FDPIC: Add support for signals for FDPIC targets

-By: Mickaël Guêné <mickael.gu...@st.com> Signed-off-by: Christophe Lyon <christophe.l...@st.com> diff --git a/linux-user/signal.c b/linux-user/signal.c index 2ea3e03..75643d7 100644 --- a/linux-user/signal.c +++ b/linux-user/signal.c @@ -2039,13 +2039,13 @@ struct sigframe_v1 {

[Qemu-devel] [ARM/FDPIC 1/4] linux-user: ARM-FDPIC: Add configure option to support loading of FDPIC binaries

FDPIC. Co-Authored-By: Mickaël Guêné <mickael.gu...@st.com> Signed-off-by: Christophe Lyon <christophe.l...@st.com> diff --git a/configure b/configure index 4d0e92c..af4c14b 100755 --- a/configure +++ b/configure @@ -451,6 +451,7 @@ jemalloc="no" replication=&

[Qemu-devel] [Bug 1761401] [NEW] ARM/Neon: vcvt rounding error

Public bug reported: Hello, While using QEMU commit 47d3b60858d90ac8a0cc3a72af7f95c96781125a (March 28, 2018), I've noticed failures in one of the GCC ARM/Neon tests. The test passes on hardware, and with QEMU-2.11.0, so it looks like a recent regression. The test builds a vector of 4 float32

[Qemu-devel] [Bug 1738767] Re: Cannot build QEMU on RHEL6 because of MAP_HUGETLB

I think we can close this bug: the build fails on RHEL6.4, but succeeded on RHEL6.7. Probably related to: https://access.redhat.com/solutions/320613 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1738767] [NEW] Cannot build QEMU on RHEL6 because of MAP_HUGETLB

Public bug reported: Hello, I've just downloaded qemu-2.11.0 sources and I wanted to build QEMU on RHEL6 x86_64, for various targets, amonst which arm-linux-user. The build fails because /usr/include/bits/mman.h does not define MAP_HUGETLB. I think it is needed since commit 541e16904. I'm not

[Qemu-devel] [Bug 1727737] Re: qemu-arm stalls on a GCC sanitizer test since qemu-2.7

Ha! I think I found the problem the sanitizer reads /proc/self/environ, which is not where QEMU wrote the target environment... Thanks a lot for your support, I think you can close this report as: "it's a feature, not a bug". -- You received this bug notification because you are a member of

[Qemu-devel] [Bug 1727737] Re: qemu-arm stalls on a GCC sanitizer test since qemu-2.7

Thanks fixing my ignorance :-) So it really seems this is a feature, not a bug here. This was a bit off-topic, but I have a pending question in comment #5: As a side note, doing $ qemu-arm -E ASAN_OPTIONS=detect_leaks=0 blah does not affect the execution, while $ env ASAN_OPTIONS=detect_leaks=0

[Qemu-devel] [Bug 1727737] Re: qemu-arm stalls on a GCC sanitizer test since qemu-2.7

Thanks for the clarification. But how does the target get the actual syscall return code, if do_syscall() is supposed to return negative-target-errno? I mean, in general the target code will check if the syscall returned -1, and only then query errno? But if QEMU's do_syscall returns -errno,

[Qemu-devel] [Bug 1727737] Re: qemu-arm stalls on a GCC sanitizer test since qemu-2.7

I also looked at QEMU's code, and I am suprised that do_syscall() returns the value of errno rather than the return code from the syscall. So for instance, if clone() fails, do_syscall() returns get_errno(do_fork(...)) instead of -1. I thought the target code expects -1 in case of failure, but I'm

[Qemu-devel] [Bug 1727737] Re: qemu-arm stalls on a GCC sanitizer test since qemu-2.7

I looked a bit more at the sanitizers source code, to understand the differences between arm and aarch64. And it turns out that on aarch64, we have: sanitizer_common/sanitizer_syscall_linux_aarch64.inc: 133 // Helper function used to avoid cobbler errno. 134 bool internal_iserror(uptr

[Qemu-devel] [Bug 1727737] Re: qemu-arm stalls on a GCC sanitizer test since qemu-2.7

My bad: on aarch64 it does not "work", the test actually exits with a LeakSanitizer error message ("fatal error"). Using QEMU_STRACE=1 shows that clone() fails in the same way as for arm (which is expected), but apparently this error is handled better on aarch64, maybe because the internal_clone

[Qemu-devel] [Bug 1725267] Re: armeb regression since qemu version 2.8

Great, thanks! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1725267 Title: armeb regression since qemu version 2.8 Status in QEMU: Fix Committed Bug description: Hi, I have noticed a

[Qemu-devel] [Bug 1727737] Re: qemu-arm stalls on a GCC sanitizer test since qemu-2.7

I suspect this happens when the sanitizer library calls StopTheWorld() (in libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc in GCC sources). It does: uptr tracer_pid = internal_clone( TracerThread, tracer_stack.Bottom(), CLONE_VM | CLONE_FS | CLONE_FILES |

[Qemu-devel] [Bug 1727737] Re: qemu-arm stalls on a GCC sanitizer test since qemu-2.7

Right, it worked for me because of the encoded rpath. Here is the missing libstdc++.so.6 ** Attachment added: "libstdc++.so.6.xz" https://bugs.launchpad.net/qemu/+bug/1727737/+attachment/5004701/+files/libstdc++.so.6.xz -- You received this bug notification because you are a member of

[Qemu-devel] [Bug 1727737] [NEW] qemu-arm stalls on a GCC sanitizer test since qemu-2.7

Public bug reported: Hi, I have noticed that several GCC/sanitizer tests fail with timeout when executed under QEMU. After a bit of investigation, I have noticed that this worked with qemu-2.7, and started failing with qemu-2.8, and still fails with qemu-2.10.1 I'm attaching a tarball

[Qemu-devel] [Bug 1727737] Re: qemu-arm stalls on a GCC sanitizer test since qemu-2.7

** Attachment added: "tarball with testcase and libs" https://bugs.launchpad.net/qemu/+bug/1727737/+attachment/4996620/+files/qemu-bug-gcc-sanitizers.tar.xz -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1725267] Re: armeb regression since qemu version 2.8

I added printfs after each 'count++' statement, and here is what I got: qemu-2.7: ATOMIC_RELAXED OK ATOMIC_ACQUIRE OK ATOMIC_RELEASE OK ATOMIC_ACQ_REL OK ATOMIC_SEQ_CST OK ATOMIC_RELAXED OK ATOMIC_ACQUIRE OK ATOMIC_RELEASE OK ATOMIC_ACQ_REL OK ATOMIC_SEQ_CST OK ALL TESTS PASSED qemu-2.10.1:

[Qemu-devel] [Bug 1725267] Re: armeb regression since qemu version 2.8

** Attachment added: "instrumented executable" https://bugs.launchpad.net/qemu/+bug/1725267/+attachment/4979332/+files/atomic-exchange-4.exe -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1725267

[Qemu-devel] [Bug 1725267] Re: armeb regression since qemu version 2.8

** Attachment added: "instrumented source testcase" https://bugs.launchpad.net/qemu/+bug/1725267/+attachment/4979333/+files/atomic-exchange-4.c -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1725267] Re: armeb regression since qemu version 2.8

Indeed I wish GCC tests printed information rather than just calling abort()... I'll add some printfs and see what this says. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1725267 Title: armeb

[Qemu-devel] [Bug 1725267] [NEW] armeb regression since qemu version 2.8

Public bug reported: Hi, I have noticed a regression when I upgraded from qemu-armeb 2.7 to 2.8, and the problem is still present with version 2.10.1. I am using qemu for GCC validation, noticed problems with testcases involving atomics, I'm attaching here atomic-exchange-4.exe. # with 2.7: $

[Qemu-devel] [Bug 1725267] Re: armeb regression since qemu version 2.8

** Attachment added: "execution trace with qemu-2.10.1" https://bugs.launchpad.net/qemu/+bug/1725267/+attachment/4978669/+files/trace.2.10.1 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1725267

[Qemu-devel] [Bug 1725267] Re: armeb regression since qemu version 2.8

** Attachment added: "execution trace with qemu-2.7" https://bugs.launchpad.net/qemu/+bug/1725267/+attachment/4978668/+files/trace.2.7 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1725267

[Qemu-devel] [Bug 1724485] Re: Invalid assertion in arm_read_memory_func

The tarball contains: scoped1.exe etc/ld.so.cache lib/libm.so.6 lib/libstdc++.so.6 lib/lib.c.so.6 lib/ld-linux-armhf.so.3 lib/libgcc_s.so.1 I can reproduce the problem with qemu-2.10.1: qemu-armeb -E LD_LIBRARY_PATH=$PWD/lib -cpu any -R 0 -d in_asm -L $PWD $PWD/scoped1.exe Removing '-d in_asm'

[Qemu-devel] [Bug 1724485] [NEW] Invalid assertion in arm_read_memory_func

Public bug reported: Hi, I think there is an invalid assertion in arm_read_memory_func: assert(info->endian == BFD_ENDIAN_LITTLE) I face it in the following use case: target armeb-linux (I use qemu user mode), -d in_asm -cpu any. At some point during program startup, glibc's _dl_new_object

[Qemu-devel] [Bug 1721275] Re: Support more ARM CPUs

Thanks for PS, I thought QEMU was stricter than that. Regarding M7 vs M$ or A35 vs A53/A57, even though there's no functional difference, it would be convenient in Makefiles to have CPU=cortex-a53, and use $(CPU) to expand GCC and QEMU options, without having to guess which CPU I should use for

[Qemu-devel] [Bug 1721275] [NEW] Support more ARM CPUs

Public bug reported: Hi, This is an enhancement request, rather than a bug report. After some discussions/presentations during the last Linaro Connect (SFO17), I understand that it may be easy to add support for more ARM CPUs in QEMU. I am interested in user-mode, if that matters. I'm

[Qemu-devel] [Bug 1590336] Re: qemu-arm does not reject vrintz on non-v8 cpu

I confirm your patch does fix the problem. You may still want to fix the disassembler such that it dumps the right instruction, but that would be a separate fix. Thanks for your quick support. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed

  1   2   >