Re: [Flightgear-devel] Persistant Nasal big-endian bug
Andy Ross wrote: Erik Hofman wrote: Ok, I've test compiled the simgear/nasal library using gcc on IRIX and linked it with the MIPSpro build version of FlightGear and it's working like a charm. Now remains the question, is it an exploited gcc bug/feature or is it really a MIPSpro bug? I've personally built and tested it using the Sun Studio compiler on Sparc, and the windows builds are done using MSVC. That proves nothing, of course, but if code were a democracy MIPSpro would be losing 3:1. :) Yeah, the only reason (if it isn't a bug) would be because I know for certain that MIPSpro doesn't initialize pointers to NULL. I don't know about other compilers. Note that the naRef structure is a nested union, and the code makes heavy use of structure assignment of these things. That's not a common idiom (most other interpreters just use casts), so I wouldn't be shocked if it triggered a bug or two. There's one spot in there already (I forget who found it -- not me, anyway) with a workaround for a gcc 2.95 code generation bug. If you want to continue tracking this down, you could try starting with a gcc library, and replace each .o file in turn with a MIPSpro one to figure out where the faulty code generation is (it might be more than one location, of course), then start moving code out symbol-by-symbol until you zero in on the location. Then we can try to rewrite it so it compiles correctly. I plan on doing so, but not before the official 0.9.9 release. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Persistant Nasal big-endian bug
Andy Ross wrote: Again: I've run fairly rigorous tests on both Sparc and PPC at this point with no failures, so I think we've pretty much ruled out endianness. Ok, I've test compiled the simgear/nasal library using gcc on IRIX and linked it with the MIPSpro build version of FlightGear and it's working like a charm. Now remains the question, is it an exploited gcc bug/feature or is it really a MIPSpro bug? I've asked others to send me a version of FlightGear compiled with the latest version of MIPSpro but have had no response so far. The good thing is that I now have a way to distribute FlightGear 0.9.9 and 1.0 for IRIX. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Persistant Nasal big-endian bug
Erik Hofman wrote: Ok, I've test compiled the simgear/nasal library using gcc on IRIX and linked it with the MIPSpro build version of FlightGear and it's working like a charm. great sigh of relief Excellent. Thanks for your work, I was completely out of ideas on this. :) Ok, I've test compiled the simgear/nasal library using gcc on IRIX and linked it with the MIPSpro build version of FlightGear and it's working like a charm. Now remains the question, is it an exploited gcc bug/feature or is it really a MIPSpro bug? I've personally built and tested it using the Sun Studio compiler on Sparc, and the windows builds are done using MSVC. That proves nothing, of course, but if code were a democracy MIPSpro would be losing 3:1. :) Note that the naRef structure is a nested union, and the code makes heavy use of structure assignment of these things. That's not a common idiom (most other interpreters just use casts), so I wouldn't be shocked if it triggered a bug or two. There's one spot in there already (I forget who found it -- not me, anyway) with a workaround for a gcc 2.95 code generation bug. If you want to continue tracking this down, you could try starting with a gcc library, and replace each .o file in turn with a MIPSpro one to figure out where the faulty code generation is (it might be more than one location, of course), then start moving code out symbol-by-symbol until you zero in on the location. Then we can try to rewrite it so it compiles correctly. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Persistant Nasal big-endian bug
Hi Andy, Since you've not yet responded to my questions I assume you've been busy lately? So far I've tracked down the problem to the getMember() function simgear/nasal/code.c. The problem starts to appear when ctx-opTop increments from 2 to 3 in which case obj.ref.reftag isn't valid anymore. Any ideas? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Persistant Nasal big-endian bug
Erik Hofman wrote: So far I've tracked down the problem to the getMember() function simgear/nasal/code.c. The problem starts to appear when ctx-opTop increments from 2 to 3 in which case obj.ref.reftag isn't valid anymore. If it's not happening across a garbage collection, then I strongly suspect a compiler bug. Note that opTop is only modified when a new reference (with valid reftag) has been pushed on the stack. Have you tried turning off optimization in the Nasal code? No need to do it for the whole project; just hand-modifying the simgear/nasal/Makefile should be sufficient. Again: I've run fairly rigorous tests on both Sparc and PPC at this point with no failures, so I think we've pretty much ruled out endianness. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Persistant Nasal big-endian bug
Andy Ross wrote: If it's not happening across a garbage collection, then I strongly suspect a compiler bug. Note that opTop is only modified when a new reference (with valid reftag) has been pushed on the stack. This section does look fushy to me (code.c setupFuncall()): naRef result = (*fp)(ctx, obj, nargs, frame + 1); ctx-opTop -= nargs + 1 + mcall; PUSH(result); Is is certain that reftag is set in this case? Have you tried turning off optimization in the Nasal code? No need to do it for the whole project; just hand-modifying the simgear/nasal/Makefile should be sufficient. Yep, to no avail. Again: I've run fairly rigorous tests on both Sparc and PPC at this point with no failures, so I think we've pretty much ruled out endianness. Did you use gcc on all those platforms? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Persistant Nasal big-endian bug
Erik Hofman wrote: Is is certain that reftag is set in this case? Yes. The modification to opTop is a pop, the stack contents have already been pushed at that point. I just scanned through the loop again, and don't see anywhere that an object gets copied onto the stack incorrectly -- the only way it's done is to copy the whole naRef at once, which copies the reftag also. Even a garbage collection wouldn't cause this behavior, as it would clean up the pointed-to object and not the reference on the stack. Note, by the way, that reftag is not guaranteed to be present -- if the naRef is a number, you will see the (non-NaN) top half of the double instead. The behavior you are seeing is consistent with a number being stored in the local variable hash in the slot where you used to see an object. No idea why that might happen either. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
