[Qemu-devel] qemu Makefile.target configure linux-user/elflo...
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 06/06/11 13:32:59
Modified files:
. : Makefile.target configure
linux-user : elfload.c main.c qemu.h
Added files:
linux-user : flat.h flatload.c linuxload.c
Log message:
bFLT loader (for uClinux binaries).
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.113r2=1.114
http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemur1=1.102r2=1.103
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/elfload.c?cvsroot=qemur1=1.34r2=1.35
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.83r2=1.84
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/qemu.h?cvsroot=qemur1=1.26r2=1.27
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/flat.h?cvsroot=qemurev=1.1
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/flatload.c?cvsroot=qemurev=1.1
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/linuxload.c?cvsroot=qemurev=1.1
Patches:
Index: Makefile.target
===
RCS file: /sources/qemu/qemu/Makefile.target,v
retrieving revision 1.113
retrieving revision 1.114
diff -u -b -r1.113 -r1.114
--- Makefile.target 30 May 2006 01:48:12 - 1.113
+++ Makefile.target 11 Jun 2006 13:32:58 - 1.114
@@ -171,7 +171,12 @@
main.o: CFLAGS+=-p
endif
-OBJS= elfload.o main.o syscall.o mmap.o signal.o path.o osdep.o thunk.o
+OBJS= main.o syscall.o mmap.o signal.o path.o osdep.o thunk.o \
+ elfload.o linuxload.o
+ifdef TARGET_HAS_BFLT
+OBJS+= flatload.o
+endif
+
ifeq ($(TARGET_ARCH), i386)
OBJS+= vm86.o
endif
Index: configure
===
RCS file: /sources/qemu/qemu/configure,v
retrieving revision 1.102
retrieving revision 1.103
diff -u -b -r1.102 -r1.103
--- configure 14 May 2006 11:30:38 - 1.102
+++ configure 11 Jun 2006 13:32:58 - 1.103
@@ -773,6 +773,7 @@
echo include ../config-host.mak $config_mak
echo #include \../config-host.h\ $config_h
+bflt=no
interp_prefix1=`echo $interp_prefix | sed s/%M/$target_cpu/g`
echo #define CONFIG_QEMU_PREFIX \$interp_prefix1\ $config_h
@@ -787,6 +788,7 @@
echo TARGET_ARCH=arm $config_mak
echo #define TARGET_ARCH \arm\ $config_h
echo #define TARGET_ARM 1 $config_h
+ bflt=yes
elif test $target_cpu = sparc ; then
echo TARGET_ARCH=sparc $config_mak
echo #define TARGET_ARCH \sparc\ $config_h
@@ -842,6 +844,10 @@
echo CONFIG_SOFTFLOAT=yes $config_mak
echo #define CONFIG_SOFTFLOAT 1 $config_h
fi
+if test $target_user_only = yes -a $bflt = yes; then
+ echo TARGET_HAS_BFLT=yes $config_mak
+ echo #define TARGET_HAS_BFLT 1 $config_h
+fi
# sdl defines
if test $target_user_only = no; then
Index: linux-user/elfload.c
===
RCS file: /sources/qemu/qemu/linux-user/elfload.c,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -b -r1.34 -r1.35
--- linux-user/elfload.c27 Apr 2006 21:07:12 - 1.34
+++ linux-user/elfload.c11 Jun 2006 13:32:58 - 1.35
@@ -3,7 +3,6 @@
#include stdio.h
#include sys/types.h
#include fcntl.h
-#include sys/stat.h
#include errno.h
#include unistd.h
#include sys/mman.h
@@ -59,6 +58,11 @@
#define ELF_DATA ELFDATA2LSB
#define ELF_ARCH EM_386
+static inline void init_thread(struct target_pt_regs *regs, struct image_info
*infop)
+{
+regs-esp = infop-start_stack;
+regs-eip = infop-entry;
+
/* SVR4/i386 ABI (pages 3-31, 3-32) says that when the program
starts %edx contains a pointer to a function which might be
registered using `atexit'. This provides a mean for the
@@ -66,12 +70,7 @@
that have been loaded before the code runs.
A value of 0 tells we have no such handler. */
-#define ELF_PLAT_INIT(_r) _r-edx = 0
-
-static inline void init_thread(struct target_pt_regs *regs, struct image_info
*infop)
-{
-regs-esp = infop-start_stack;
-regs-eip = infop-entry;
+regs-edx = 0;
}
#define USE_ELF_CORE_DUMP
@@ -93,8 +92,6 @@
#endif
#define ELF_ARCH EM_ARM
-#define ELF_PLAT_INIT(_r) _r-ARM_r0 = 0
-
static inline void init_thread(struct target_pt_regs *regs, struct image_info
*infop)
{
target_long stack = infop-start_stack;
@@ -107,7 +104,9 @@
regs-ARM_r2 = tgetl(stack + 8); /* envp */
regs-ARM_r1 = tgetl(stack + 4); /* envp */
/* XXX: it seems that r0 is zeroed after ! */
-//regs-ARM_r0 = tgetl(stack); /* argc */
+regs-ARM_r0 = 0;
+/* For uClinux PIC binaries. */
+regs-ARM_r10 = infop-start_data;
}
#define USE_ELF_CORE_DUMP
@@ -142,9 +141,6 @@
#define ELF_DATAELFDATA2MSB
#define ELF_ARCHEM_SPARC
-/*XXX*/
-#define ELF_PLAT_INIT(_r)
-
static inline void init_thread(struct target_pt_regs *regs,
[Qemu-devel] setting MIPS gdb breakpoints have wrong offsets
Hi, I just tried to debug some simple MIPS code using qemu-system-mipsel by setting some breakpoints. If I use gdb's break command with symbol names the breakpoints are set at offsets and therefore they are never hit. Please find an example below. I'd like to stop the program if I get an interrupt, everything looks okay. But break command sets breakpoint at 0xbfc00384 instead of 0xbfc00380. Is this a bug or feature? I use qemu-system-mipsel with some of the pending MIPS patches applied locally. If this is a bug, can anybody else reproduce this? Any idea? Best regards Dirk (gdb) info address exception Symbol exception is at 0xbfc00380. (gdb) list exception 158 .end cache_miss 159 160 .org 0x380 161 .ent exception 162 exception: 163 j exception_handler 164 nop 165 .end exception 166 167 / (gdb) x/2i 0xbfc00380 0xbfc00380 exception: b 0xbfc0046c exception_handler 0xbfc00384 exception+4: nop (gdb) break exception Breakpoint 1 at 0xbfc00384: file crt0.S, line 163. (gdb) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu qemu-doc.texi
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
Re: [Qemu-devel] setting MIPS gdb breakpoints have wrong offsets
Hi Dirk, when I set a breakpoint to address 0x8180 (b *0x8180), this works as expected. So do breakpoints to symbolic addresses in the Linux kernel. info breakpoints shows address 0x8180 for the first example. Maybe b *0xbfc00380 works for your case. If it does, your mips-gdb is somehow strange. Regards Stefan Dirk Behme schrieb: Hi, I just tried to debug some simple MIPS code using qemu-system-mipsel by setting some breakpoints. If I use gdb's break command with symbol names the breakpoints are set at offsets and therefore they are never hit. Please find an example below. I'd like to stop the program if I get an interrupt, everything looks okay. But break command sets breakpoint at 0xbfc00384 instead of 0xbfc00380. Is this a bug or feature? I use qemu-system-mipsel with some of the pending MIPS patches applied locally. If this is a bug, can anybody else reproduce this? Any idea? Best regards Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] setting MIPS gdb breakpoints have wrong offsets
On Sun, Jun 11, 2006 at 10:56:51PM +0200, Stefan Weil wrote: Hi Dirk, when I set a breakpoint to address 0x8180 (b *0x8180), this works as expected. So do breakpoints to symbolic addresses in the Linux kernel. info breakpoints shows address 0x8180 for the first example. Maybe b *0xbfc00380 works for your case. If it does, your mips-gdb is somehow strange. This means that GDB has (mistakenly) decided that the first assembly instruction in the function is part of a standard function prologue; feel free to report a GDB bug. -- Daniel Jacobowitz CodeSourcery ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: RE : Re: [Qemu-devel] Windows Vista
On Fri, 9 Jun 2006, Ben Taylor wrote: Does the ACPI patch that was posted a couple of weeks ago for Solaris/X86 support help at all? That patch would be much easier to test if someone were to provide a pre-compiled ACPI blob. (I'd love to test it). regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: If it ain't broke, don't fix it. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
