[Qemu-devel] Unable to Run Gprof Successfully on QEMU
I'd appreciate any input on how to run gprof successfully on qemu. I'm new to gprof and am probably missing some steps. I successfully ran gprof on a sorting program available online, then I attempted to run gprof on qemu. Here are the steps I take: I'm trying to run gprof on qemu, but am unsuccessful. my os is linux, my qemu version is 0.8.2. I configure qemu with the options "configure --prefix=/install_path --enable-gprof. Then I make and make install. I run qemu successfully using the options /install_path/qemu -hda diskimage.img -m 256 which results in the gmon.out file. My run of qemu involved starting the image (virtual linux OS), running a few simple commands and shutting the image down. Finally, I run gprof /intsall_path/qemu gmon.out > result.txt which gives the error: gprof: file 'qemu' has no symbols' Are there any other configuration options required? Should the image be run with differently? thank you, atoosaah
[Qemu-devel] RFC: Code fetch optimisation
Here's a small patch that allow an optimisation for code fetch, at least
for RISC CPU targets, as suggested by Fabrice Bellard.
The main idea is that a translated block is never to span over a page
boundary. As the tb_find_slow routine already gets the physical address
of the page of code to be translated, the code translator could then
fetch the code using raw host memory accesses instead of doing it
through the softmmu routines.
This patch could also be adapted to RISC CPU targets, with care for the
last instruction of a page. For now, I did implement it for alpha, arm,
mips, PowerPC and SH4.
I don't actually know if the optimsation would bring a sensible speed
gain or if it will be absolutelly marginal.
Please comment.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
Index: cpu-exec.c
===
RCS file: /sources/qemu/qemu/cpu-exec.c,v
retrieving revision 1.119
diff -u -d -d -p -r1.119 cpu-exec.c
--- cpu-exec.c 8 Oct 2007 13:16:13 - 1.119
+++ cpu-exec.c 12 Oct 2007 07:14:43 -
@@ -133,6 +133,7 @@ static TranslationBlock *tb_find_slow(ta
tb->tc_ptr = tc_ptr;
tb->cs_base = cs_base;
tb->flags = flags;
+tb->page_addr[0] = phys_page1;
cpu_gen_code(env, tb, CODE_GEN_MAX_SIZE, &code_gen_size);
code_gen_ptr = (void *)(((unsigned long)code_gen_ptr + code_gen_size + CODE_GEN_ALIGN - 1) & ~(CODE_GEN_ALIGN - 1));
Index: target-alpha/translate.c
===
RCS file: /sources/qemu/qemu/target-alpha/translate.c,v
retrieving revision 1.5
diff -u -d -d -p -r1.5 translate.c
--- target-alpha/translate.c 16 Sep 2007 21:08:01 - 1.5
+++ target-alpha/translate.c 12 Oct 2007 07:14:47 -
@@ -1966,12 +1966,15 @@ int gen_intermediate_code_internal (CPUS
#endif
DisasContext ctx, *ctxp = &ctx;
target_ulong pc_start;
+unsigned long phys_pc;
uint32_t insn;
uint16_t *gen_opc_end;
int j, lj = -1;
int ret;
pc_start = tb->pc;
+phys_pc = (unsigned long)phys_ram_base + tb->page_addr[0] +
+(pc_start & ~TARGET_PAGE_MASK);
gen_opc_ptr = gen_opc_buf;
gen_opc_end = gen_opc_buf + OPC_MAX_SIZE;
gen_opparam_ptr = gen_opparam_buf;
@@ -2010,7 +2013,7 @@ int gen_intermediate_code_internal (CPUS
ctx.pc, ctx.mem_idx);
}
#endif
-insn = ldl_code(ctx.pc);
+insn = ldl_raw(phys_pc);
#if defined ALPHA_DEBUG_DISAS
insn_count++;
if (logfile != NULL) {
@@ -2018,6 +2021,7 @@ int gen_intermediate_code_internal (CPUS
}
#endif
ctx.pc += 4;
+phys_pc += 4;
ret = translate_one(ctxp, insn);
if (ret != 0)
break;
Index: target-arm/translate.c
===
RCS file: /sources/qemu/qemu/target-arm/translate.c,v
retrieving revision 1.57
diff -u -d -d -p -r1.57 translate.c
--- target-arm/translate.c 17 Sep 2007 08:09:51 - 1.57
+++ target-arm/translate.c 12 Oct 2007 07:14:47 -
@@ -38,6 +38,7 @@
/* internal defines */
typedef struct DisasContext {
target_ulong pc;
+unsigned long phys_pc;
int is_jmp;
/* Nonzero if this instruction has been conditionally skipped. */
int condjmp;
@@ -2206,8 +2207,9 @@ static void disas_arm_insn(CPUState * en
{
unsigned int cond, insn, val, op1, i, shift, rm, rs, rn, rd, sh;
-insn = ldl_code(s->pc);
+insn = ldl_raw(s->phys_pc);
s->pc += 4;
+s->phys_pc += 4;
cond = insn >> 28;
if (cond == 0xf){
@@ -2971,8 +2973,9 @@ static void disas_thumb_insn(DisasContex
int32_t offset;
int i;
-insn = lduw_code(s->pc);
+insn = lduw_raw(s->phys_pc);
s->pc += 2;
+s->phys_pc += 2;
switch (insn >> 12) {
case 0: case 1:
@@ -3494,7 +3497,7 @@ static void disas_thumb_insn(DisasContex
break;
}
offset = ((int32_t)insn << 21) >> 10;
-insn = lduw_code(s->pc);
+insn = lduw_raw(s->phys_pc);
offset |= insn & 0x7ff;
val = (uint32_t)s->pc + 2;
@@ -3544,6 +3547,8 @@ static inline int gen_intermediate_code_
dc->is_jmp = DISAS_NEXT;
dc->pc = pc_start;
+dc->phys_pc = (unsigned long)phys_ram_base + tb->page_addr[0] +
+(pc_start & ~TARGET_PAGE_MASK);
dc->singlestep_enabled = env->singlestep_enabled;
dc->condjmp = 0;
dc->thumb = env->thumb;
Index: target-mips/translate.c
===
RCS file: /sources/qemu/qemu/target-mips/translate.c,v
retrieving revision 1.106
diff -u -d -d -p -r1.106 translate.c
--- target-mips/translate.c 9 Oct 2007 03:39:58 - 1.106
+++ target-mips/translate.c 12 Oct 2007 07:14:48 -
@@ -6483,6 +6483,7 @@ gen_intermediate_code_internal (CPUState
{
DisasContext ctx;
target_ulong pc_start;
+unsigned long phys_pc;
uint16_t *gen_opc_end;
int j, lj = -1;
@@ -6490,6
Re: [Qemu-devel] Unable to Run Gprof Successfully on QEMU
On Fri, 2007-10-12 at 01:00 -0700, Atoosaah S wrote: > I'd appreciate any input on how to run gprof successfully on qemu. I'm > new to gprof and am probably missing some steps. I successfully ran > gprof on a sorting program available online, then I attempted to run > gprof on qemu. > > Here are the steps I take: > > I'm trying to run gprof on qemu, but am unsuccessful. my os is linux, > my qemu version is 0.8.2. I configure qemu with the options "configure > --prefix=/install_path --enable-gprof. Then I make and make install. I > run qemu successfully using the options /install_path/qemu -hda > diskimage.img -m 256 which results in the gmon.out file. My run of > qemu involved starting the image (virtual linux OS), running a few > simple commands and shutting the image down. > > Finally, I run gprof /intsall_path/qemu gmon.out > result.txt which > gives the error: gprof: file 'qemu' has no symbols' > > Are there any other configuration options required? Should the image > be run with differently? You need a qemu executable with debugging symbols. Distributed versions are usually stripped, which means the debug symbols are not present anymore. A way to get the debug symbol is to fetch the source and recompile it... -- J. Mayer <[EMAIL PROTECTED]> Never organized
[Qemu-devel] RFC: avoid #ifdef for target cpu list - for x86, too.
This seems like a good excuse to send my suggested -cpu option for the
x86 target. It is just like my previous "take 4", but fits to the newly
unified cpu_list.
Index: hw/pc.c
===
RCS file: /sources/qemu/qemu/hw/pc.c,v
retrieving revision 1.87
diff -u -p -r1.87 pc.c
--- hw/pc.c 9 Oct 2007 03:08:56 - 1.87
+++ hw/pc.c 12 Oct 2007 08:50:22 -
@@ -667,7 +667,7 @@ static void pc_init1(int ram_size, int v
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename,
- int pci_enabled)
+ int pci_enabled, const char *cpu_model)
{
char buf[1024];
int ret, linux_boot, i;
@@ -683,6 +683,13 @@ static void pc_init1(int ram_size, int v
linux_boot = (kernel_filename != NULL);
/* init CPUs */
+if (cpu_model == NULL)
+cpu_model = "basic";
+
+if (x86_find_cpu_by_name(cpu_model)) {
+fprintf(stderr, "Unable to find x86 CPU definition\n");
+exit(1);
+}
for(i = 0; i < smp_cpus; i++) {
env = cpu_init();
if (i != 0)
@@ -951,7 +958,7 @@ static void pc_init_pci(int ram_size, in
pc_init1(ram_size, vga_ram_size, boot_device,
ds, fd_filename, snapshot,
kernel_filename, kernel_cmdline,
- initrd_filename, 1);
+ initrd_filename, 1, cpu_model);
}
static void pc_init_isa(int ram_size, int vga_ram_size, int boot_device,
@@ -965,7 +972,7 @@ static void pc_init_isa(int ram_size, in
pc_init1(ram_size, vga_ram_size, boot_device,
ds, fd_filename, snapshot,
kernel_filename, kernel_cmdline,
- initrd_filename, 0);
+ initrd_filename, 0, cpu_model);
}
QEMUMachine pc_machine = {
Index: target-i386/cpu.h
===
RCS file: /sources/qemu/qemu/target-i386/cpu.h,v
retrieving revision 1.50
diff -u -p -r1.50 cpu.h
--- target-i386/cpu.h 27 Sep 2007 16:44:31 - 1.50
+++ target-i386/cpu.h 12 Oct 2007 08:50:22 -
@@ -274,23 +274,56 @@
#define CPUID_CMOV (1 << 15)
#define CPUID_PAT (1 << 16)
#define CPUID_PSE36 (1 << 17)
+#define CPUID_PN (1 << 18)
#define CPUID_CLFLUSH (1 << 19)
-/* ... */
+#define CPUID_DTS (1 << 21)
+#define CPUID_ACPI (1 << 22)
#define CPUID_MMX (1 << 23)
#define CPUID_FXSR (1 << 24)
#define CPUID_SSE (1 << 25)
#define CPUID_SSE2 (1 << 26)
+#define CPUID_SS (1 << 27)
+#define CPUID_HT (1 << 28)
+#define CPUID_TM (1 << 29)
+#define CPUID_IA64 (1 << 30)
+#define CPUID_PBE (1 << 31)
#define CPUID_EXT_SSE3 (1 << 0)
#define CPUID_EXT_MONITOR (1 << 3)
+#define CPUID_EXT_DSCPL(1 << 4)
+#define CPUID_EXT_VMX (1 << 5)
+#define CPUID_EXT_SMX (1 << 6)
+#define CPUID_EXT_EST (1 << 7)
+#define CPUID_EXT_TM2 (1 << 8)
+#define CPUID_EXT_SSSE3(1 << 9)
+#define CPUID_EXT_CID (1 << 10)
#define CPUID_EXT_CX16 (1 << 13)
+#define CPUID_EXT_XTPR (1 << 14)
+#define CPUID_EXT_DCA (1 << 17)
+#define CPUID_EXT_POPCNT (1 << 22)
#define CPUID_EXT2_SYSCALL (1 << 11)
+#define CPUID_EXT2_MP (1 << 19)
#define CPUID_EXT2_NX (1 << 20)
+#define CPUID_EXT2_MMXEXT (1 << 22)
#define CPUID_EXT2_FFXSR (1 << 25)
+#define CPUID_EXT2_PDPE1GB (1 << 26)
+#define CPUID_EXT2_RDTSCP (1 << 27)
#define CPUID_EXT2_LM (1 << 29)
+#define CPUID_EXT2_3DNOWEXT (1 << 30)
+#define CPUID_EXT2_3DNOW (1 << 31)
+#define CPUID_EXT3_LAHF_LM (1 << 0)
+#define CPUID_EXT3_CMP_LEG (1 << 1)
#define CPUID_EXT3_SVM (1 << 2)
+#define CPUID_EXT3_EXTAPIC (1 << 3)
+#define CPUID_EXT3_CR8LEG (1 << 4)
+#define CPUID_EXT3_ABM (1 << 5)
+#define CPUID_EXT3_SSE4A (1 << 6)
+#define CPUID_EXT3_MISALIGNSSE (1 << 7)
+#define CPUID_EXT3_3DNOWPREFETCH (1 << 8)
+#define CPUID_EXT3_OSVW(1 << 9)
+#define CPUID_EXT3_IBS (1 << 10)
#define EXCP00_DIVZ0
#define EXCP01_SSTP1
@@ -564,6 +597,9 @@ typedef struct CPUX86State {
CPUX86State *cpu_x86_init(void);
int cpu_x86_exec(CPUX86State *s);
void cpu_x86_close(CPUX86State *s);
+int x86_find_cpu_by_name (const unsigned char *name);
+void x86_cpu_list (FILE *f, int (*cpu_fprintf)(FILE *f, const char *fmt,
+ ...));
int cpu_get_pic_interrupt(CPUX86State *s);
/* MSDOS compatibility mode FPU exception support */
void cpu_set_ferr(CPUX86State *s);
@@ -687,6 +723,7 @@ static inline int cpu_get_time_fast(void
#define cpu_exec cpu_x86_exec
#define cpu_gen_code cpu_x86_gen_code
#define cpu_signal_handler cpu_x86_signal_handler
+#define cpu_list x86_cpu_list
#include "cpu-all.h"
Index: target-i386/helper2.c
===
RCS file: /sources/qemu/qemu/target-i386/helper2.c,v
retrieving revision 1.52
diff -u -
Re: [Qemu-devel] RFC: Code fetch optimisation
On 10/12/07, J. Mayer <[EMAIL PROTECTED]> wrote: > Here's a small patch that allow an optimisation for code fetch, at least > for RISC CPU targets, as suggested by Fabrice Bellard. > The main idea is that a translated block is never to span over a page > boundary. As the tb_find_slow routine already gets the physical address > of the page of code to be translated, the code translator could then > fetch the code using raw host memory accesses instead of doing it > through the softmmu routines. > This patch could also be adapted to RISC CPU targets, with care for the > last instruction of a page. For now, I did implement it for alpha, arm, > mips, PowerPC and SH4. > I don't actually know if the optimsation would bring a sensible speed > gain or if it will be absolutelly marginal. > > Please comment. This will not work correctly for execution of MMIO registers, but maybe that won't work on real hardware either. Who cares. Wouldn't it be even more efficient if you moved most of this calculation: +phys_pc = (unsigned long)phys_ram_base + tb->page_addr[0] + +(pc_start & ~TARGET_PAGE_MASK); here: +tb->page_addr[0] = phys_page1; ?
Re: [Qemu-devel] Unable to Run Gprof Successfully on QEMU
How do I enable debugging? I checked the configure file and I do not see any options for compiling with debugging, i.e. there is no --enable-debug option. I see that the "default parameters" section of the configure file sets: gdbstub="yes" but other than that i do not see any other reference to debugging. Also, I am working with qemu source code, which I configure, make, make install before every run. Thank you again. On 10/12/07, J. Mayer <[EMAIL PROTECTED]> wrote: > > On Fri, 2007-10-12 at 01:00 -0700, Atoosaah S wrote: > > I'd appreciate any input on how to run gprof successfully on qemu. I'm > > new to gprof and am probably missing some steps. I successfully ran > > gprof on a sorting program available online, then I attempted to run > > gprof on qemu. > > > > Here are the steps I take: > > > > I'm trying to run gprof on qemu, but am unsuccessful. my os is linux, > > my qemu version is 0.8.2. I configure qemu with the options "configure > > --prefix=/install_path --enable-gprof. Then I make and make install. I > > run qemu successfully using the options /install_path/qemu -hda > > diskimage.img -m 256 which results in the gmon.out file. My run of > > qemu involved starting the image (virtual linux OS), running a few > > simple commands and shutting the image down. > > > > Finally, I run gprof /intsall_path/qemu gmon.out > result.txt which > > gives the error: gprof: file 'qemu' has no symbols' > > > > Are there any other configuration options required? Should the image > > be run with differently? > > You need a qemu executable with debugging symbols. Distributed versions > are usually stripped, which means the debug symbols are not present > anymore. > A way to get the debug symbol is to fetch the source and recompile it... > > -- > J. Mayer <[EMAIL PROTECTED]> > Never organized > >
Re: [Qemu-devel] RFC: fix run of 32 bits Linux executables on 64 bits targets
Blue Swirl wrote:
[snip]
> Index: qemu/linux-user/mipsn32/syscall.h
> ===
> --- qemu.orig/linux-user/mipsn32/syscall.h2007-10-11 19:17:14.0
> +
> +++ qemu/linux-user/mipsn32/syscall.h 2007-10-11 19:17:46.0 +
> @@ -4,15 +4,15 @@
>
> struct target_pt_regs {
> /* Saved main processor registers. */
> - target_ulong regs[32];
> + abi_ulong regs[32];
>
> /* Saved special registers. */
> - target_ulong cp0_status;
> - target_ulong lo;
> - target_ulong hi;
> - target_ulong cp0_badvaddr;
> - target_ulong cp0_cause;
> - target_ulong cp0_epc;
> + abi_ulong cp0_status;
> + abi_ulong lo;
> + abi_ulong hi;
> + abi_ulong cp0_badvaddr;
> + abi_ulong cp0_cause;
> + abi_ulong cp0_epc;
> };
This is broken. n32 has 64bit wide registers (and uses them for long long).
> /* Target errno definitions taken from asm-mips/errno.h */
> Index: qemu/linux-user/mipsn32/target_signal.h
> ===
> --- qemu.orig/linux-user/mipsn32/target_signal.h 2007-10-11
> 19:17:14.0 +
> +++ qemu/linux-user/mipsn32/target_signal.h 2007-10-11 19:17:46.0
> +
> @@ -21,7 +21,7 @@
> #define TARGET_MINSIGSTKSZ2048
> #define TARGET_SIGSTKSZ 8192
>
> -static inline target_ulong get_sp_from_cpustate(CPUMIPSState *state)
> +static inline abi_ulong get_sp_from_cpustate(CPUMIPSState *state)
> {
> return state->gpr[29][state->current_tc];
> }
Same problem.
[snip]
> Index: qemu/linux-user/signal.c
> ===
> --- qemu.orig/linux-user/signal.c 2007-10-11 19:17:13.0 +
> +++ qemu/linux-user/signal.c 2007-10-12 15:58:08.0 +
[snip]
> @@ -2013,12 +2013,12 @@
> uint32_t sc_dsp; /* dsp status, was sc_ssflags */
> uint64_t sc_mdhi;
> uint64_t sc_mdlo;
> -target_ulong sc_hi1; /* Was sc_cause */
> -target_ulong sc_lo1; /* Was sc_badvaddr */
> -target_ulong sc_hi2; /* Was sc_sigset[4] */
> -target_ulong sc_lo2;
> -target_ulong sc_hi3;
> -target_ulong sc_lo3;
> +abi_ulong sc_hi1; /* Was sc_cause */
> +abi_ulong sc_lo1; /* Was sc_badvaddr */
> +abi_ulong sc_hi2; /* Was sc_sigset[4] */
> +abi_ulong sc_lo2;
> +abi_ulong sc_hi3;
> +abi_ulong sc_lo3;
> };
Likewise. When comparing with Linux kernel headers keep in mind that
a 64bit MIPS kernel is always n64, so the data types used on the kernel
side don't match the n32 userland ones.
I'm probably just too used to it to find it confusing, taking the
glibc headers as a guideline might be easier for you. :-)
[snip]
> Index: qemu/linux-user/syscall_defs.h
> ===
> --- qemu.orig/linux-user/syscall_defs.h 2007-10-11 19:17:13.0
> +
> +++ qemu/linux-user/syscall_defs.h2007-10-12 16:08:10.0 +
[snip]
> @@ -1272,7 +1272,7 @@
> unsigned intst_dev;
> unsigned intst_pad0[3]; /* Reserved for st_dev expansion */
>
> - target_ulongst_ino;
> + abi_ulong st_ino;
>
> unsigned int st_mode;
> unsigned int st_nlink;
Another one. I leave out a few more instances which also break n32.
[snip]
> Index: qemu/configure
> ===
> --- qemu.orig/configure 2007-10-11 19:17:14.0 +
> +++ qemu/configure2007-10-12 15:38:15.0 +
> @@ -504,7 +504,7 @@
> fi
> # the following are Linux specific
> if [ "$linux_user" = "yes" ] ; then
> -target_list="i386-linux-user arm-linux-user armeb-linux-user
> sparc-linux-user ppc-linux-user mips-linux-user mipsel-linux-user
> m68k-linux-user alpha-linux-user ppc64-linux-user sh4-linux-user
> cris-linux-user $target_list"
> +target_list="i386-linux-user arm-linux-user armeb-linux-user
> sparc-linux-user sparc64-linux-user sparc32plus-linux-user ppc-linux-user
> mips-linux-user mipsel-linux-user m68k-linux-user alpha-linux-user
> ppc64-linux-user sh4-linux-user cris-linux-user $target_list"
> fi
> # the following are Darwin specific
> if [ "$darwin_user" = "yes" ] ; then
> @@ -933,6 +933,7 @@
> [ "$target_cpu" = "armeb" ] && target_bigendian=yes
> [ "$target_cpu" = "sparc" ] && target_bigendian=yes
> [ "$target_cpu" = "sparc64" ] && target_bigendian=yes
> +[ "$target_cpu" = "sparc32plus" ] && target_bigendian=yes
> [ "$target_cpu" = "ppc" ] && target_bigendian=yes
> [ "$target_cpu" = "ppc64" ] && target_bigendian=yes
> [ "$target_cpu" = "ppcemb" ] && target_bigendian=yes
> @@ -1005,6 +1006,7 @@
>
> if test "$target_cpu" = "i386" ; then
>echo "TARGET_ARCH=i386" >> $config_mak
> + echo "TARGET_ABI_DIR=i386" >> $config
Re: [Qemu-devel] RFC: Code fetch optimisation
Blue Swirl wrote: On 10/12/07, J. Mayer <[EMAIL PROTECTED]> wrote: Here's a small patch that allow an optimisation for code fetch, at least for RISC CPU targets, as suggested by Fabrice Bellard. The main idea is that a translated block is never to span over a page boundary. As the tb_find_slow routine already gets the physical address of the page of code to be translated, the code translator could then fetch the code using raw host memory accesses instead of doing it through the softmmu routines. This patch could also be adapted to RISC CPU targets, with care for the last instruction of a page. For now, I did implement it for alpha, arm, mips, PowerPC and SH4. I don't actually know if the optimsation would bring a sensible speed gain or if it will be absolutelly marginal. Please comment. This will not work correctly for execution of MMIO registers, but maybe that won't work on real hardware either. Who cares. It can never happen because QEMU currently does not support it (see get_phys_addr_code()). I started to implement it but never really finished it (real hardware can do it so QEMU should support it). The idea consist in using a reserved ram page to store the code. Another point is that the TB must be discarded once executed as the MMIO data can change. Regards, Fabrice.
Re: [Qemu-devel] RFC: Code fetch optimisation
Blue Swirl wrote: On 10/12/07, J. Mayer <[EMAIL PROTECTED]> wrote: Here's a small patch that allow an optimisation for code fetch, at least for RISC CPU targets, as suggested by Fabrice Bellard. The main idea is that a translated block is never to span over a page boundary. As the tb_find_slow routine already gets the physical address of the page of code to be translated, the code translator could then fetch the code using raw host memory accesses instead of doing it through the softmmu routines. This patch could also be adapted to RISC CPU targets, with care for the last instruction of a page. For now, I did implement it for alpha, arm, mips, PowerPC and SH4. I don't actually know if the optimsation would bring a sensible speed gain or if it will be absolutelly marginal. Please comment. This will not work correctly for execution of MMIO registers, but maybe that won't work on real hardware either. Who cares. It can never happen because QEMU currently does not support it (see get_phys_addr_code()). I started to implement it but never really finished it (real hardware can do it so QEMU should support it). The idea consist in using a reserved ram page to store the code. Another point is that the TB must be discarded once executed as the MMIO data can change. Regards, Fabrice.
Re: [Qemu-devel] What happened with NPTL/TLS support?
On Fri, 2007-10-12 at 18:12 +0300, Felipe Contreras wrote: > Hi, > > When I try to use codesourcery's toolchain arm-2006q3-27 in my Fedora > 7 box I always have the following issue: > > qemu: Unsupported syscall: 983045 Yep, I've seen that before. > I guess it's a problem of NPTL incompatibility. Anyway, the patch that > Paul Brook sent a while ago solves it [1]. > > I wonder if it can be integrated or what would be the right way to > solve this issue. Am I the only one having it? > > Best regards. > > [1] http://lists.gnu.org/archive/html/qemu-devel/2005-08/msg00128.html I've been using this patch, as well as other NPTL/TLS patches as well as some of my own work and have a set of patches for NPTL/TLS that works reasonably well for arm and i386. The patches don't apply cleanly to CVS current, but I'm more than happy to rework them so that they will if someone is serious about getting NPTL/TLS/futex stuff working for linux-user. I haven't submitted my patches because I kept expecting the other patches to be accepted.
Re: [Qemu-devel] [PATCH] syscall_target_errno.patch
On Wed, 2007-10-10 at 21:38 -0600, Thayne Harbaugh wrote:
> I have noticed that many functions in syscall.c return a *host* errno
> when a *target* errno should be return. At the same time, there are
> several places in syscall.c:do_syscall() that immediately return an
> errno rather than setting the return value and exiting through the
> syscall return value reporting at the end of do_syscall().
>
> This patch addresses both of those problems at once rather than touching
> the exact same errno return lines twice in do_syscall().
The patch is better with parenthesis around the arguments of the
return_err() macro:
#define return_err(err) do { ret = -(err); goto fail; } while(0)
Re: [Qemu-devel] RFC: Code fetch optimisation
On Fri, 2007-10-12 at 18:21 +0300, Blue Swirl wrote:
> On 10/12/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > Here's a small patch that allow an optimisation for code fetch, at least
> > for RISC CPU targets, as suggested by Fabrice Bellard.
> > The main idea is that a translated block is never to span over a page
> > boundary. As the tb_find_slow routine already gets the physical address
> > of the page of code to be translated, the code translator could then
> > fetch the code using raw host memory accesses instead of doing it
> > through the softmmu routines.
> > This patch could also be adapted to RISC CPU targets, with care for the
> > last instruction of a page. For now, I did implement it for alpha, arm,
> > mips, PowerPC and SH4.
> > I don't actually know if the optimsation would bring a sensible speed
> > gain or if it will be absolutelly marginal.
> >
> > Please comment.
>
> This will not work correctly for execution of MMIO registers, but
> maybe that won't work on real hardware either. Who cares.
I wonder if this is important or not... But maybe, when retrieving the
physical address we could check if it is inside ROM/RAM or an I/O area
and in the last case do not give the phys_addr information to the
translator. In that case, it would go on using the ldxx_code. I guess if
we want to do that, a set of helpers would be appreciated to avoid
adding code like:
if (phys_pc == 0)
opc = ldul_code(virt_pc)
else
opc = ldul_raw(phys_pc)
everywhere... I could also add another check so this set of macro would
automatically use ldxx_code if we reach a page boundary, which would
then make easy to use this optimisation for CISC/VLE architectures too.
I'm not sure of the proper solution to allow executing code from mmio
devices. But adding specific accessors to handle the CISC/VLE case is to
be done. Something like this might be OK:
static inline target_ulong ldl_code_p(unsigned long *start_pc, unsigned
long *phys_pc, target_ulong *virt_pc)
{
target_ulong opc;
if ((*start_pc ^ *phys_pc) & TARGET_PAGE_MASK) {
/* slow path that may raise an exception */
opc = ldul_code(virt_pc);
*start_pc = phys_pc; /* Avoid softmmu call on next load */
} else {
/* Optimized path */
opc = ldul_raw(phys_pc);
}
*phys_pc += sizeof(target_ulong);
*virt_pc += sizeof(target_ulong);
return opc;
}
Of course, 8, 16 and 64 (why not ?) bits accessors would be also
provided the same way.
> Wouldn't it be even more efficient if you moved most of this calculation:
> +phys_pc = (unsigned long)phys_ram_base + tb->page_addr[0] +
> +(pc_start & ~TARGET_PAGE_MASK);
> here:
> +tb->page_addr[0] = phys_page1;
> ?
Maybe. I choosed to do this way because it's exactly the same assignment
that is done in tb_link_phys after the gen_intermediate_code function
returns. I then though that the safer thing to do was to store the same
value so, whatever might happen, the value in the tb structure is never
inconsistent. I also guess that it's not so important as the tb is not
linked at this point...
[Qemu-devel] Help to build qemu to a host arm
Could anyone give me a tip in how to compile qemu to a host arm. I have a ARM machine running debian 4.0 , i need to run a very small i386 application on this machine but i can not compile qeumu on it. I keep getting errors. # ./configure --target-list=i386-user WARNING: "gcc" looks like gcc 4.x Looking for gcc 3.x Found "gcc-3.3" Install prefix/usr/local BIOS directory/usr/local/share/qemu binary directory /usr/local/bin Manual directory /usr/local/share/man ELF interp prefix /usr/gnemul/qemu-%M Source path /root/qemu-0.9.0 C compilergcc-3.3 Host C compiler gcc make make install install host CPU armv4l host big endian no target list i386-user gprof enabled no profiler no static build no SDL support no mingw32 support no Adlib support no CoreAudio support no ALSA support no DSound supportno FMOD support no kqemu support no Documentation no # make gcc-3.3 -DQEMU_TOOL -Wall -O2 -g -fno-strict-aliasing -I. -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -g -o qemu-img qemu-img.c cutils.c block.c block-raw.c block-cow.c block-qcow.c aes.c block-vmdk.c block-cloop.c block-dmg.c block-bochs.c block-vpc.c block-vvfat.c block-qcow2.c -lz -lrt gcc -Wall -O2 -g -fno-strict-aliasing -I. -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -o dyngen dyngen.c make -C i386-user all make[1]: Entering directory `/root/qemu-0.9.0/i386-user' gcc-3.3 -Wall -O2 -g -fno-strict-aliasing -I. -I.. -I/root/qemu-0.9.0/target-i386 -I/root/qemu-0.9.0 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/root/qemu-0.9.0/fpu -DHAS_AUDIO -I/root/qemu-0.9.0/slirp -c -o exec.o/root/qemu- 0.9.0/exec.c /root/qemu-0.9.0/exec.c:38:18: qemu.h: No such file or directory /root/qemu-0.9.0/exec.c: In function `cpu_physical_memory_rw': /root/qemu-0.9.0/exec.c:2004: warning: implicit declaration of function `lock_user' /root/qemu-0.9.0/exec.c:2004: warning: assignment makes pointer from integer without a cast /root/qemu-0.9.0/exec.c:2006: warning: implicit declaration of function `unlock_user' /root/qemu-0.9.0/exec.c:2010: warning: assignment makes pointer from integer without a cast make[1]: *** [exec.o] Error 1 make[1]: Leaving directory `/root/qemu-0.9.0/i386-user' make: *** [subdir-i386-user] Error 2
Re: [Qemu-devel] Unable to Run Gprof Successfully on QEMU
That was it. I got it to work! Thanks so much for your help :-) On 10/12/07, Ben Taylor <[EMAIL PROTECTED]> wrote: > > > Atoosaah S <[EMAIL PROTECTED]> wrote: > > How do I enable debugging? > > > > I checked the configure file and I do not see any options for compiling > with > > debugging, i.e. there is no --enable-debug option. I see that the > "default > > parameters" section of the configure file sets: gdbstub="yes" but other > than > > that i do not see any other reference to debugging. > > > > Also, I am working with qemu source code, which I configure, make, make > > install before every run. > > then run the binary from the source tree, as it is not stripped. As part > of make install, the binaries are stripped. > > HTH > > > > > Thank you again. > > > > > > On 10/12/07, J. Mayer <[EMAIL PROTECTED]> wrote: > > > > > > On Fri, 2007-10-12 at 01:00 -0700, Atoosaah S wrote: > > > > I'd appreciate any input on how to run gprof successfully on qemu. > I'm > > > > new to gprof and am probably missing some steps. I successfully ran > > > > gprof on a sorting program available online, then I attempted to run > > > > gprof on qemu. > > > > > > > > Here are the steps I take: > > > > > > > > I'm trying to run gprof on qemu, but am unsuccessful. my os is > linux, > > > > my qemu version is 0.8.2. I configure qemu with the options > "configure > > > > --prefix=/install_path --enable-gprof. Then I make and make install. > I > > > > run qemu successfully using the options /install_path/qemu -hda > > > > diskimage.img -m 256 which results in the gmon.out file. My run of > > > > qemu involved starting the image (virtual linux OS), running a few > > > > simple commands and shutting the image down. > > > > > > > > Finally, I run gprof /intsall_path/qemu gmon.out > result.txt which > > > > gives the error: gprof: file 'qemu' has no symbols' > > > > > > > > Are there any other configuration options required? Should the image > > > > be run with differently? > > > > > > You need a qemu executable with debugging symbols. Distributed > versions > > > are usually stripped, which means the debug symbols are not present > > > anymore. > > > A way to get the debug symbol is to fetch the source and recompile > it... > > > > > > -- > > > J. Mayer <[EMAIL PROTECTED]> > > > Never organized > > > > > > > >
Re: [Qemu-devel] Unable to Run Gprof Successfully on QEMU
Atoosaah S <[EMAIL PROTECTED]> wrote: > How do I enable debugging? > > I checked the configure file and I do not see any options for compiling with > debugging, i.e. there is no --enable-debug option. I see that the "default > parameters" section of the configure file sets: gdbstub="yes" but other than > that i do not see any other reference to debugging. > > Also, I am working with qemu source code, which I configure, make, make > install before every run. then run the binary from the source tree, as it is not stripped. As part of make install, the binaries are stripped. HTH > > Thank you again. > > > On 10/12/07, J. Mayer <[EMAIL PROTECTED]> wrote: > > > > On Fri, 2007-10-12 at 01:00 -0700, Atoosaah S wrote: > > > I'd appreciate any input on how to run gprof successfully on qemu. I'm > > > new to gprof and am probably missing some steps. I successfully ran > > > gprof on a sorting program available online, then I attempted to run > > > gprof on qemu. > > > > > > Here are the steps I take: > > > > > > I'm trying to run gprof on qemu, but am unsuccessful. my os is linux, > > > my qemu version is 0.8.2. I configure qemu with the options "configure > > > --prefix=/install_path --enable-gprof. Then I make and make install. I > > > run qemu successfully using the options /install_path/qemu -hda > > > diskimage.img -m 256 which results in the gmon.out file. My run of > > > qemu involved starting the image (virtual linux OS), running a few > > > simple commands and shutting the image down. > > > > > > Finally, I run gprof /intsall_path/qemu gmon.out > result.txt which > > > gives the error: gprof: file 'qemu' has no symbols' > > > > > > Are there any other configuration options required? Should the image > > > be run with differently? > > > > You need a qemu executable with debugging symbols. Distributed versions > > are usually stripped, which means the debug symbols are not present > > anymore. > > A way to get the debug symbol is to fetch the source and recompile it... > > > > -- > > J. Mayer <[EMAIL PROTECTED]> > > Never organized > > > >
[Qemu-devel] What happened with NPTL/TLS support?
Hi, When I try to use codesourcery's toolchain arm-2006q3-27 in my Fedora 7 box I always have the following issue: qemu: Unsupported syscall: 983045 I guess it's a problem of NPTL incompatibility. Anyway, the patch that Paul Brook sent a while ago solves it [1]. I wonder if it can be integrated or what would be the right way to solve this issue. Am I the only one having it? Best regards. [1] http://lists.gnu.org/archive/html/qemu-devel/2005-08/msg00128.html -- Felipe Contreras
Re: [Qemu-devel] RFC: fix run of 32 bits Linux executables on 64 bits targets
Blue Swirl wrote:
> On 10/12/07, Thiemo Seufer <[EMAIL PROTECTED]> wrote:
> > Blue Swirl wrote:
> > [snip]
> > > Index: qemu/linux-user/mipsn32/syscall.h
> > > ===
> > > --- qemu.orig/linux-user/mipsn32/syscall.h2007-10-11
> > > 19:17:14.0 +
> > > +++ qemu/linux-user/mipsn32/syscall.h 2007-10-11 19:17:46.0 +
> > > @@ -4,15 +4,15 @@
> > >
> > > struct target_pt_regs {
> > > /* Saved main processor registers. */
> > > - target_ulong regs[32];
> > > + abi_ulong regs[32];
> > >
> > > /* Saved special registers. */
> > > - target_ulong cp0_status;
> > > - target_ulong lo;
> > > - target_ulong hi;
> > > - target_ulong cp0_badvaddr;
> > > - target_ulong cp0_cause;
> > > - target_ulong cp0_epc;
> > > + abi_ulong cp0_status;
> > > + abi_ulong lo;
> > > + abi_ulong hi;
> > > + abi_ulong cp0_badvaddr;
> > > + abi_ulong cp0_cause;
> > > + abi_ulong cp0_epc;
> > > };
> >
> > This is broken. n32 has 64bit wide registers (and uses them for long long).
>
> If target_ulong is 64 bits, then abi_ulong is 64 bits too and
> therefore correct. Unless you want to enable the ABI32 feature? It is
> only enabled for the new Sparc32plus and PPC targets for now.
>
> But I put the original target_ulongs back.
I probably should have written "looks broken" than "is broken".
In any case, having abi_ulong not matching the ABI's "unsigned long"
is even more confusing than target_ulong not matching the ABI's
"unsigned long".
Now that I think of it again I believe the ABI32 feature isn't usable
for mips. The ABI-mandated structures are too different.
Thiemo
[Fwd: Re: [Qemu-devel] RFC: Code fetch optimisation]
Forwarded Message
> From: Jocelyn Mayer <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED], qemu-devel@nongnu.org
> To: qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] RFC: Code fetch optimisation
> Date: Fri, 12 Oct 2007 20:24:44 +0200
>
> On Fri, 2007-10-12 at 18:21 +0300, Blue Swirl wrote:
> > On 10/12/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > > Here's a small patch that allow an optimisation for code fetch, at least
> > > for RISC CPU targets, as suggested by Fabrice Bellard.
> > > The main idea is that a translated block is never to span over a page
> > > boundary. As the tb_find_slow routine already gets the physical address
> > > of the page of code to be translated, the code translator could then
> > > fetch the code using raw host memory accesses instead of doing it
> > > through the softmmu routines.
> > > This patch could also be adapted to RISC CPU targets, with care for the
> > > last instruction of a page. For now, I did implement it for alpha, arm,
> > > mips, PowerPC and SH4.
> > > I don't actually know if the optimsation would bring a sensible speed
> > > gain or if it will be absolutelly marginal.
> > >
> > > Please comment.
> >
> > This will not work correctly for execution of MMIO registers, but
> > maybe that won't work on real hardware either. Who cares.
>
> I wonder if this is important or not... But maybe, when retrieving the
> physical address we could check if it is inside ROM/RAM or an I/O area
> and in the last case do not give the phys_addr information to the
> translator. In that case, it would go on using the ldxx_code. I guess if
> we want to do that, a set of helpers would be appreciated to avoid
> adding code like:
> if (phys_pc == 0)
> opc = ldul_code(virt_pc)
> else
> opc = ldul_raw(phys_pc)
> everywhere... I could also add another check so this set of macro would
> automatically use ldxx_code if we reach a page boundary, which would
> then make easy to use this optimisation for CISC/VLE architectures too.
>
> I'm not sure of the proper solution to allow executing code from mmio
> devices. But adding specific accessors to handle the CISC/VLE case is to
> be done.
[...]
I did update my patch following this way and it's now able to run x86
and PowerPC targets.
PowerPC is the easy case, x86 is maybe the worst... Well, I'm not really
sure of what I've done for Sparc, but other targets should be safe.
Please comment.
--
J. Mayer <[EMAIL PROTECTED]>
Never organized
Index: cpu-all.h
===
RCS file: /sources/qemu/qemu/cpu-all.h,v
retrieving revision 1.76
diff -u -d -d -p -r1.76 cpu-all.h
--- cpu-all.h 23 Sep 2007 15:28:03 - 1.76
+++ cpu-all.h 12 Oct 2007 22:53:37 -
@@ -646,6 +646,13 @@ static inline void stfq_be_p(void *ptr,
#define ldl_code(p) ldl_raw(p)
#define ldq_code(p) ldq_raw(p)
+#define ldub_code_p(sp, pp, p) ldub_raw(p)
+#define ldsb_code_p(sp, pp, p) ldsb_raw(p)
+#define lduw_code_p(sp, pp, p) lduw_raw(p)
+#define ldsw_code_p(sp, pp, p) ldsw_raw(p)
+#define ldl_code_p(sp, pp, p) ldl_raw(p)
+#define ldq_code_p(sp, pp, p) ldq_raw(p)
+
#define ldub_kernel(p) ldub_raw(p)
#define ldsb_kernel(p) ldsb_raw(p)
#define lduw_kernel(p) lduw_raw(p)
Index: cpu-exec.c
===
RCS file: /sources/qemu/qemu/cpu-exec.c,v
retrieving revision 1.119
diff -u -d -d -p -r1.119 cpu-exec.c
--- cpu-exec.c 8 Oct 2007 13:16:13 - 1.119
+++ cpu-exec.c 12 Oct 2007 22:53:37 -
@@ -133,6 +133,7 @@ static TranslationBlock *tb_find_slow(ta
tb->tc_ptr = tc_ptr;
tb->cs_base = cs_base;
tb->flags = flags;
+tb->page_addr[0] = phys_page1;
cpu_gen_code(env, tb, CODE_GEN_MAX_SIZE, &code_gen_size);
code_gen_ptr = (void *)(((unsigned long)code_gen_ptr + code_gen_size + CODE_GEN_ALIGN - 1) & ~(CODE_GEN_ALIGN - 1));
Index: softmmu_header.h
===
RCS file: /sources/qemu/qemu/softmmu_header.h,v
retrieving revision 1.17
diff -u -d -d -p -r1.17 softmmu_header.h
--- softmmu_header.h 8 Oct 2007 13:16:14 - 1.17
+++ softmmu_header.h 12 Oct 2007 22:53:37 -
@@ -336,6 +336,60 @@ static inline void glue(glue(st, SUFFIX)
}
}
+#else
+
+#if DATA_SIZE <= 2
+static inline RES_TYPE glue(glue(glue(lds,SUFFIX),MEMSUFFIX),_p)(unsigned long *start_pc,
+ unsigned long phys_pc,
+ target_ulong virt_pc)
+{
+RES_TYPE opc;
+
+if (unlikely((*start_pc ^
+ (phys_pc + sizeof(RES_TYPE) - 1)) >> TARGET_PAGE_BITS)) {
+/* Slow path: phys_pc is not in the same page than start_pc
+ *or the insn is spanning two pages
+ */
+opc = glue(glue(lds,SUFFIX),MEMSUFFIX)(virt_pc);
+/* Avoid softmmu access on next load */
+/* XXX: dont: phys PC is not correct anymore
+
