[Qemu-devel] sh4: further updates
Hi everyone,
Here comes the second batch of patches for the user space emulator.
Below is a one line summary of each patch, please have a look in the
patch header for details:
- Fix XHACK() macro and use FREG if possible
- Emulate more fpu opcodes
- Document FPSCR usage
- Use DREG() over XREG() if possible
- Remove unnecessary pointer magic in shift operations
- Add fpu register support to the gdb code
If you have any questions or comments, please don't hesitate to contact me!
Thanks!
/ magnus
sh4: Fix XHACK() macro and use FREG if possible
The XHACK() macro seems to incorrectly shift left once, so fix that.
XREG() is used in some places where FREG() is more suitable.
Signed-off-by: Magnus Damm <[EMAIL PROTECTED]>
--- 0001/target-sh4/translate.c
+++ work/target-sh4/translate.c 2007-05-07 17:11:49.0 +0900
@@ -236,7 +236,7 @@ static void gen_delayed_conditional_jump
? (x) + 16 : (x))
#define FREG(x) (ctx->fpscr & FPSCR_FR ? (x) ^ 0x10 : (x))
-#define XHACK(x) (((x) & 1 ) << 4 | ((x) & 0xe ) << 1)
+#define XHACK(x) x) & 1 ) << 4) | ((x) & 0xe))
#define XREG(x) (ctx->fpscr & FPSCR_FR ? XHACK(x) ^ 0x10 : XHACK(x))
#define CHECK_NOT_DELAY_SLOT \
@@ -685,7 +685,7 @@ void decode_opc(DisasContext * ctx)
} else {
gen_op_movl_rN_T0(REG(B7_4));
gen_op_ldfl_T0_FT0(ctx);
- gen_op_fmov_FT0_frN(XREG(B11_8));
+ gen_op_fmov_FT0_frN(FREG(B11_8));
}
return;
case 0xf009: /* fmov @Rm+,{F,D,X}Rn */
@@ -704,7 +704,7 @@ void decode_opc(DisasContext * ctx)
} else {
gen_op_movl_rN_T0(REG(B7_4));
gen_op_ldfl_T0_FT0(ctx);
- gen_op_fmov_FT0_frN(XREG(B11_8));
+ gen_op_fmov_FT0_frN(FREG(B11_8));
gen_op_inc4_rN(REG(B7_4));
}
return;
@@ -745,7 +745,7 @@ void decode_opc(DisasContext * ctx)
gen_op_movl_rN_T0(REG(B7_4));
gen_op_add_rN_T0(REG(0));
gen_op_ldfl_T0_FT0(ctx);
- gen_op_fmov_FT0_frN(XREG(B11_8));
+ gen_op_fmov_FT0_frN(FREG(B11_8));
}
return;
case 0xf007: /* fmov {F,D,X}Rn,@(R0,Rn) */
sh4: Emulate more fpu opcodes
This patch adds support for more fpu opcodes. Emulation is not complete
yet - FPU flags and exceptions are not fully supported. The FPSCR register
does not yet contain correct flag information. But it is a good start. =)
Signed-off-by: Magnus Damm <[EMAIL PROTECTED]>
--- 0001/target-sh4/cpu.h
+++ work/target-sh4/cpu.h 2007-05-07 17:40:32.0 +0900
@@ -99,6 +99,7 @@ typedef struct CPUSH4State {
/* temporary float registers */
float32 ft0, ft1;
float64 dt0, dt1;
+float_status fp_status;
/* Those belong to the specific unit (SH7750) but are handled here */
uint32_t mmucr; /* MMU control register */
--- 0001/target-sh4/op.c
+++ work/target-sh4/op.c 2007-05-07 17:40:32.0 +0900
@@ -509,6 +509,9 @@ void OPPROTO op_##store##_##target##_T0
void OPPROTO op_lds_T0_fpscr(void)
{
env->fpscr = T0 & 0x003f;
+env->fp_status.float_rounding_mode = T0 & 0x01 ?
+ float_round_to_zero : float_round_nearest_even;
+
RETURN();
}
@@ -705,6 +708,18 @@ void OPPROTO op_fmov_drN_DT0(void)
RETURN();
}
+void OPPROTO op_fmov_frN_FT1(void)
+{
+FT1 = *(float32 *)&env->fregs[PARAM1];
+RETURN();
+}
+
+void OPPROTO op_fmov_drN_DT1(void)
+{
+DT1 = *(float64 *)&env->fregs[PARAM1];
+RETURN();
+}
+
void OPPROTO op_fmov_FT0_frN(void)
{
*(float32 *)&env->fregs[PARAM1] = FT0;
@@ -717,6 +732,84 @@ void OPPROTO op_fmov_DT0_drN(void)
RETURN();
}
+void OPPROTO op_fadd_FT(void)
+{
+FT0 = float32_add(FT0, FT1, &env->fp_status);
+RETURN();
+}
+
+void OPPROTO op_fadd_DT(void)
+{
+DT0 = float64_add(DT0, DT1, &env->fp_status);
+RETURN();
+}
+
+void OPPROTO op_fsub_FT(void)
+{
+FT0 = float32_sub(FT0, FT1, &env->fp_status);
+RETURN();
+}
+
+void OPPROTO op_fsub_DT(void)
+{
+DT0 = float64_sub(DT0, DT1, &env->fp_status);
+RETURN();
+}
+
+void OPPROTO op_fmul_FT(void)
+{
+FT0 = float32_mul(FT0, FT1, &env->fp_status);
+RETURN();
+}
+
+void OPPROTO op_fmul_DT(void)
+{
+DT0 = float64_mul(DT0, DT1, &env->fp_status);
+RETURN();
+}
+
+void OPPROTO op_fdiv_FT(void)
+{
+FT0 = float32_div(FT0, FT1, &env->fp_status);
+RETURN();
+}
+
+void OPPROTO op_fdiv_DT(void)
+{
+DT0 = float64_div(DT0, DT1, &env->fp_status);
+RETURN();
+}
+
+void OPPROTO op_float_FT(void)
+{
+FT0 = int32_to_float32(env->fpul, &env->fp_status);
+RETURN();
+}
+
+void OPPROTO op_float_DT(void)
+{
+DT0 = int32_to_float64(env->fpul, &env->fp_status);
+RETURN();
+}
+
+void OPPROTO op_ftrc_FT(void)
+{
+env->fpul = float32_to_int32(FT0, &env->fp_status);
+RETURN();
+}
+
+void OPPROTO op_ftrc_DT(void)
+{
+env->fpul = float64_to_int32(DT0, &env->fp_status);
+RETURN();
+}
+
+void OPPROTO op_movl_T0_FT0(void)
+{
+FT0 = T0;
+RETURN();
+}
+
void OPPROTO op_dec1_rN(void)
{
env->gregs[PARAM1] -= 1;
--- 0002/target-sh4/translate.c
+++ work/target-sh4/translate.c 2007-05-09 16:47:55.000
Re: [Qemu-devel] [PATCH] configure
> Thiemo Seufer wrote: > Jeff Chua wrote: > [snip] > > @@ -567,7 +567,8 @@ > >fi > > > ># Check if tools are available to build documentation. > > -if [ -x "`which texi2html`" ] && [ -x "`which pod2man`" ]; then > > +if [ -x "`which texi2html 2>/dev/null`" \ > > + -a -x "`which pod2man 2>/dev/null`" ]; then > > Under which circumstances does "which" complain about unavailable > executables? Isn't the use of "which" wrong, anyway? "which" belongs to csh/tcsh, and tells you about csh's/tcsh's idea about a command or a csh command alias. IMO, for a /bin/sh (or bash) script, using the "type" command would be a better idea.
[Qemu-devel] [PATCH] MIPS: support MMU selection at runtime
Hi, The attached patch removes the MIPS_USES_R4K_TLB define, and replaces it by some function pointers in the env structure. The model can be extended to support another TLB types quite easily (see translate_init.c) Hervé dynamic_mmu.diff Description: Binary data
Re: [Qemu-devel] [PATCH] configure
On 5/9/07, Juergen Keil <[EMAIL PROTECTED]> wrote: Isn't the use of "which" wrong, anyway? "which" belongs to csh/tcsh, and tells you about csh's/tcsh's idea about a command or a csh command alias. IMO, for a /bin/sh (or bash) script, using the "type" command would be a better idea. "which" returns the first path, "type" returns all paths. # type awk awk is /bin/awk awk is /usr/bin/awk # which awk /bin/awk # type foo -bash: type: foo: not found Either way would work, but even with "type", it still needs to be "type foo 2>/dev/null". Thanks, Jeff.
[Qemu-devel] qemu/target-mips op.c translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/05/09 09:33:33 Modified files: target-mips: op.c translate.c Log message: Fix MIPS64 address computation specialcase, by Aurelien Jarno. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemu&r1=1.46&r2=1.47 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.69&r2=1.70
[Qemu-devel] qemu/target-mips helper.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/05/09 09:34:31 Modified files: target-mips: helper.c Log message: Preliminary MIPS 64-bit MMU implementation, by Aurelien Jarno. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/helper.c?cvsroot=qemu&r1=1.36&r2=1.37
Re: [Qemu-devel] [PATCH] configure
"Jeff Chua" <[EMAIL PROTECTED]> writes: > On 5/9/07, Juergen Keil <[EMAIL PROTECTED]> wrote: > >> Isn't the use of "which" wrong, anyway? >> >> "which" belongs to csh/tcsh, and tells you about csh's/tcsh's idea >> about a command or a csh command alias. >> >> IMO, for a /bin/sh (or bash) script, using the "type" command would >> be a better idea. > > "which" returns the first path, "type" returns all paths. You want "type -p". Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [Qemu-devel] configure
On Wednesday, May 9, 2007, 2:41:03, Thiemo Seufer wrote: > I don't see a warning for e.g. "which foo" on my system. Could you > describe your system and paste the output the which command produces > there? Gentoo: # which foo which: no foo in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1:/opt/blackdown-jre-1.4.2.03/bin) # which nano /usr/bin/nano # file /usr/bin/which /usr/bin/which: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped Debian: # which foo # which nano /usr/bin/nano # file /bin/which /bin/which: Bourne shell script text executable which builtin in the shell on my firewall box (pfSense, based on FreeBSD 6.2) also produces a warning, but /usr/bin/which on the same box doesn't. -- < Jernej Simončič ><><><><>< http://deepthought.ena.si/ > Space expands to house the people to perform the work that Congress creates. -- Washington's Law
[Qemu-devel] Re: qcow2 images going corrupt
On 2007-05-08, Thiemo Seufer <[EMAIL PROTECTED]> wrote: > There was a bug in the qcow2 support which is fixed in CVS. You can use > qcow instead, or upgrade to a recent-ish CVS version of qemu. Oh yeah, thanks, I see. I really could as well have looked it up myself... What I *don't* understand is that why has not the Qemu team made a bugfix release immediately? This is a _serious bug_. It can cause data loss. As it did for me. Csaba
[Qemu-devel] Tiny but full featured demo based on qemu-system-arm
Here's a demo everyone here can start in less than 1 minute: http://free-electrons.com/community/demos/qemu-arm-directfb/ You just have to download 1 file and run qemu. Let it surprise you! This demo shows that it's possible to implement a full-featured embedded system with a graphical interface within 2.1 MB! Feedback, suggestions and contributions are welcome! :-) Michael. -- Michael Opdenacker, Free Electrons Free Embedded Linux Training Materials on http://free-electrons.com/training (More than 1500 pages!)
[Qemu-devel] Could any body fix the bug in gdbstub.c for x86_64?
Hi,
The -s option for qemu-system-x86_64 is not useable.
I've already post a patch, but it is ignored.
http://lists.gnu.org/archive/html/qemu-devel/2007-05/msg00062.html
This patch is for version 0.9.0, could some body merge it
in the cvs tree?
---><--
--- qemu-0.9.0/gdbstub.cTue Feb 6 07:01:54 2007
+++ gdbstub.cSat May 5 02:22:39 2007
@@ -223,63 +223,83 @@
#if defined(TARGET_I386)
+#if defined(TARGET_X86_64)
+/*
+ * XXX
+ * This is a ugly hack (in my opinion...), is it better to redefine R_EXX
+ * in target-i386/cpu.h to match 'amd64_regnum' in gdb (gdb/amd64-tdep.h)?
+ */
+static int regnames[CPU_NB_REGS] = { R_EAX, R_EBX, R_ECX, R_EDX, R_ESI,
R_EDI,
+R_EBP, R_ESP, 8, 9, 10, 11, 12, 13, 14, 15 };
+#endif
static int cpu_gdb_read_registers(CPUState *env, uint8_t *mem_buf)
{
-uint32_t *registers = (uint32_t *)mem_buf;
-int i, fpus;
+target_ulong *registers = (target_ulong *)mem_buf;
+int i, fpus, regno0, regno1, regno2;
-for(i = 0; i < 8; i++) {
+for(i = 0; i < CPU_NB_REGS; i++) {
+#if defined(TARGET_X86_64)
+registers[i] = env->regs[regnames[i]];
+#else
registers[i] = env->regs[i];
+#endif
}
-registers[8] = env->eip;
-registers[9] = env->eflags;
-registers[10] = env->segs[R_CS].selector;
-registers[11] = env->segs[R_SS].selector;
-registers[12] = env->segs[R_DS].selector;
-registers[13] = env->segs[R_ES].selector;
-registers[14] = env->segs[R_FS].selector;
-registers[15] = env->segs[R_GS].selector;
+registers[i++] = env->eip;
+registers[i++] = env->eflags;
+registers[i++] = env->segs[R_CS].selector;
+registers[i++] = env->segs[R_SS].selector;
+registers[i++] = env->segs[R_DS].selector;
+registers[i++] = env->segs[R_ES].selector;
+registers[i++] = env->segs[R_FS].selector;
+registers[i++] = env->segs[R_GS].selector;
+regno0 = i;
/* XXX: convert floats */
for(i = 0; i < 8; i++) {
-memcpy(mem_buf + 16 * 4 + i * 10, &env->fpregs[i], 10);
+memcpy(mem_buf + regno0 * sizeof(target_ulong) + i * 10,
&env->fpregs[i], 10);
}
-registers[36] = env->fpuc;
+regno1 = regno0 + (i * 10)/sizeof(target_ulong);
+i = regno1;
+registers[i++] = env->fpuc;
fpus = (env->fpus & ~0x3800) | (env->fpstt & 0x7) << 11;
-registers[37] = fpus;
-registers[38] = 0; /* XXX: convert tags */
-registers[39] = 0; /* fiseg */
-registers[40] = 0; /* fioff */
-registers[41] = 0; /* foseg */
-registers[42] = 0; /* fooff */
-registers[43] = 0; /* fop */
-
-for(i = 0; i < 16; i++)
+registers[i++] = fpus;
+registers[i++] = 0; /* XXX: convert tags */
+registers[i++] = 0; /* fiseg */
+registers[i++] = 0; /* fioff */
+registers[i++] = 0; /* foseg */
+registers[i++] = 0; /* fooff */
+registers[i++] = 0; /* fop */
+regno2 = i;
+for(i = 0; i < regno0; i++)
tswapls(®isters[i]);
-for(i = 36; i < 44; i++)
+for(i = regno1; i < regno2; i++)
tswapls(®isters[i]);
-return 44 * 4;
+return (regno2 * sizeof(target_ulong));
}
static void cpu_gdb_write_registers(CPUState *env, uint8_t *mem_buf, int
size)
{
-uint32_t *registers = (uint32_t *)mem_buf;
+target_ulong *registers = (target_ulong *)mem_buf;
int i;
-for(i = 0; i < 8; i++) {
+for(i = 0; i < CPU_NB_REGS; i++) {
+#if defined(TARGET_X86_64)
+env->regs[regnames[i]] = tswapl(registers[i]);
+#else
env->regs[i] = tswapl(registers[i]);
+#endif
}
-env->eip = tswapl(registers[8]);
-env->eflags = tswapl(registers[9]);
+env->eip = tswapl(registers[CPU_NB_REGS]);
+env->eflags = tswapl(registers[CPU_NB_REGS + 1]);
#if defined(CONFIG_USER_ONLY)
#define LOAD_SEG(index, sreg)\
if (tswapl(registers[index]) != env->segs[sreg].selector)\
cpu_x86_load_seg(env, sreg, tswapl(registers[index]));
-LOAD_SEG(10, R_CS);
-LOAD_SEG(11, R_SS);
-LOAD_SEG(12, R_DS);
-LOAD_SEG(13, R_ES);
-LOAD_SEG(14, R_FS);
-LOAD_SEG(15, R_GS);
+LOAD_SEG(CPU_NB_REGS + 2, R_CS);
+LOAD_SEG(CPU_NB_REGS + 3, R_SS);
+LOAD_SEG(CPU_NB_REGS + 4, R_DS);
+LOAD_SEG(CPU_NB_REGS + 5, R_ES);
+LOAD_SEG(CPU_NB_REGS + 6, R_FS);
+LOAD_SEG(CPU_NB_REGS + 7, R_GS);
#endif
}
-><---
Regards,
MingyanGuo
--
Three passions, simple but overwhelmingly strong, have governed my life:
the longing for love, the search for knowledge, and unbearable pity for
the suffering of mankind.
-Bertrand Russell
[Qemu-devel] [PATCH, RFC] Fix softfloat NaN handling
Hello All,
The relevant IEEE standards don't define if a set or a clear bit is
used to distinguish between QNaN and SNaN. MIPS, and apparently
PA RISC, made a different choice than the rest of the industry.
The appended patch accounts for this, it fixes a number of failures
on MIPS, none of those appears to be covered by e.g. classic paranoia.
It also changes some things for the other architectures, that's why
I ask for comments:
- float32_is_nan tests now for <=, since the set MSB of the mantissa
is enough to make it a proper QNaN.
- float64_is_nan has the same change, plus a changed bitmask which
is consistent to the QNaN definition.
Thiemo
Index: qemu-cvs/fpu/softfloat-specialize.h
===
--- qemu-cvs.orig/fpu/softfloat-specialize.h
+++ qemu-cvs/fpu/softfloat-specialize.h
@@ -61,7 +61,11 @@
/*
| The pattern for a default generated single-precision NaN.
**/
+#if defined(TARGET_MIPS) || defined(TARGET_HPPA)
+#define float32_default_nan 0xFF80
+#else
#define float32_default_nan 0xFFC0
+#endif
/*
| Returns 1 if the single-precision floating-point value `a' is a NaN;
@@ -70,9 +74,11 @@
int float32_is_nan( float32 a )
{
-
-return ( 0xFF00 < (bits32) ( a<<1 ) );
-
+#if defined(TARGET_MIPS) || defined(TARGET_HPPA)
+return ( ( ( a>>22 ) & 0x1FF ) == 0x1FE ) && ( a & 0x003F );
+#else
+return ( 0xFF80 <= (bits32) ( a<<1 ) );
+#endif
}
/*
@@ -82,9 +88,11 @@
int float32_is_signaling_nan( float32 a )
{
-
+#if defined(TARGET_MIPS) || defined(TARGET_HPPA)
+return ( 0xFF80 <= (bits32) ( a<<1 ) );
+#else
return ( ( ( a>>22 ) & 0x1FF ) == 0x1FE ) && ( a & 0x003F );
-
+#endif
}
/*
@@ -131,8 +139,13 @@
aIsSignalingNaN = float32_is_signaling_nan( a );
bIsNaN = float32_is_nan( b );
bIsSignalingNaN = float32_is_signaling_nan( b );
+#if defined(TARGET_MIPS) || defined(TARGET_HPPA)
+a &= ~0x0040;
+b &= ~0x0040;
+#else
a |= 0x0040;
b |= 0x0040;
+#endif
if ( aIsSignalingNaN | bIsSignalingNaN ) float_raise( float_flag_invalid
STATUS_VAR);
if ( aIsSignalingNaN ) {
if ( bIsSignalingNaN ) goto returnLargerSignificand;
@@ -154,7 +167,11 @@
/*
| The pattern for a default generated double-precision NaN.
**/
+#if defined(TARGET_MIPS) || defined(TARGET_HPPA)
+#define float64_default_nan LIT64( 0xFFF0 )
+#else
#define float64_default_nan LIT64( 0xFFF8 )
+#endif
/*
| Returns 1 if the double-precision floating-point value `a' is a NaN;
@@ -163,9 +180,13 @@
int float64_is_nan( float64 a )
{
-
-return ( LIT64( 0xFFE0 ) < (bits64) ( a<<1 ) );
-
+#if defined(TARGET_MIPS) || defined(TARGET_HPPA)
+return
+ ( ( ( a>>51 ) & 0xFFF ) == 0xFFE )
+&& ( a & LIT64( 0x0007 ) );
+#else
+return ( LIT64( 0xFFF0 ) <= (bits64) ( a<<1 ) );
+#endif
}
/*
@@ -175,11 +196,13 @@
int float64_is_signaling_nan( float64 a )
{
-
+#if defined(TARGET_MIPS) || defined(TARGET_HPPA)
+return ( LIT64( 0xFFF0 ) <= (bits64) ( a<<1 ) );
+#else
return
( ( ( a>>51 ) & 0xFFF ) == 0xFFE )
&& ( a & LIT64( 0x0007 ) );
-
+#endif
}
/*
@@ -229,8 +252,13 @@
aIsSignalingNaN = float64_is_signaling_nan( a );
bIsNaN = float64_is_nan( b );
bIsSignalingNaN = float64_is_signaling_nan( b );
+#if defined(TARGET_MIPS) || defined(TARGET_HPPA)
+a &= ~LIT64( 0x0008 );
+b &= ~LIT64( 0x0008 );
+#else
a |= LIT64( 0x0008 );
b |= LIT64( 0x0008 );
+#endif
if ( aIsSignalingNaN | bIsSignalingNaN ) float_raise( float_flag_invalid
STATUS_VAR);
if ( aIsSignalingNaN ) {
if ( bIsSignalingNaN ) goto returnLargerSignificand;
Re: [Qemu-devel] Tiny but full featured demo based on qemu-system-arm
On 5/9/07, Michael Opdenacker wrote: This demo shows that it's possible to implement a full-featured embedded system with a graphical interface within 2.1 MB! Feedback, suggestions and contributions are welcome! cool :) merci Michael... -- Christian
[Qemu-devel] Re: Could any body fix the bug in gdbstub.c for x86_64?
MingyanGuo wrote: > Hi, > The -s option for qemu-system-x86_64 is not useable. > I've already post a patch, but it is ignored. Have you seen my patch [1] on this already? Does it work for you? It's running fine here, but there are still some open questions [2], and I unfortunately didn't received feedback on my last revisions as well. I haven't looked in details at your approach, but you stumbled over the same thing as I did, that redefining the register constants would simplify things significantly - if this is fine with the rest of qemu. > http://lists.gnu.org/archive/html/qemu-devel/2007-05/msg00062.html > This patch is for version 0.9.0, could some body merge it > in the cvs tree? > However the solution will finally look like, a fix for the next release would be welcome here as well! One just need to know which way is preferred... Jan [1] http://lists.gnu.org/archive/html/qemu-devel/2007-04/msg00554.html [2] http://lists.gnu.org/archive/html/qemu-devel/2007-04/msg00524.html signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] configure
On Wed, 2007-05-09 at 10:51 +0200, Juergen Keil wrote: > Isn't the use of "which" wrong, anyway? > > "which" belongs to csh/tcsh, and tells you about csh's/tcsh's idea > about a command or a csh command alias. > > IMO, for a /bin/sh (or bash) script, using the "type" command would > be a better idea. Yes, 'which' is not reliable. I already posted a patch regarding Mac OS X here: http://lists.gnu.org/archive/html/qemu-devel/2007-04/msg00649.html It fixes gcc detection only, because the other tools, that are detected by which, are installed anyway. This is of course not clean, but worked for the time. -- Joachim Henke http://base91.sourceforge.net/j-o/
[Qemu-devel] qemu configure
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/05/09 13:55:04 Modified files: . : configure Log message: Suppress warning messages from "which". CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1.140&r2=1.141
Re: [Qemu-devel] configure
Jernej Simon?i? wrote: > On Wednesday, May 9, 2007, 2:41:03, Thiemo Seufer wrote: > > > I don't see a warning for e.g. "which foo" on my system. Could you > > describe your system and paste the output the which command produces > > there? > > Gentoo: > > # which foo > which: no foo in > (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1:/opt/blackdown-jre-1.4.2.03/bin) > # which nano > /usr/bin/nano > # file /usr/bin/which > /usr/bin/which: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for > GNU/Linux 2.4.1, dynamically linked (uses shared libs), for GNU/Linux 2.4.1, > stripped > > Debian: > > # which foo > # which nano > /usr/bin/nano > # file /bin/which > /bin/which: Bourne shell script text executable > > which builtin in the shell on my firewall box (pfSense, based on > FreeBSD 6.2) also produces a warning, but /usr/bin/which on the same > box doesn't. Thanks, that's the information I needed. Thiemo
[Qemu-devel] qemu configure
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/05/09 14:06:07 Modified files: . : configure Log message: Avoid use of which to detect gcc, as it is broken on darwin. Patch by Joachim Henke. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1.141&r2=1.142
Re: [Qemu-devel] [PATCH] configure
Joachim Henke wrote: > On Wed, 2007-05-09 at 10:51 +0200, Juergen Keil wrote: > > Isn't the use of "which" wrong, anyway? > > > > "which" belongs to csh/tcsh, and tells you about csh's/tcsh's idea > > about a command or a csh command alias. > > > > IMO, for a /bin/sh (or bash) script, using the "type" command would > > be a better idea. > > Yes, 'which' is not reliable. "type" appears to be bash-specific, at least according to the bash documentation, so I stuck with "which" for now. Thiemo
Re: [Qemu-devel] [PATCH] configure
On 5/9/07, Andreas Schwab <[EMAIL PROTECTED]> wrote: "Jeff Chua" <[EMAIL PROTECTED]> writes: > "which" returns the first path, "type" returns all paths. You want "type -p". # type awk awk is /bin/awk awk is /usr/bin/awk # type -p awk /bin/awk /usr/bin/awk # type foo -bash: type: foo: not found # type -p foo # Interesting. "type -p foo" does the same as "type foo 2>/dev/null", but only if "foo" is not found. Tried that on "awk" above, and it prints the paths. Thanks, Jeff.
[Qemu-devel] Re: Could any body fix the bug in gdbstub.c for x86_64?
On 5/9/07, Jan Kiszka <[EMAIL PROTECTED]> wrote: MingyanGuo wrote: > Hi, > The -s option for qemu-system-x86_64 is not useable. > I've already post a patch, but it is ignored. Have you seen my patch [1] on this already? Does it work for you? It's running fine here, but there are still some open questions [2], and I unfortunately didn't received feedback on my last revisions as well. I haven't looked in details at your approach, but you stumbled over the same thing as I did, that redefining the register constants would simplify things significantly - if this is fine with the rest of qemu. I read your patch now, our approaches are the same I think, just in different forms. I don't know if there are any adverse side effects to redefine the register constants (see my comments in the patch), so a simple register mapping is a quick fix :-) http://lists.gnu.org/archive/html/qemu-devel/2007-05/msg00062.html > This patch is for version 0.9.0, could some body merge it > in the cvs tree? > However the solution will finally look like, a fix for the next release would be welcome here as well! One just need to know which way is preferred... Jan [1] http://lists.gnu.org/archive/html/qemu-devel/2007-04/msg00554.html [2] http://lists.gnu.org/archive/html/qemu-devel/2007-04/msg00524.html I should cancel my patch now, as I am debugging an OS kernel, no xmms/fpu registers considered, and your patch is better. :D Regards, MingyanGuo -- Three passions, simple but overwhelmingly strong, have governed my life: the longing for love, the search for knowledge, and unbearable pity for the suffering of mankind. -Bertrand Russell
Re: [Qemu-devel] [PATCH, RFC] Fix softfloat NaN handling
On 5/9/07, Thiemo Seufer <[EMAIL PROTECTED]> wrote: Hello All, The relevant IEEE standards don't define if a set or a clear bit is used to distinguish between QNaN and SNaN. MIPS, and apparently PA RISC, made a different choice than the rest of the industry. On Sparc, the rule is as follows: SNaN: sign undefined, exponent 255, mantissa 0xxx...and at least one bit must be nonzero QNaN: sign undefined, exponent 255, mantissa 1xxx... Is this the same as MIPS?
[Qemu-devel] [PATCH] fadvise64 support
Hi,
this patch should implement fadvise64 and fadvise64_64 syscall support
for at least i386 by mapping it to the host syscall. While trying out a
current glibc version with qemu-i386 it just annoyed me to get an
unsupported syscall for this.
Hope this helps,
Alex
Index: qemu-0.9.0/linux-user/syscall.c
===
--- qemu-0.9.0.orig/linux-user/syscall.c
+++ qemu-0.9.0/linux-user/syscall.c
@@ -144,6 +144,7 @@ type name (type1 arg1,type2 arg2,type3 a
#define __NR_sys_getdents64 __NR_getdents64
#define __NR_sys_rt_sigqueueinfo __NR_rt_sigqueueinfo
#define __NR_sys_syslog __NR_syslog
+#define __NR_sys_fadvise64 __NR_fadvise64
#if defined(__alpha__) || defined (__ia64__) || defined(__x86_64__)
#define __NR__llseek __NR_lseek
@@ -164,6 +165,7 @@ _syscall5(int, _llseek, uint, fd, ulon
loff_t *, res, uint, wh);
_syscall3(int,sys_rt_sigqueueinfo,int,pid,int,sig,siginfo_t *,uinfo)
_syscall3(int,sys_syslog,int,type,char*,bufp,int,len)
+_syscall4(int,sys_fadvise64,int,fd,loff_t,offset,loff_t,len,int,advice)
#ifdef __NR_exit_group
_syscall1(int,exit_group,int,error_code)
#endif
@@ -4151,6 +4153,17 @@ long do_syscall(void *cpu_env, int num,
break;
}
#endif
+#ifdef TARGET_NR_fadvise64
+case TARGET_NR_fadvise64:
+ ret = get_errno(sys_fadvise64((int)arg1, arg2, arg3, (int)arg4));
+ break;
+#endif
+#ifdef TARGET_NR_fadvise64_64
+case TARGET_NR_fadvise64_64:
+ // fadvise64_64 should be just a wrapper for fadvise_64
+ ret = get_errno(sys_fadvise64((int)arg1, arg2, arg3, (int)arg4));
+ break;
+#endif
default:
unimplemented:
gemu_log("qemu: Unsupported syscall: %d\n", num);
Index: qemu-0.9.0/linux-user/i386/syscall_nr.h
===
--- qemu-0.9.0.orig/linux-user/i386/syscall_nr.h
+++ qemu-0.9.0/linux-user/i386/syscall_nr.h
@@ -272,3 +272,4 @@
#define TARGET_NR_clock_nanosleep (TARGET_NR_timer_create+8)
#define TARGET_NR_utimes 271
+#define TARGET_NR_fadvise64_64 272
Re: [Qemu-devel] [PATCH, RFC] Fix softfloat NaN handling
Blue Swirl wrote: > On 5/9/07, Thiemo Seufer <[EMAIL PROTECTED]> wrote: > >Hello All, > > > >The relevant IEEE standards don't define if a set or a clear bit is > >used to distinguish between QNaN and SNaN. MIPS, and apparently > >PA RISC, made a different choice than the rest of the industry. > > On Sparc, the rule is as follows: > > SNaN: sign undefined, exponent 255, mantissa 0xxx...and at least one > bit must be nonzero > QNaN: sign undefined, exponent 255, mantissa 1xxx... > > Is this the same as MIPS? For MIPS, and allegedly HPPA, the meaning of the highest bit in the mantissa is inverted. IOW, 0xxx... is a QNaN, 1xxx... is a SNaN. The rest is the same, and AFAIK mandated by the standard. Thiemo
[Qemu-devel] Re: [PATCH] configure
Thiemo Seufer <[EMAIL PROTECTED]> writes: > Joachim Henke wrote: >> On Wed, 2007-05-09 at 10:51 +0200, Juergen Keil wrote: >> > Isn't the use of "which" wrong, anyway? >> > >> > "which" belongs to csh/tcsh, and tells you about csh's/tcsh's idea >> > about a command or a csh command alias. >> > >> > IMO, for a /bin/sh (or bash) script, using the "type" command would >> > be a better idea. >> >> Yes, 'which' is not reliable. > > "type" appears to be bash-specific, at least according to the bash > documentation, so I stuck with "which" for now. You could use "command -v" from SUSv3. -- Ben Pfaff http://benpfaff.org
Re: [Qemu-devel] [PATCH] configure
"Jeff Chua" <[EMAIL PROTECTED]> writes: > # type awk > awk is /bin/awk > awk is /usr/bin/awk > # type -p awk > /bin/awk > /usr/bin/awk You are not using type, but type -a. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
[Qemu-devel] [PATCH] MIPS: support MMU selection at runtime #2
Hi, This patch is resent due to checkin of a 64 bit MMU. It removes the MIPS_USES_R4K_TLB define, and replaces it by some function pointers in the env structure. The model can be extended to support another TLB types quite easily (see translate_init.c) "No MMU" mode seems to not work, but it was also not working before this patch. Hervé dynamic_mmu_2.diff Description: Binary data
[Qemu-devel] [PATCH] Windows: redirect serial port to console
Hi, This patch adds the "-serial con:" option on Windows hosts, to redirect the serial port output to the console. Hervé serial_win_console.diff Description: Binary data
[Qemu-devel] [PATCH][MIPS] Fix for the scd instruction
Hi, The scd instruction is not correctly implemented. In op_mem.c a 1 or a 0 is returned in T0 depending on the success or not of the RMW sequence. However in translate.c, the result is never copied back to the register. The trivial patch below fixes that. Please also find below a boot of a 64-bit kernel on the MIPS target. I guess the next step is to implement 64-bit TLB. Bye, Aurelien (qemu) Linux version 2.6.21.1 ([EMAIL PROTECTED]) (gcc version 4.1.1 ()) #1 Sun May 6 21:43:32 CEST 2007 LINUX started... CPU revision is: 0400 FPU revision is: 00730400 registering PCI controller with io_map_base unset Determined physical RAM map: memory: 1000 @ (reserved) memory: 000ef000 @ 1000 (ROM data) memory: 00464000 @ 000f (reserved) memory: 07aab000 @ 00554000 (usable) Wasting 76384 bytes for tracking 1364 unused pages Initrd not found or empty - disabling initrd Built 1 zonelists. Total pages: 32320 Kernel command line: root=/dev/hda1 console=ttyS0 Primary instruction cache 4kB, physically tagged, direct mapped, linesize 16 bytes. Primary data cache 16kB, direct mapped, linesize 16 bytes. Unified secondary cache 128kB direct mapped, linesize 16 bytes. Synthesized TLB refill handler (39 instructions). Synthesized TLB load handler fastpath (51 instructions). Synthesized TLB store handler fastpath (51 instructions). Synthesized TLB modify handler fastpath (50 instructions). PID hash table entries: 512 (order: 9, 4096 bytes) CPU frequency 200.05 MHz Using 100.023 MHz high precision timer. Index: target-mips/translate.c === RCS file: /sources/qemu/qemu/target-mips/translate.c,v retrieving revision 1.70 diff -u -d -p -r1.70 translate.c --- target-mips/translate.c 9 May 2007 09:33:33 - 1.70 +++ target-mips/translate.c 9 May 2007 20:00:54 - @@ -745,6 +745,7 @@ static void gen_ldst (DisasContext *ctx, save_cpu_state(ctx, 1); GEN_LOAD_REG_TN(T1, rt); op_ldst(scd); +GEN_STORE_TN_REG(rt, T0); opn = "scd"; break; case OPC_LDL: -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net
[Qemu-devel] qemu vl.h hw/ide.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 07/05/09 20:25:36 Modified files: . : vl.h hw : ide.c Log message: PCMCIA addresses are 26-bit, widen the address type from 16 to 32 bits. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemu&r1=1.233&r2=1.234 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ide.c?cvsroot=qemu&r1=1.59&r2=1.60
[Qemu-devel] All the world's a VAX! - reloaded
Hello! Those of you who are old enough will remember that certain kinds of implicit assumptions in programming used to raise the outcry: All the world's a VAX! E.g. taking for granted that a pointer will always fit into an integer and vice versa. After trying Qemu for the first time and a long debugging session last weekend I'd like to suggest a new phrase for the current millennium: If it ain't Windows, it must be Linux! Please don't get me wrong, this is definitely not meant to be an insult, but I got quite frustrated short of banging my head against something. So, what happened? I have an old license of Windows 98 SE lying around and I was seeking a free way to run that on my old Powerbook G4. Luckily I own a fast Intel iMac as well that I could use for setup and later compiling, but the system was to run on the PowerPC CPU. Reason was a single Windows application that I need. It talks to my GPS receiver that I carry while paragliding via a serial port. I first tried Bochs. While a appreciate the effort and even used Bochs a couple of years ago to run Minix, it's far from usable for any real work in Windows. Next try: Qemu. Boy, was I surprised! Installing Windows 98 SE from CD took less than two hours, perceived speed about a 486 or Pentium I, quite usable. This was on the Intel iMac. Then I copied the finished Windows installation to the G4. Still good. Really good. I love the product. OK, documentation says, to setup COM1 to be passed to a serial port of the host system, add "-serial /dev/ttyXY". That was /dev/cu.KeySerial1 for my Keyspan USB serial adapter. This produced nothing but an error message like "could not open /dev/cu.KeySerial1". This is when the debugging session started. It ended to no avail. I'll spare you amount of times I looked at the access bits of the device, tried if I could open it with minicom and stuff like that, the workarounds with Unix domain sockets instead of the tty and socat, ... the true reason hit me like a hammer when I looked at the source of vl.c: #if defined(__linux__) /* all the code that deals with ttys */ #endif Wilma! Boys and girls, this code should run without modification on _any_ sufficiently recent variant of Unix. _Unix_. That's a whole class of operating systems adhering to certain API standards. It even includes Linux, now, ain't that great? And of course I proved it to run on Mac OS X in no time. Da, zeerial port beink workink now. So, please, please, please, don't make things that work perfectly almost everywhere depend on Linux. Why would you? End rant. Please don't take the tone too seriously. Now that I can use the serial port without a hitch, I really like Qmemu. All this was just so unnecessary. Kind regards, Patrick P.S. No, I don't have a patch, because what I did locally does not fix the problem. Once we change #if defined(__linux__) to #if defined(__linux__) || defined(__DARWIN__) we will in no time have to add || defined(__FreeBSD__) ... ... ad nauseam. -- punkt.de GmbH * Vorholzstr. 25 * 76137 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 [EMAIL PROTECTED] http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285
Re: [Qemu-devel] All the world's a VAX! - reloaded
In message: <[EMAIL PROTECTED]> "Patrick M. Hausen" <[EMAIL PROTECTED]> writes: : P.S. No, I don't have a patch, because what I did locally does : not fix the problem. Once we change : : #if defined(__linux__) : to : #if defined(__linux__) || defined(__DARWIN__) : : we will in no time have to add : : || defined(__FreeBSD__) : ... : ... #ifdef unix ... #endif is the traditional way to say this :-) Warner
Re: [Qemu-devel] All the world's a VAX! - reloaded
Hi Patrick, On Wed, 9 May 2007, Patrick M. Hausen wrote: > Boys and girls, this code should run without modification on > _any_ sufficiently recent variant of Unix. _Unix_. Even if you sound like a troll, I am heavily reminded of another widespread saying here: patches welcome. Talk is cheap, Dscho
Re: [Qemu-devel] Could any body fix the bug in gdbstub.c for x86_64?
On Wednesday 09 May 2007, MingyanGuo wrote: > Hi, > The -s option for qemu-system-x86_64 is not useable. > I've already post a patch, but it is ignored. > http://lists.gnu.org/archive/html/qemu-devel/2007-05/msg00062.html Please read the list archives for previous patches/discussions on this topic. Your patch is wrong in several ways Paul
[Qemu-devel] qemu exec-all.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/05/10 00:33:40 Modified files: . : exec-all.h Log message: Fix wrong branch condition in MIPS testandset. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/exec-all.h?cvsroot=qemu&r1=1.53&r2=1.54
[Qemu-devel] qemu/target-mips translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/05/10 00:51:01 Modified files: target-mips: translate.c Log message: Fix for the scd instruction, by Aurelien Jarno. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.70&r2=1.71
