[Qemu-devel] [Bug 702885] Re: Internal resource leak error with ARM NEON vmull.s32 insn
I can confirm that this bug is gone with QEMU commit commit
0fad6efce5d3f18278b7239dece3c251b3e7c04d.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/702885
Title:
Internal resource leak error with ARM NEON vmull.s32 insn
Status in QEMU:
Fix Committed
Bug description:
This bug occurs in qemu, commit
78a59470e6bbc6e16dc4033767492649c1ae4cfd (most recent as of
01/14/2011).
Compile, assemble, and link the code below, with the ARM tools. (I use
ARM C/C++ Compiler, 4.1 [Build 462]).
armasm --cpu Cortex-A8 --licensing=flex foo.s
armcc --cpu Cortex-A8 --licensing=flex -o main -L--sysv main.c foo.o
Execute on qemu-arm and observe an Internal resource leak message.
qemu-arm main
Internal resource leak before 818c
- Wolfgang
main.c:
int main(void)
{
void foofunc(void);
foofunc();
return 0 ;
}
foo.s:
ARM
REQUIRE8
PRESERVE8
AREA code, CODE, READONLY, ALIGN=2
foofunc PROC
VMULL.S32 q1, d2, d4
MOV pc, lr
ENDP
EXPORT foofunc [CODE]
END
[Qemu-devel] [Bug 702885] Re: Internal resource leak error with ARM NEON vmull.s32 insn
** Attachment added: Binary to reproduce bug
https://bugs.launchpad.net/qemu/+bug/702885/+attachment/1801849/+files/main.axf
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/702885
Title:
Internal resource leak error with ARM NEON vmull.s32 insn
Status in QEMU:
New
Bug description:
This bug occurs in qemu, commit
78a59470e6bbc6e16dc4033767492649c1ae4cfd (most recent as of
01/14/2011).
Compile, assemble, and link the code below, with the ARM tools. (I use
ARM C/C++ Compiler, 4.1 [Build 462]).
armasm --cpu Cortex-A8 --licensing=flex foo.s
armcc --cpu Cortex-A8 --licensing=flex -o main -L--sysv main.c foo.o
Execute on qemu-arm and observe an Internal resource leak message.
qemu-arm main
Internal resource leak before 818c
- Wolfgang
main.c:
int main(void)
{
void foofunc(void);
foofunc();
return 0 ;
}
foo.s:
ARM
REQUIRE8
PRESERVE8
AREA code, CODE, READONLY, ALIGN=2
foofunc PROC
VMULL.S32 q1, d2, d4
MOV pc, lr
ENDP
EXPORT foofunc [CODE]
END
[Qemu-devel] RE: [Bug 702885] Re: Internal resource leak error with ARM NEONvmull.s32 insn
Duh. I had missed the greater part of Christophe's patch (I am still
having trouble with my mail client; applying patches off the list is
manual for me).
With both patches applied, indeed the bug filed on launchpad seems
fixed. On my second test case, behaviour is much improved. Thanks much!
- Wolfgang
-Original Message-
From: boun...@canonical.com [mailto:boun...@canonical.com] On
Behalf Of Peter Maydell
Sent: Friday, January 21, 2011 8:01 AM
To: Schildbach, Wolfgang
Subject: [Bug 702885] Re: Internal resource leak error with
ARM NEONvmull.s32 insn
That binary executes OK for me with no resource leak messages with:
qemu master as of commit b646968336
http://patchwork.ozlabs.org/patch/79728/
http://patchwork.ozlabs.org/patch/79581/
(i386 host.)
--
You received this bug notification because you are a direct
subscriber of the bug.
https://bugs.launchpad.net/bugs/702885
Title:
Internal resource leak error with ARM NEON vmull.s32 insn
Status in QEMU:
New
Bug description:
This bug occurs in qemu, commit
78a59470e6bbc6e16dc4033767492649c1ae4cfd (most recent as of
01/14/2011).
Compile, assemble, and link the code below, with the ARM
tools. (I use
ARM C/C++ Compiler, 4.1 [Build 462]).
armasm --cpu Cortex-A8 --licensing=flex foo.s
armcc --cpu Cortex-A8 --licensing=flex -o main -L--sysv main.c foo.o
Execute on qemu-arm and observe an Internal resource leak message.
qemu-arm main
Internal resource leak before 818c
- Wolfgang
main.c:
int main(void)
{
void foofunc(void);
foofunc();
return 0 ;
}
foo.s:
ARM
REQUIRE8
PRESERVE8
AREA code, CODE, READONLY, ALIGN=2
foofunc PROC
VMULL.S32 q1, d2, d4
MOV pc, lr
ENDP
EXPORT foofunc [CODE]
END
To unsubscribe from this bug, go to:
https://bugs.launchpad.net/qemu/+bug/702885/+subscribe
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/702885
Title:
Internal resource leak error with ARM NEON vmull.s32 insn
Status in QEMU:
New
Bug description:
This bug occurs in qemu, commit
78a59470e6bbc6e16dc4033767492649c1ae4cfd (most recent as of
01/14/2011).
Compile, assemble, and link the code below, with the ARM tools. (I use
ARM C/C++ Compiler, 4.1 [Build 462]).
armasm --cpu Cortex-A8 --licensing=flex foo.s
armcc --cpu Cortex-A8 --licensing=flex -o main -L--sysv main.c foo.o
Execute on qemu-arm and observe an Internal resource leak message.
qemu-arm main
Internal resource leak before 818c
- Wolfgang
main.c:
int main(void)
{
void foofunc(void);
foofunc();
return 0 ;
}
foo.s:
ARM
REQUIRE8
PRESERVE8
AREA code, CODE, READONLY, ALIGN=2
foofunc PROC
VMULL.S32 q1, d2, d4
MOV pc, lr
ENDP
EXPORT foofunc [CODE]
END
[Qemu-devel] [Bug 702885] Re: Internal resource leak error with ARM NEON vmull.s32 insn
This bug is fixed on HEAD in the qemu-meego tree (commit
8493a687d54e542ac4eec8b2f8326415edf37ec4
A)
- Wolfgang
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/702885
Title:
Internal resource leak error with ARM NEON vmull.s32 insn
Status in QEMU:
New
Bug description:
This bug occurs in qemu, commit
78a59470e6bbc6e16dc4033767492649c1ae4cfd (most recent as of
01/14/2011).
Compile, assemble, and link the code below, with the ARM tools. (I use
ARM C/C++ Compiler, 4.1 [Build 462]).
armasm --cpu Cortex-A8 --licensing=flex foo.s
armcc --cpu Cortex-A8 --licensing=flex -o main -L--sysv main.c foo.o
Execute on qemu-arm and observe an Internal resource leak message.
qemu-arm main
Internal resource leak before 818c
- Wolfgang
main.c:
int main(void)
{
void foofunc(void);
foofunc();
return 0 ;
}
foo.s:
ARM
REQUIRE8
PRESERVE8
AREA code, CODE, READONLY, ALIGN=2
foofunc PROC
VMULL.S32 q1, d2, d4
MOV pc, lr
ENDP
EXPORT foofunc [CODE]
END
[Qemu-devel] [Bug 702885] [NEW] Internal resource leak error with ARM NEON vmull.s32 insn
Public bug reported:
This bug occurs in qemu, commit 78a59470e6bbc6e16dc4033767492649c1ae4cfd
(most recent as of 01/14/2011).
Compile, assemble, and link the code below, with the ARM tools. (I use
ARM C/C++ Compiler, 4.1 [Build 462]).
armasm --cpu Cortex-A8 --licensing=flex foo.s
armcc --cpu Cortex-A8 --licensing=flex -o main -L--sysv main.c foo.o
Execute on qemu-arm and observe an Internal resource leak message.
qemu-arm main
Internal resource leak before 818c
- Wolfgang
main.c:
int main(void)
{
void foofunc(void);
foofunc();
return 0 ;
}
foo.s:
ARM
REQUIRE8
PRESERVE8
AREA code, CODE, READONLY, ALIGN=2
foofunc PROC
VMULL.S32 q1, d2, d4
MOV pc, lr
ENDP
EXPORT foofunc [CODE]
END
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/702885
Title:
Internal resource leak error with ARM NEON vmull.s32 insn
Status in QEMU:
New
Bug description:
This bug occurs in qemu, commit
78a59470e6bbc6e16dc4033767492649c1ae4cfd (most recent as of
01/14/2011).
Compile, assemble, and link the code below, with the ARM tools. (I use
ARM C/C++ Compiler, 4.1 [Build 462]).
armasm --cpu Cortex-A8 --licensing=flex foo.s
armcc --cpu Cortex-A8 --licensing=flex -o main -L--sysv main.c foo.o
Execute on qemu-arm and observe an Internal resource leak message.
qemu-arm main
Internal resource leak before 818c
- Wolfgang
main.c:
int main(void)
{
void foofunc(void);
foofunc();
return 0 ;
}
foo.s:
ARM
REQUIRE8
PRESERVE8
AREA code, CODE, READONLY, ALIGN=2
foofunc PROC
VMULL.S32 q1, d2, d4
MOV pc, lr
ENDP
EXPORT foofunc [CODE]
END
[Qemu-devel] [Bug 673613] Re: ARM semihosting SYS_GET_CMDLINE does not return arguments
diff --git a/arm-semi.c b/arm-semi.c
index 0687b03..53b40e4 100644
--- a/arm-semi.c
+++ b/arm-semi.c
@@ -373,45 +373,48 @@ uint32_t do_arm_semihosting(CPUState *env)
#ifdef CONFIG_USER_ONLY
/* Build a commandline from the original argv. */
{
-char **arg = ts-info-host_argv;
-int len = ARG(1);
-/* lock the buffer on the ARM side */
-char *cmdline_buffer = (char*)lock_user(VERIFY_WRITE, ARG(0), len,
0);
+int i ;
-if (!cmdline_buffer)
-/* FIXME - should this error code be -TARGET_EFAULT ? */
-return (uint32_t)-1;
+char *arm_cmdline_buffer ;
+const char *host_cmdline_buffer ;
-s = cmdline_buffer;
-while (*arg len 2) {
-int n = strlen(*arg);
+int arm_cmdline_len = ARG(1) ;
+int host_cmdline_len = ts-info-arg_end-ts-info-arg_start ;
-if (s != cmdline_buffer) {
-*(s++) = ' ';
-len--;
-}
-if (n = len)
-n = len - 1;
-memcpy(s, *arg, n);
-s += n;
-len -= n;
-arg++;
-}
-/* Null terminate the string. */
-*s = 0;
-len = s - cmdline_buffer;
+if (host_cmdline_len arm_cmdline_len)
+return (uint32_t)-1; /* command line too long */
+
+/* lock the buffers on the ARM side */
+arm_cmdline_buffer = (char*)lock_user(VERIFY_WRITE, ARG(0),
host_cmdline_len, 0);
+host_cmdline_buffer = (const char*)lock_user(PAGE_READ,
ts-info-arg_start, host_cmdline_len, 0);
-/* Unlock the buffer on the ARM side. */
-unlock_user(cmdline_buffer, ARG(0), len);
+if (arm_cmdline_buffer host_cmdline_buffer)
+{
-/* Adjust the commandline length argument. */
-SET_ARG(1, len);
+/* the last argument is zero-terminated;
+ no need for additional termination */
+memcpy(arm_cmdline_buffer, host_cmdline_buffer,
host_cmdline_len);
-/* Return success if commandline fit into buffer. */
-return *arg ? -1 : 0;
+/* separate arguments by white spaces */
+for (i = 0; i host_cmdline_len-1; i++) {
+if (arm_cmdline_buffer[i] == 0) {
+arm_cmdline_buffer[i] = ' ';
+}
+}
+
+/* Adjust the commandline length argument. */
+SET_ARG(1, host_cmdline_len);
+}
+
+/* Unlock the buffers on the ARM side. */
+unlock_user(arm_cmdline_buffer, ARG(0), host_cmdline_len);
+unlock_user((void*)host_cmdline_buffer, ts-info-arg_start,
host_cmdline_len);
+
+/* Return success if we could return a commandline. */
+return (arm_cmdline_buffer host_cmdline_buffer) ? 0 : -1;
}
#else
- return -1;
+return -1;
#endif
case SYS_HEAPINFO:
{
diff --git a/bsd-user/bsdload.c b/bsd-user/bsdload.c
index 14a93bf..6d9bb6f 100644
--- a/bsd-user/bsdload.c
+++ b/bsd-user/bsdload.c
@@ -176,8 +176,6 @@ int loader_exec(const char * filename, char ** argv, char
** envp,
retval = prepare_binprm(bprm);
-infop-host_argv = argv;
-
if(retval=0) {
if (bprm.buf[0] == 0x7f
bprm.buf[1] == 'E'
diff --git a/bsd-user/qemu.h b/bsd-user/qemu.h
index 9763616..e343894 100644
--- a/bsd-user/qemu.h
+++ b/bsd-user/qemu.h
@@ -50,7 +50,6 @@ struct image_info {
abi_ulong entry;
abi_ulong code_offset;
abi_ulong data_offset;
-char **host_argv;
int personality;
};
diff --git a/linux-user/linuxload.c b/linux-user/linuxload.c
index 9ee27c3..ac8c486 100644
--- a/linux-user/linuxload.c
+++ b/linux-user/linuxload.c
@@ -174,8 +174,6 @@ int loader_exec(const char * filename, char ** argv, char
** envp,
retval = prepare_binprm(bprm);
-infop-host_argv = argv;
-
if(retval=0) {
if (bprm-buf[0] == 0x7f
bprm-buf[1] == 'E'
diff --git a/linux-user/qemu.h b/linux-user/qemu.h
index 708021e..8f0a81f 100644
--- a/linux-user/qemu.h
+++ b/linux-user/qemu.h
@@ -50,7 +50,6 @@ struct image_info {
abi_ulong saved_auxv;
abi_ulong arg_start;
abi_ulong arg_end;
-char**host_argv;
int personality;
};
--
ARM semihosting SYS_GET_CMDLINE does not return arguments
https://bugs.launchpad.net/bugs/673613
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: New
Bug description:
I have downloaded version 0.13.0 of the code, configured with: './configure'
[Qemu-devel] [Bug 673613] Re: ARM semihosting SYS_GET_CMDLINE does not return arguments
Hi Peter, Is this what you had in mind? -- ARM semihosting SYS_GET_CMDLINE does not return arguments https://bugs.launchpad.net/bugs/673613 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: I have downloaded version 0.13.0 of the code, configured with: './configure' '--prefix=/tmp/qemu-0.13.0' '--interp-prefix=/tmp/qemu-0.13.0/usr/local/gnemul/qemu-%M' '--target-list=arm-softmmu arm-linux-user armeb-linux-user' and built using gcc version 4.3.2 (Debian 4.3.2-1.1). Execution environment is Debian, kernel 2.6.26-2-686. I am running a barebone helloworld.c which echoes its commandline arguments, compiled with ADS1.2 from ARM. The arguments never get echoed back. I have found the culprit in the source code, lines 3020 and 3022 of linux-user/main.c which free target_argv[]. However, loader_exec(), which is called a couple lines above, records the pointer to target_argv[]. So, when the data is accessed in arm-semi.c, it is actually trying to load from memory that has been free()d already. This bug manifests itself for baremetal simulation, but I suspect it hits other platforms as well.
[Qemu-devel] [Bug 673613] [NEW] ARM semihosting SYS_GET_CMDLINE does not return arguments
Public bug reported: I have downloaded version 0.13.0 of the code, configured with: './configure' '--prefix=/tmp/qemu-0.13.0' '--interp- prefix=/tmp/qemu-0.13.0/usr/local/gnemul/qemu-%M' '--target-list=arm- softmmu arm-linux-user armeb-linux-user' and built using gcc version 4.3.2 (Debian 4.3.2-1.1). Execution environment is Debian, kernel 2.6.26-2-686. I am running a barebone helloworld.c which echoes its commandline arguments, compiled with ADS1.2 from ARM. The arguments never get echoed back. I have found the culprit in the source code, lines 3020 and 3022 of linux-user/main.c which free target_argv[]. However, loader_exec(), which is called a couple lines above, records the pointer to target_argv[]. So, when the data is accessed in arm-semi.c, it is actually trying to load from memory that has been free()d already. This bug manifests itself for baremetal simulation, but I suspect it hits other platforms as well. ** Affects: qemu Importance: Undecided Status: New -- ARM semihosting SYS_GET_CMDLINE does not return arguments https://bugs.launchpad.net/bugs/673613 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: I have downloaded version 0.13.0 of the code, configured with: './configure' '--prefix=/tmp/qemu-0.13.0' '--interp-prefix=/tmp/qemu-0.13.0/usr/local/gnemul/qemu-%M' '--target-list=arm-softmmu arm-linux-user armeb-linux-user' and built using gcc version 4.3.2 (Debian 4.3.2-1.1). Execution environment is Debian, kernel 2.6.26-2-686. I am running a barebone helloworld.c which echoes its commandline arguments, compiled with ADS1.2 from ARM. The arguments never get echoed back. I have found the culprit in the source code, lines 3020 and 3022 of linux-user/main.c which free target_argv[]. However, loader_exec(), which is called a couple lines above, records the pointer to target_argv[]. So, when the data is accessed in arm-semi.c, it is actually trying to load from memory that has been free()d already. This bug manifests itself for baremetal simulation, but I suspect it hits other platforms as well.
Re: [Qemu-devel] Porting QEMU to PalmOS
Try compiling as position-dependent (i.e. not PIC) code. GOT is a typical feature of position independent code. - Wolfgang [EMAIL PROTECTED] wrote on 23.05.2007 13:20:22: Hi Johannes, thanks for your quick response. I thought QEMU was already compiled and run on an ARM machine? If so, how come that noone else had such problem (I searched for it on google), and PXA255 is a standard ARM CPU with a few additional instructions. And how to make them not come from GOT, those vars are declared as extern, so they are globals? BR, Voda. - Original Message From: Johannes Schindelin [EMAIL PROTECTED] To: sinisa marovic [EMAIL PROTECTED] Cc: qemu-devel@nongnu.org Sent: Wednesday, May 23, 2007 12:48:59 PM Subject: Re: [Qemu-devel] Porting QEMU to PalmOS Hi, On Wed, 23 May 2007, sinisa marovic wrote: Relocation types that fail are 25 and 26, which are R_ARM_GOTPC and R_ARM_GOT32 respectively. Their names are: _GLOBAL_OFFSET_TABLE_ cc_table __op_param1 __op_param2 __op_param3 Is there a way to fix this? The GOT is an offset table. Many CPUs have fixed-size instruction sets, which means that you cannot easily jump to an absolute address, since the address alone would already fill up the size. Of course, this is a no-no for QEmu, since the _same_ function snippet will be reused _multiple_ times. So, the address must not come from a GOT, but be inserted directly into the code. I do not remember off-hand how I managed to do this a couple of years ago, when I worked on a MIPS host, but there _are_ gcc options to avoid a GOT. Hth, Dscho Food fight? Enjoy some healthy debate in the Yahoo! Answers Food Drink QA.
Re: SV: [Qemu-devel] ARM CPSR and conditional instructions
I very much doubt there is any problem with the CPSR. The ARM emulation has correctly run hundreds of millions of instructions coming from many different compilers and hand-written assembly. Can you be more precise in what the effect is that you see? - Wolfgang [EMAIL PROTECTED] wrote on 22.11.2006 22:13:01: I?m sorry for spamming you mailing list with my duplicate posts. I had some problems sending my mail. /Torbjörn Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Torbjörn Andersson Skickat: den 21 november 2006 22:16 Till: qemu-devel@nongnu.org Ämne: [Qemu-devel] ARM CPSR and conditional instructions Hello qemu developers! I´m using QEMU for some ARM debugging and I have som questions regardning the CPSR register. I get the feeling that the CPSR condition code bits, representing the results from the ALU, are not maintained at all points. Is the JIT in QEMU tailored in any way towards GCC output? (Resulting in issues with the output of other compilers that make use of the conditional execution of instructions etc.) What I want to do is to try to verify QEMU maintains the CPSR register and if not fix it. However, it is not trivial identify where the updates should be placed. The relationship between translate.c and op.c is not trival I must say :) I would be happy I anyone here could give me some pointers on how the updates of the CPSR register is done today and what the strategy is. I guess there are plenty of performance ideas here as in the rest of qemu. Does anyone have any reflection on this topic or can anyone give me some pointers? Torbjörn ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu-0.8.2 on glibc 2.2.5: CLOCK_MONOTONIC not defined
I stumbled upon the same problem as Bill Rossi (see his post below):
The current cvs version of qemu fails to compile on my machine because
CLOCK_MONOTONIC is not defined in my glibc. According to clock_gettime(3),
systems that define this functionality have _POSIX_MONOTONIC_CLOCK and
_POSIX_TIMERS set. Updating the ifdef (see patch below) to include these
makes the offending code go away on my CLOCK_MONOTONIC-less system
(gcc3.3), but continues to include it on a newer system with a later
libgcc. Not sure if the __linux__ in there is still necessary, but I left
it in for good measure.
Please consider for inclusing into CVS.
Thx,
- Wolfgang Schildbach
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.217
diff -r1.217 vl.c
550c550
#if defined(__linux__)
---
#if defined (__linux__) defined(_POSIX_TIMERS)
defined(_POSIX_MONOTONIC_CLOCK)
562c562
#if defined(__linux__)
---
#if defined (__linux__) defined(_POSIX_TIMERS)
defined(_POSIX_MONOTONIC_CLOCK)
Bill Rossi wrote on 26.07.2006 19:38:08:
Fails to compile on Linux with glibc 2.2.5. CLOCK_MONOTONIC isn't
defined in glibc 2.2.5. The following patch is a workaround:
--- qemu-0.8.2/vl.c 2006-07-22 13:23:34.0 -0400
+++ ../qemu-0.8.2/vl.c 2006-07-26 11:37:34.0 -0400
@@ -541,7 +541,7 @@
static void init_get_clock(void)
{
use_rt_clock = 0;
-#if defined(__linux__)
+#if 0 //defined(__linux__)
{
struct timespec ts;
if (clock_gettime(CLOCK_MONOTONIC, ts) == 0) {
@@ -553,7 +553,7 @@
static int64_t get_clock(void)
{
-#if defined(__linux__)
+#if 0 //defined(__linux__)
if (use_rt_clock) {
struct timespec ts;
clock_gettime(CLOCK_MONOTONIC, ts);
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
--
Wolfgang Schildbach
Group Manager Systems Engineering and Consulting
Coding Technologies GmbH
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu-arm: Make commandline args available to semihosting
Hello list,
This patch implements the semihosting call to retrieve command line
arguments from the host environment. Without this patch, neither
arm-non-eabi-gcc compiled executables (which use semihosting) nor
ARM-compiler compiled executables can read command line arguments. It
works for both little- and bigendian executables, in user mode emulation.
The patch below applies on the 2006-07-31 version of qemu (later versions
of qemu don't work for me due to aio changes), but merging this into the
head should be very straightforward. See more text explaining the code in
http://lists.gnu.org/archive/html/qemu-devel/2006-06/msg00454.html .
Paul, do you want to take a look at this?
Thx,
- Wolfgang
--
Wolfgang Schildbach
Group Manager Systems Engineering and Consulting
Coding Technologies GmbH
Index: linux-user/arm-semi.c
===
RCS file: /sources/qemu/qemu/linux-user/arm-semi.c,v
retrieving revision 1.5
diff -r1.5 arm-semi.c
80c80,81
#define ARG(n) tget32(args + n * 4)
---
#define ARG(n) tget32(args + (n) * 4)
#define SET_ARG(n,val) tput32(args + (n) * 4,val)
161,164c162,199
/* XXX: Not implemented. */
s = (char *)g2h(ARG(0));
*s = 0;
return -1;
---
/* The ARM semihosting interface requires that the commandline is
presented with blanks separating the arguments. Thus, we need
to build a new command line, given the global pointer to the
command line we received.
A better way would be to build this command line on the user stack,
similar to the way it is done in loader_build_argptr(), and then
just hand that pointer back to the caller */
{
extern char **global_userspace_argv ; /* initialized in main() */
char **av = global_userspace_argv ; /* work ptr */
int len = ARG(1); /* amount of RAM that the ARM binary has set
aside for the command line */
/* lock the buffer on the ARM side */
char *cmdline_buffer = (char*)lock_user(ARG(0),len,0);
s = cmdline_buffer ;
do {
int n = strlen(*av) ;
/* is there still space in the supplied buffer, including
the terminating zero? */
if (s - cmdline_buffer + n+1 len)
break ; /* no */
memcpy(s,*av,n); s += n ;
*s++ = ' '; /* separate command line args with blank */
av++;
} while (*av);
*s++ = 0; /* terminate cmdline string with \0 */
/* unlock the buffer on the ARM side */
unlock_user(cmdline_buffer, ARG(0), len);
/* adjust the commandline length argument */
SET_ARG(1, (uint32_t)(s - cmdline_buffer));
/* successfull return if commandline fit into buffer */
return *av == 0 ? 0 : -1 ;
}
Index: linux-user/main.c
===
RCS file: /sources/qemu/qemu/linux-user/main.c,v
retrieving revision 1.92
diff -r1.92 main.c
290a291,293
/* XXX: this is an ugly hack, to make argc/argv available to ARM semihosting
*/
char **global_userspace_argv ;
1534a1538
global_userspace_argv = argv + optind;
1536c1540
if (loader_exec(filename, argv+optind, environ, regs, info) != 0) {
---
if ((loader_exec(filename, global_userspace_argv, environ, regs, info))
!= 0) {
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu-arm: Make commandline args available to semihosting
Hello list, ARM ADS/RVCT compiler generated executables by default use semihosting to communicate with the host, including retrieval of a commandline. The semihosting implementation up to now did not implement this functionality; this patch adds the SYS_GET_CMDLINE semihosting call, such that semihosting executables get a command line when executed through qemu-arm. This is a reworked patch an earlier version of which can be found at http://lists.gnu.org/archive/html/qemu-devel/2006-06/msg00323.html . The old version contained a bug which effectively limited the commandline to 128 bytes. (quoted from that earlier mail:) The patch below implements the SYS_GET_CMDLINE semihosting call, by keeping a global pointer to the user space commandline arguments, and by re-building a space-separated command line in the guest side supplied buffer. This patch has two shortcomings, which I would love to see feedback on: - I am keeping a global pointer in order to have a handle on the command line arguments inside do_arm_semihosting. Is there a better place to keep this? - The ARM (guest) side supplied buffer is only 256 bytes long; if the user supplied command line is larger, the semihosting call will fail (gracefully). A better strategy may be to build the string on the initial guest stack (similar to loader_build_argptgr()) and then hand that pointer to the guest. I am not quite sure whether the ARGS[] array should be locked before access (then again, none of the functions in do_arm_semihosting() do this). This is tested with both big- and littleendian emulation (i.e. qemu-arm and qemu-armeb). All comments welcome. -- Wolfgang Schildbach, Senior Research Engineer Coding Technologies GmbH arm_semihosting_commandline.diff Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Bug in target-arm/op.c; qsub gives wrong saturation
Hi, For the ARM9E target, qsub gives wrong output when saturating against -0x8000. The attached patch fixes an obvious typo that is causing this. Please consider this for inclusion into the mainline. Thanks, -- Wolfgang Schildbach, Senior Research Engineer Coding Technologies GmbH op_subl_T0_T1_saturate.diff Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu qemu-doc.texi
Hi Paul, Does this mean that qemu-arm should be able to run the binaries that are produced by RVCT? I am trying to run a simple helloworld, compiled and linked with rvct2.2 (armcc -g -o hello hello.c) into a ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped file, but qemu-arm fails with an error loading ./hello. On a related note, how do I go about debugging qemu (namely the part that loads executables)? Since qemu appears as a shared object, this is not so straightforward. When I start gdb on arm-user, set a breakpoint at main() and type run, I get cannot insert breakpoint 1. Error accessing memory address 0x1cfb2: Input/output error. The same program may be running in another process. (This is with gdb 5.2, but 6.3 is not much different) - Wolfgang [EMAIL PROTECTED] wrote on 11.06.2006 18:28:41: CVSROOT: /sources/qemu Module name: qemu Changes by: Paul Brook pbrook 06/06/11 16:28:41 Modified files: . : qemu-doc.texi Log message: Document new arm-user features. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi? cvsroot=qemur1=1.90r2=1.91 Patches: Index: qemu-doc.texi === RCS file: /sources/qemu/qemu/qemu-doc.texi,v retrieving revision 1.90 retrieving revision 1.91 diff -u -b -r1.90 -r1.91 --- qemu-doc.texi 26 May 2006 00:49:52 - 1.90 +++ qemu-doc.texi 11 Jun 2006 16:28:41 - 1.91 @@ -1531,6 +1531,7 @@ * Quick Start:: * Wine launch:: * Command line options:: +* Other binaries:: @end menu @node Quick Start @@ -1637,6 +1638,15 @@ Act as if the host page size was 'pagesize' bytes @end table [EMAIL PROTECTED] Other binaries [EMAIL PROTECTED] Other binaries + [EMAIL PROTECTED] is also capable of running ARM Angel semihosted ELF +binaries (as implemented by the arm-elf and arm-eabi Newlib/GDB +configurations), and arm-uclinux bFLT format binaries. + +The binary format is detected automatically. + @node compilation @chapter Compilation from the sources ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Wolfgang Schildbach, Senior Research Engineer Coding Technologies GmbH ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu qemu-doc.texi
Thanks much Paul -- that did the trick! (Well, almost.) For the benefit of other ADS/RVCT users that try this, here is what I did: - figured out the file offset of the executable region in the axf file (readelf -l foo.axf|grep LOAD). For me, the offset appears to always be 0x34, and the executable region starts at 0x8000. - linked the application with armlink --ro-base 0x8034. This will move the executable region to a new start which is page-aligned to the actual file offset. - finally (this took me a little to figure out), I made sure that the executable has execute permissions: chmod u+rx foo.axf. With these changes, I could execute ARM/RealView Developer Suite generated executables directly. This is excellent -- thanks much to all who contributed to make this possible! The one remaining issue is that command line parameters are not properly transfered over to the ARM executable. This surprises me a little, since this does work for arm-userspace-linux, and the mechanisms loading the image appear quite similar. Where would I (start to) look for the reasons behind this? Is this something that needs to be fixed on the ARM side (i.e. fix the location where the ARM code looks for the environment)? - Wolfgang Paul Brook [EMAIL PROTECTED] wrote on 12.06.2006 16:18:34: On Monday 12 June 2006 15:09, Wolfgang Schildbach wrote: Hi Paul, Does this mean that qemu-arm should be able to run the binaries that are produced by RVCT? I am trying to run a simple helloworld, compiled and linked with rvct2.2 (armcc -g -o hello hello.c) into a ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped file, but qemu-arm fails with an error loading ./hello. Yes it should be able to run RVCT binaries. The problem is that the qemu loader assumes the LMA and file offsets be page aligned (ie. be the same modulo the page size). This is part of the ABI for linux executables so that the binary can be mmapped directly into memory. RVCT does not enforce this alignment by default. On a related note, how do I go about debugging qemu (namely the part that loads executables)? Since qemu appears as a shared object, this is not so straightforward. When I start gdb on arm-user, set a breakpoint at main() and type run, I get Configure with --static. Paul -- Wolfgang Schildbach, Senior Research Engineer Coding Technologies GmbH ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Wolfgang Schildbach is out of the office.
I will be out of the office starting 14.04.2006 and will not return until 18.04.2006. I will respond to your message when I return. If you have a question or concern regarding our ARM decoder or encoder software, please direct your email to [EMAIL PROTECTED] Best regards, - Wolfgang Schildbach ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Missing ARMv6 instructions?
The way I understand this is that anyone who got ARM documentation with the license that Paul mentioned, could not contribute patches that implement v6 emulation. If, however, someone else (who has not signed such a license) were to buy documentation about the ARMv6 architecture that comes without a license (for example, the ARM System Developer's Guide, by Sloss, Symes, and Wright, Elsevier 2004), that someone should be able to contribute (at least in those aspects of the ARM that are disclosed by the book). In that case, ARM should not have any legal hooks except copyright, and since at that point you are not using any of their code, there is no case. However, I am not a lawyer, so don't take my word for it. As to the threats to ARM's business model, I could see them threatened if someone emulated the ARM on hardware of similar performance (without licensing ARM IP) -- that would undermine sales of the real ARM cores, depending on the price/performance point of the replacement. Software emulation of an ARM core on a 4 GHz Pentium is hardly an alternative to buying the real thing, though... I also find it hard to believe that building a product competitive to an ARM is possible using a description of the instruction set alone. That said, I agree with Paul that lobbying ARM to change their license is probably a better route to go. I believe software emulators like qemu are really in ARMs best interest since they support ARM development and thereby increase the availability of software for ARM cores. - Wolfgang Disclaimer: The views stated above are entirely mine, and do not necessarily reflect the views of my employer. Paul wrote on 30.03.2006 00:01:41: I could understand a claim if someone acquired ARM's documentation under an agreement to not produce an emulator. That's exactly where the restriction comes from. Theoretically it may be possible to reverse engineer a good proportion of ARMv6 from other sources (eg. gcc). However if that were done it would mean anyone with access to the real ARM documentation (i.e. me and probably anyone else with any professional/commercial interest in ARM emulation) would be unable to contribute to qemu. And if there is a possibility of that - in which countries do they have any weight? Dare I suggest encouraging the development of patches they don't like to countries where they have no legal weight? I don't think that's particularly helpful or practical suggestion. Better would be to lobby ARM to allow open source emulators. I'd like to use ARM hardware for big project, but qemu doesn't support ARMv7 so I'm thinking of using PowerPC instead is a particularly good argument ;-) Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Wolfgang Schildbach, Senior Research Engineer Coding Technologies GmbH ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Missing ARMv6 instructions?
Hello list, Running an ARM application in user mode emulation (qemu CVS version of 3-15-2006), my code crashes at an SMMUL instruction (this is part of the ARMv6 instruction set). A brief glance at translate.c and op.c seems to suggest that qemu does not emulate that instruction (yet). Before I dig any deeper, could somebody in the know (Paul?) confirm or reject this suspicion? Thanks much, -- Wolfgang Schildbach, Senior Research Engineer Coding Technologies GmbH ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Missing ARMv6 instructions?
Thanks, Paul. That explains it... I find it strange that ARM would restrict emulation of their architecture -- that could hardly pose a threat to their business, I would say. Anyhow, thanks for the note. - Wolfgang Paul Brook [EMAIL PROTECTED] wrote on 29.03.2006 16:39:12: On Wednesday 29 March 2006 13:33, Wolfgang Schildbach wrote: Hello list, Running an ARM application in user mode emulation (qemu CVS version of 3-15-2006), my code crashes at an SMMUL instruction (this is part of the ARMv6 instruction set). A brief glance at translate.c and op.c seems to suggest that qemu does not emulate that instruction (yet). Before I dig any deeper, could somebody in the know (Paul?) confirm or reject this suspicion? qemu cvs only supports ARMv5TE. The ARMv6 architecture is released under a more restrictive licence than ARMv5. The Arm licencing department have explicitly prohibited the distribution of open source ARMv6/v7 emulators. We're trying to get this restriction lifted, but so far to no avail. Paul -- Wolfgang Schildbach, Senior Research Engineer Coding Technologies GmbH ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Problems bringing up network in qemu-system-arm
Thanks much! I have now successfully built a kernel that runs on qemu, and detects the smc91x. I used the 2.6.14 kernel sources from kernel.org, modified with the patch available at the ARM website (http://www.arm.com/linux/linux_download.html). After I discovered /proc/config.gz (very useful!), I used that to model my config. - Wolfgang Paul Brook [EMAIL PROTECTED] wrote on 05.01.2006 18:34:49: On Thursday 05 January 2006 13:59, Wolfgang Schildbach wrote: Indeed at bootup time the kernel does not appear to detect the smc91 network card. I'll try to build my own kernel then. For the kernel at the qemu website, did you use the patch-2.6.14-arm1 patch available at the ARM website? I used vanilla kernel.org, probably 2.6.14. Which config options did you use -- can you post the config file? Config attached. Paul [attachment config.qemu.gz deleted by Wolfgang Schildbach/nbg/CodingTechnologies] -- Wolfgang Schildbach, Senior Research Engineer Coding Technologies GmbH ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Problems bringing up network in qemu-system-arm
Indeed at bootup time the kernel does not appear to detect the smc91 network card. I'll try to build my own kernel then. For the kernel at the qemu website, did you use the patch-2.6.14-arm1 patch available at the ARM website? Which config options did you use -- can you post the config file? Thanks much, - Wolfgang Paul Brook [EMAIL PROTECTED] wrote on 04.01.2006 22:30:56: http://lists.gnu.org/archive/html/qemu-devel/2005-12/msg00137.html), it should be possible to set up a network, user-mode or TUN/TAP. However, I fail to see the light as to how to bring the correct interface up on the guest system (arm-linux). ifconfig shows two devices, lo and dummy0, but nothing that would point to a smc91 being detected or used. This is independent from whether I try -net tap or -net user. Probably your kernel doesn't have the right driver. Looks like the image on the qemu website doesn't include the NIC driver. Paul -- Wolfgang Schildbach, Senior Research Engineer Coding Technologies GmbH ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Problems bringing up network in qemu-system-arm
Hi everyone, I am using the current CVS (HEAD) version of qemu running on x86 linux, and am using it to emulate an ARM on the integrator board, running arm-linux, using arm-test-0.1.tar.gz. From what I've read in this list ( http://lists.gnu.org/archive/html/qemu-devel/2005-12/msg00137.html), it should be possible to set up a network, user-mode or TUN/TAP. However, I fail to see the light as to how to bring the correct interface up on the guest system (arm-linux). ifconfig shows two devices, lo and dummy0, but nothing that would point to a smc91 being detected or used. This is independent from whether I try -net tap or -net user. 1) Is the network/smc91x support finished enough to be useable? 2) If so, what is the magic bullet? Any boot options that I need to give to the kernel? (BTW, I am calling the emulation as qemu-system-arm -kernel integratorcp.zImage -initrd arm_root.imfg -nographic -net user ) Thanks much for any help, Wolfgang -- Wolfgang Schildbach, Senior Research Engineer Coding Technologies GmbH ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
