[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: and/or missbehaviour in embedded lua 5.1
- From: Kein-Hong Man <mkh@...>
- Date: Fri, 17 Mar 2006 11:56:43 +0800
Andreas Stenius wrote:
Kein-Hong Man skrev:
Andreas Stenius wrote:
1.0890312344636e-60 = E0FFFFFF05007C33
2.1436356971487e-228 = 000000001100AA10
The first 4 bytes look mighty suspicious... since the expression is
essentially the same but your earlier sample (=true and 0) gave a
different value, I guess something is broken. Without more
information, it's almost impossible for anyone on the list to diagnose
what had caused it; we would be only speculating.
Something is most certainly broken. I'm still poking around to find out
where, and I can't really let go of the idea it lies some where in
the lua sources.. I do get the correct value when used with variable
lookup (as shown earlier). Part of my struggle is that I unfortuanetly
doesn't have a
debugger for my target, so I can't step through the c-code, and it's
quite tedious process downloading after each recompile, so it all adds
up and takes quite alot of time..
Since the problem is due to the code generator producing a
funny-looking constant, debugging information would be the most
helpful thing now. We have pinpointed the problem, we just need to
know why those constants are generated. Even if there is a config
workaround, I think it's worth getting to the bottom of this and
finding out exactly why it happens. It would be valuable to other
users on the list who use Lua in embedding.
I did miss to point out that I got the different strange value after a
recompile. Which, as you say, suggests something weird with the code
But it still would be in interaction with the lua sources how the code
is used that generates bad code (which would be a bug in the compiler
non the less, but
it should be able to come to a work-around for that).
it's little endian, and lua_Number is double.
It should be like x86 except for int... hmmm... yeah, the
debugging nightmare would be if it's a problem with the C
compiler. So it could be any one of the following:
(a) some place in the code generator doesn't like an int of 2 and
(b) C compiler miscompiles the code generator due to the way it
interprets C, some lack of information, some kind of shortcut
taken or an internal bug
(c) double type problem due to math library or conversion
Without a debugger, peppering lcode.c with printfs should be fine.
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia