I actually just ran into and straightened out (I think) the syscall interface issue. I basically added the missing calls and set set_thread_area to ignoreFunc. Now I'm running into an unsupported instruction in __current_locale_name which gdb doesn't seem to understand either. Any idea how this should be handled?
0x00453720 <__current_locale_name+0>: lui gp,0x4b 0x00453724 <__current_locale_name+4>: addiu gp,gp,32544 0x00453728 <__current_locale_name+8>: 0x7c03e83b 0x0045372c <__current_locale_name+12>: move v0,v1 0x00453730 <__current_locale_name+16>: lw v1,-30160(gp) 0x00453734 <__current_locale_name+20>: addiu a0,a0,16 0x00453738 <__current_locale_name+24>: addu v0,v1,v0 0x0045373c <__current_locale_name+28>: lw v0,0(v0) 0x00453740 <__current_locale_name+32>: sll a0,a0,0x2 0x00453744 <__current_locale_name+36>: addu v0,v0,a0 0x00453748 <__current_locale_name+40>: lw v0,0(v0) 0x0045374c <__current_locale_name+44>: jr ra 0x00453750 <__current_locale_name+48>: nop Gabe Matt wrote: > Attached is the simple C source and the compiled MIPS binary that adds > two doubles and prints the result. > The binary was compiled with my cross compiler which is GCC 4.4.1 > linked with EGLIBC 2.10.1 with Linux 2.6.29.6 headers. Hopefully this > binary will work for you; I've made some modifications to my copy of > M5 to get it to handle some of the more recent changes to the Linux > MIPS syscall interface. So hopefully, since this is a pretty simple > little program, it won't do anything your version of M5 doesn't yet > support. > > On Sat, Dec 12, 2009 at 4:54 PM, Gabe Black <[email protected]> wrote: > >> Matt wrote: >> >>> I'm having problems getting double-precision floating-point to work in >>> m5 for the MIPS isa. >>> >>> The 32-bit MIPS isa has 32 32-bit floating-point registers. >>> Double-precision floating-point numbers are stored in pairs of >>> floating-point registers. At least that's how I understand it. >>> >>> Simple floating point math used to work in m5 until changeset >>> 781969fbeca9. After the change, it seams that m5 does not read two >>> 32-bit floating point registers to get a double-precision >>> floating-point operand, but only one 32-bit floating-point register >>> (when it's simulating an add_d instruction, for example). This >>> results in incorrect floating point arithmetic. >>> >>> I have the following C program (compiled for MIPS) that exercises the >>> problem: >>> >>> #include<stdio.h> >>> >>> int main (void) >>> { >>> double x, y, z; >>> >>> x = 5.0; >>> y = 0.1; >>> >>> z = x + y; >>> >>> printf ("z = %lf\n", z); >>> >>> return 0; >>> } >>> >>> It should print "z = 5.1", but it doesn't because the simulation of >>> the floating-point addition is wrong. >>> >>> Can anyone tell me why this change was made that seems to break the >>> simulation of double-precision floating-point arithmetic in m5? >>> >>> Thanks. >>> >>> >>> >> Could you send out a compiled version of your test program please? I'm >> having some problems getting the cross compiler working. >> >> Gabe >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> >> > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
