On 14.11.2010 18:50, Peter Maydell wrote:
Although newlib/libgloss use different modes for opening stdout
and stderr, the ARM C library implementation does not, for
instance; so your patch is relying on a detail of implementation of
a particular semihosting user. So I don't think we can apply
Fix garbage collection of temporaries in Neon emulation.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
target-arm/translate.c | 22 +-
1 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/target-arm/translate.c b/target-arm/translate.c
index 57664bc
On 18.01.2011 16:26, Peter Maydell wrote:
On 18 January 2011 14:34, Christophe Lyon christophe.l...@st.com wrote:
+
+/* gen_helper_neon_mull_[su]{8|16} do not free their parameters.
+ Don't forget to clean them now. */
+switch ((size 1) | u) {
+case 0:
+case 1
On 18.01.2011 16:36, Peter Maydell wrote:
Incidentally there are some correctness fixes for the multiply-by-scalar
neon insns from the qemu-meego tree which are on my list to push
upstream. So you probably aren't getting the right results even if
you've managed to shut up qemu's warnings :-)
Here is an updated patch which will hopefully not be mangled by my mailer.
Fix garbage collection of temporaries in Neon emulation.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
target-arm/translate.c | 18 +-
1 files changed, 13 insertions(+), 5 deletions
This patch fixes corner-case saturations, when the target range is
zero. It merely removes the guard against (sh == 0), and makes:
__ssat(0x87654321, 1) return 0x and set the saturation flag
__usat(0x87654321, 0) return 0 and set the saturation flag
Signed-off-by: Christophe Lyon
On 19.01.2011 17:51, Peter Maydell wrote:
On 19 January 2011 16:10, Christophe Lyon christophe.l...@st.com wrote:
This patch fixes corner-case saturations, when the target range is
zero. It merely removes the guard against (sh == 0), and makes:
__ssat(0x87654321, 1) return 0x and set
On 19.01.2011 20:29, Peter Maydell wrote:
Fix the register and part of register we get the scalar from in
the various multiply vector by scalar ops (VMUL by scalar
and friends).
I do confirm that with this patch, I can see many improvements in my tests.
Thanks.
emulation.
OK, so here is the same patch with an updated description:
target-arm: Fix garbage collection of temporaries in Neon emulation of
MULL and friends (VMLAL, VQDMLAL, VMLSL, VQDMLSL, VMULL, VQDMULL) as
well as (VSHRN, VRSHRN, VQSHRN, VQRSHRN).
Signed-off-by: Christophe Lyon christophe.l
and adds the 64 bits case.
Signed-off-by: Christophe Lyon christophe.l...@st.com
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/helpers.h | 12 --
target-arm/neon_helper.c | 89 ++
target-arm/op_helper.c | 49
Hi all,
I have developed some tests for ARM-Neon in the form of C sources files calling
ARM Neon intrinsics, and comparing the results of the resulting program with a
known reference (eg execution on actual CPU) shows if the execution engine is
follows the spec.
These tests currently
How about you make it available somewhere (tarball via http, git
repository on gitorious, or other method of your choice) for the
moment? Then we can take a look at it and proceed from there.
I agree, this is a good first step. If possible, its good if you
can publish source and binaries
is the official emacs configuration to get the right qemu style?
You can check for this sort of thing by running scripts/checkpatch.pl,
Thanks for the pointer.
Here is an updated patch with these minor fixes.
Christophe.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
target-arm/helpers.h
On 24.01.2011 11:23, Christophe Lyon wrote:
OK, I am going to have a look at gitorious. In the mean time, I have a bit of
cleanup and minimal documentation to perform.
Hi,
You can have a look at http://gitorious.org/arm-neon-tests/arm-neon-tests.
For sure it will need some polishing
This patch fixes the errors reported by my tests in VSRA.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
target-arm/translate.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/target-arm/translate.c b/target-arm/translate.c
index 7cb48c0..4cf2ecd 100644
On 31.01.2011 09:20, Aurelien Jarno wrote:
On Fri, Jan 28, 2011 at 04:50:59PM +0100, christophe.l...@st.com wrote:
From: Christophe Lyon christophe.l...@st.com
Handle corner cases where the addition of the rounding constant could
cause overflows.
After applying this patch, I get
On 31.01.2011 10:44, Aurelien Jarno wrote:
On Mon, Jan 31, 2011 at 10:35:30AM +0100, Christophe Lyon wrote:
On 31.01.2011 09:20, Aurelien Jarno wrote:
On Fri, Jan 28, 2011 at 04:50:59PM +0100, christophe.l...@st.com wrote:
From: Christophe Lyon christophe.l...@st.com
Handle corner cases
On 25.01.2011 18:18, Christophe Lyon wrote:
This patch fixes the errors reported by my tests in VSRA.
ping?
On 24.01.2011 13:41, Christophe Lyon wrote:
Here is an updated patch with these minor fixes.
ping?
On 31.01.2011 17:46, Peter Maydell wrote:
On 31 January 2011 15:59, Aurelien Jarno aurel...@aurel32.net wrote:
It seems the problems come from here, if I add --enable-debug, I am not
able to reproduce the problem anymore. I don't understand why though.
--enable-debug turns off optimisation
. This patch only modifies the
commonNaNToFloat32 and commonNaNToFloat64 conversion functions, as ARM
only uses these.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
checkpatch complains in this patch, but I have kept the style already present
in the involved files.
fpu/softfloat
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
target-arm/helpers.h | 12 --
target-arm/neon_helper.c | 89 ++
target-arm/op_helper.c | 49 -
target-arm/translate.c | 18 -
4 files changed
Some CPUs have a status flag imposing to return floatxx_default_nan
whatever the input value, when converting from one FP format to
another. Implement this, using the already existing default_nan_mode
status flag (currently used on ARM and SH4 at the moment).
Signed-off-by: Christophe Lyon
On 04.02.2011 20:47, Aurelien Jarno wrote:
On Fri, Feb 04, 2011 at 02:44:48PM +, Peter Maydell wrote:
On 4 February 2011 14:01, Christophe Lyon christophe.l...@st.com wrote:
The target-specific #ifdef is pretty ugly.
I wanted to be safe (not breaking other targets
On 07.02.2011 17:08, Peter Maydell wrote:
On 31 January 2011 18:06, christophe.l...@st.com wrote:
From: Christophe Lyon christophe.l...@st.com
Handle unsigned variant of VQ(R)SHRN instructions.
This patch appears to be modifying a section of code
that was already patched by 2/8
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
Submitted as a standalone patch as suggested by Peter, along with his
corrections.
target-arm/translate.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/target-arm/translate.c b/target-arm
On 08.02.2011 16:59, Peter Maydell wrote:
Your subject is a bit long, which can make it wrap annoyingly in git logs.
I'd suggest something like:
OK.
This is float32_to_float16() but it looks like you've missed
float16_to_float32() ?
Well, actually I somewhat managed to persuade myself
On 07.02.2011 16:57, Peter Maydell wrote:
On 31 January 2011 18:06, christophe.l...@st.com wrote:
For variants with rounding, fix cases where adding the rounding
constant could overflow.
For VSHLL, fix bit mask.
These two things are completely distinct -- please put them
in separate
Fix bit mask used when widening the result of shift on narrow input.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
target-arm/translate.c | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/target-arm/translate.c b/target-arm/translate.c
index
Create and use neon_unarrow_sat* helpers.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
target-arm/helpers.h |3 ++
target-arm/neon_helper.c | 63 ++
target-arm/translate.c | 28
3 files changed, 88
Now use the same algorithm as described in the ARM ARM.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
target-arm/helper.c | 72 ++
1 files changed, 60 insertions(+), 12 deletions(-)
diff --git a/target-arm/helper.c b/target-arm
On 14.02.2011 10:46, Christophe Lyon wrote:
Now use the same algorithm as described in the ARM ARM.
oops sorry, I have sent the wrong patch. Please ignore this version.
Christophe.
These two special values are needed to implement some helper functions, which
return these values in some cases.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
fpu/softfloat-specialize.h |9 +
fpu/softfloat.h|2 ++
2 files changed, 11 insertions(+), 0
On 14.02.2011 19:12, Peter Maydell wrote:
On 11 February 2011 15:10, christophe.l...@st.com wrote:
+uint32_t HELPER(neon_rshl_s32)(uint32_t valop, uint32_t shiftop)
+{
+int32_t dest;
+int32_t val = (int32_t)valop;
+int8_t shift = (int8_t)shiftop;
+if (shift = 32) {
+
-dest = src1 (tmp - 1); \
+dest = src1 (-tmp - 1); \
dest++; \
dest = 1; \
Again, these three lines have the same effect as dest = 0,
so we can fold into the previous if().
} else if (tmp 0) { \
@@ -594,7 +594,7 @@ uint64_t
On 14.02.2011 19:18, Peter Maydell wrote:
On 11 February 2011 15:10, christophe.l...@st.com wrote:
From: Christophe Lyon christophe.l...@st.com
This patch series provides fixes such that ARM Neon instructions
VRSHR, VRSRA, VQRSHRN, VQRSHRUN, VRSHRN, VQSHRN, VSHRN, VQSHRUN now
pass all my
@@ -924,7 +924,11 @@ uint32_t HELPER(neon_qrshl_s32)(CPUState *env, uint32_t
valop, uint32_t shiftop)
dest = val shift;
if ((dest shift) != val) {
SET_QC();
-dest = (uint32_t)(1 (sizeof(val) * 8 - 1)) - (val 0 ? 1 :
0);
+if (val
On 15.02.2011 15:21, Peter Maydell wrote:
On 15 February 2011 14:03, Christophe Lyon christophe.l...@st.com wrote:
It also seems that the neon_shl_s* helpers don't handle correctly large
negative shift amounts.
They look OK to me (large -ve shift is a huge right shift,
which for signed
On 15.02.2011 14:44, Peter Maydell wrote:
This patch series fixes bugs in the Neon shift instructions
VRSHR, VRSRA, VQRSHRN, VQRSHRUN, VRSHRN, VQSHRN, VSHRN, VQSHRUN,
VRSHL, and VQRSHL. It is based on the v3 patchset Christophe
sent recently, with some fixes for minor nits in those patches,
On 16.02.2011 12:53, Peter Maydell wrote:
On 14 February 2011 16:47, Christophe Lyon christophe.l...@st.com wrote:
These two special values are needed to implement some helper functions,
which return these values in some cases.
I assume this is for vrecpe, right? I think it would be better
On 16.02.2011 17:54, Peter Maydell wrote:
On 16 February 2011 14:51, christophe.l...@st.com wrote:
From: Christophe Lyon christophe.l...@st.com
These two special values are needed to implement some helper
functions, which return these values in some cases.
This patch also moves
+float_status *s = env-vfp.standard_fp_status;
+float64 one = int64_to_float64(1, s);
You don't need to create a variable for this, float64_one
will do what you want.
OK
+/* q = (int)(a * 512.0) */
+float64 x512 = int64_to_float64(512, s);
+float64 q =
, float64_256 and
float64_512.
Patch #3 uses these newly exported values and uses the VRECPE
algorithm described in the ARM ARM.
Patch #4 uses these newly exported values and uses the VRSQRTE
algorithm described in the ARM ARM.
Thanks to Peter for his careful reviews.
Christophe Lyon (4):
softfloat
These constants and utility function are needed to implement some
helpers. Defining constants avoids the need to re-compute them at
runtime.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
fpu/softfloat.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git
Now use the same algorithm as described in the ARM ARM.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
target-arm/helper.c | 121 ++
1 files changed, 111 insertions(+), 10 deletions(-)
diff --git a/target-arm/helper.c b/target-arm
Now use the same algorithm as described in the ARM ARM.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
target-arm/helper.c | 83 +++---
1 files changed, 71 insertions(+), 12 deletions(-)
diff --git a/target-arm/helper.c b/target-arm
These special values are needed to implement some helper functions,
which return/use these values in some cases.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
fpu/softfloat-specialize.h | 68 ---
fpu/softfloat.h| 69
On ARM, the SYS_EXIT semi-hosting call has no room for application
exit code, hence exiting a program from qemu always returns 0.
This patch catches to argument passed to exit() and uses it as the
return code when processing SYS_EXIT.
Signed-off-by: Christophe Lyon christophe.l...@st.com
On 18.02.2011 17:13, Peter Maydell wrote:
I'm afraid you've just run into the limitations of semihosting
as an API again: it doesn't provide a way for programs to pass
Indeed.
out an exit code, and trying to shoehorn back doors for this
into qemu just results in ugly code in qemu. The qemu
On 20.02.2011 23:20, Aurelien Jarno wrote:
On Sun, Feb 20, 2011 at 10:09:46PM +, Peter Maydell wrote:
On 20 February 2011 21:52, Aurelien Jarno aurel...@aurel32.net wrote:
While it's probably a good idea to define the commonly used values in
softfloat.h, I don't think we should have all
These two constants will be used by helper functions such as recpe_f32
and rsqrte_f32.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
target-arm/helper.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index
Now use the same algorithm as described in the ARM ARM.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
target-arm/helper.c | 121 ++
1 files changed, 111 insertions(+), 10 deletions(-)
diff --git a/target-arm/helper.c b/target-arm
These constants and utility function are needed to implement some
helpers. Defining constants avoids the need to re-compute them at
runtime.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
fpu/softfloat.h | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff
Now use the same algorithm as described in the ARM ARM.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
target-arm/helper.c | 83 +++---
1 files changed, 71 insertions(+), 12 deletions(-)
diff --git a/target-arm/helper.c b/target-arm
These special values are needed to implement some helper functions,
which return/use these values in some cases.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
fpu/softfloat-specialize.h | 68 ---
fpu/softfloat.h| 69
comments into account (http://patchwork.ozlabs.org/patch/83603/):
constants 256 and 512 are now defined locally in target-arm/helper.c.
Christophe Lyon (5):
softfloat: move all default NaN definitions to softfloat.h.
softfloat: add _set_sign(), _infinity and _half for 32 and 64 bits
floats
These 5 patches fix the ARM Neon VRECPE and VRSQRTE instructions by
matching the algorithms descibed in the ARM ARM.
Patches #1 to #3 are unchanged compared to v4
Patches #4 and #5 should address Peter's comments.
Christophe Lyon (5):
softfloat: move all default NaN definitions to softfloat.h
These two constants will be used by helper functions such as recpe_f32
and rsqrte_f32.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
target-arm/helper.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index
These constants and utility function are needed to implement some
helpers. Defining constants avoids the need to re-compute them at
runtime.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
fpu/softfloat.h | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff
Now use the same algorithm as described in the ARM ARM.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
target-arm/helper.c | 83 +++---
1 files changed, 71 insertions(+), 12 deletions(-)
diff --git a/target-arm/helper.c b/target-arm
These special values are needed to implement some helper functions,
which return/use these values in some cases.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
fpu/softfloat-specialize.h | 68 ---
fpu/softfloat.h| 69
Now use the same algorithm as described in the ARM ARM.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
target-arm/helper.c | 123 ++
1 files changed, 113 insertions(+), 10 deletions(-)
diff --git a/target-arm/helper.c b/target-arm
Ping?
On 25.06.2010 17:44, Christophe LYON wrote:
Hello,
I propose this small patch so that ARM semi-hosting handles stderr as
expected when linking with Newlib/libgloss.
diff --git a/arm-semi.c b/arm-semi.c
index 9549e6c..6874036 100644
--- a/arm-semi.c
+++ b/arm-semi.c
@@ -211,8 +211,11
Hello,
I am trying to use qemu-system-arm (0.12.3) to execute an ARM bare
machine program (not a Linux kernel), and I have some trouble when the
program in question tries to read from stdin.
The program does use ARM semihosting to communicate with the host.
Here is the sample code:
On 18.06.2010 18:52, Paul Brook wrote:
$ qemu-system-arm -semihosting -cpu cortex-a9 -nographic -kernel
./input.exe
-nographic implies -monitor stdio -serial stdio. Don't do that if you want to
access stdio via semihosting.
Indeed, using either
-monitor null -serial none -nographic
or
Hello,
I propose this small patch so that ARM semi-hosting handles stderr as
expected when linking with Newlib/libgloss.
diff --git a/arm-semi.c b/arm-semi.c
index 9549e6c..6874036 100644
--- a/arm-semi.c
+++ b/arm-semi.c
@@ -211,8 +211,11 @@ uint32_t do_arm_semihosting(CPUState *env)
Hello,
I propose this small patch so that the qemu log file has a unique name,
to help running several QEmu processes at once (or with different users).
Is it OK?
Thanks
Christophe.
diff --git a/exec.c b/exec.c
index 5969eb2..5ba8d7e 100644
--- a/exec.c
+++ b/exec.c
@@ -1516,7 +1516,10 @@
Maybe adding a -logfile option would allow what you're trying to achieve
without affecting other use cases? I've always thought that it's strange
that you can only change the logfile location in the monitor and not on
the command line.
Kevin
Here is patch that does what you suggest.
mailer won't scramble everything.
Signed-off-by: Christophe Lyon christophe.l...@st.com
bsd-user/main.c| 34 --
darwin-user/main.c | 32 +++-
linux-user/main.c | 32 +++-
qemu-doc.texi | 12
Hello,
I am facing a problem when using qemu-arm, when the target code uses the
SYS_GET_CMDLINE semi-hosting call.
Indeed, in arm-semi.c (line ~376), args are read from
ts-info-host_argv, which in turn has been initialised much earlier in
linuxload.c:load_exec with the value of target_argv.
Indeed, the result is known to be always positive.
Signed-off-by: Christophe Lyon christophe.l...@st.com
---
target-arm/helper.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index d3a3ba2..ff5456c 100644
--- a/target-arm
On 09.10.2011 00:57, Peter Maydell wrote:
On 3 October 2011 15:28, Christophe Lyonchristophe.l...@st.com wrote:
Indeed, the result is known to be always positive.
-val = ((val64 63) 0x8000)
-| ((result_exp 0xff) 23)
+val = ((result_exp 0xff) 23)
| ((val64
Hi,
Here is a small patch for the /proc/self/maps output (Linux user
mode), which adds a space after the last number in the case where
there is no filename to print. This matches what the kernel does, and
is expected by libsanitizer.
Christophe.
qemu-maps.patch
Description: Binary data
Ping?
On 2 April 2013 14:03, Christophe Lyon christophe.l...@linaro.org wrote:
Add a space at end of line when there is no filename to print, to
conform to linux kernel format (see show_map_vma() in
fs/proc/task_mmu.c).
Signed-off-by: Christophe Lyon christophe.l...@linaro.org
---
Changes
is the license change
and a global modification of the comment structure. This patch rebases
our softfloat code to SoftFloat-2a in order to have a GPLv2 compatible
license.
Acked-by: Christophe Lyon christophe.l...@st.com
Hi,
Would it be possible to include the small patch at:
https://lists.gnu.org/archive/html/qemu-devel/2013-05/msg00530.html
Thanks
Christophe.
On 09.05.2013 00:29, Anthony Liguori wrote:
Hi,
On behalf of the QEMU Team, I'd like to announce the availability of the
second release candidate
Hi,
May I ping for this small patch?
Thanks,
Christophe
On 19 February 2013 17:28, Christophe Lyon christophe.l...@linaro.org wrote:
Hi,
Here is a small patch for the /proc/self/maps output (Linux user
mode), which adds a space after the last number in the case where
there is no filename
there is no filename
to print, to conform to linux kernel format.
Signed-off-by: Christophe Lyon christophe.l...@linaro.org
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index a148d9f..3b0ca86 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -5016,7 +5016,7 @@ static int open_self_maps
Add a space at end of line when there is no filename to print, to
conform to linux kernel format.
Signed-off-by: Christophe Lyon christophe.l...@linaro.org
---
linux-user/syscall.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
Add a space at end of line when there is no filename to print, to
conform to linux kernel format (see show_map_vma() in
fs/proc/task_mmu.c).
Signed-off-by: Christophe Lyon christophe.l...@linaro.org
---
Changes v1-v2:
Additional space is now part of the format string.
linux-user/syscall.c
From: Christophe Lyon christophe.l...@linaro.org
mmap_flags_tbl contains a list of mmap flags, and how to map them to
the target. This patch adds MAP_NORESERVE, which was missing to the
list.
Signed-off-by: Christophe Lyon christophe.l...@linaro.org
---
linux-user/syscall.c | 2 ++
1 file
On 02/03/14 18:46, Peter Maydell wrote:
On 3 February 2014 16:04, Christophe Lyon christophe.l...@st.com wrote:
From: Christophe Lyon christophe.l...@linaro.org
mmap_flags_tbl contains a list of mmap flags, and how to map them to
the target. This patch adds MAP_NORESERVE, which was missing
Public bug reported:
Hello,
It seems that qemu-arm does not reject some v8-only instructions as it
should, but executes them "correctly".
For instance, while compiling/running some of the GCC ARM instrinsics tests, we
noticed that
vrintz should be rejected on cortex-a9 for instance, while it
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
RMv7.
> (We got this right for all the other new-in-v8 insns, but forgot
> it for these Neon 2-reg-misc ops.)
>
> Reported-by: Christophe Lyon <christophe.l...@linaro.org>
> Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
> ---
> Christophe: I'd appreciate it i
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
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
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'
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
** 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
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:
$
** 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
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
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
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
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,
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
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
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
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
1 - 100 of 184 matches
Mail list logo
