I think the unsupported instruction is the rdhwr instruction. It's used to get the thread pointer which is used by many C library functions to access global variables that are defined thread-local these days (like errno, and the locale structure). If TLS is not supported, even very basic C library calls will fail.
In order to get basic TLS support working, I had to implement the set_thread_area syscall and the rdhwr instruction. The argument to set_thread_area is saved and then returned whenever rdhwr asks for it. I'll try to provide a patch to get TLS working in MIPS. I've got it working now, but it's hacked into m5-stable from several months ago, so it will take a bit of work to generate a patch that will apply cleanly to the head of the current development tree. On Mon, Dec 14, 2009 at 8:33 AM, Korey Sewell <[email protected]> wrote: > which inst in there is unsupported?... Does it not recognize the "move"??? > > On Sun, Dec 13, 2009 at 6:43 PM, Gabe Black <[email protected]> wrote: >> >> 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 > > > > -- > - Korey > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > > -- Cheers, Matt _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
