Re: Hacking Lua for debug information

[Peter Cawley <lua@...>]

On Sun, Mar 18, 2012 at 1:08 AM, Florian Hester <florian@celaeno.org> wrote:
> So, am i doing something which i simply should not be doing, debugging or
> otherwise, or is there truly something screwy going on?

I believe that your Windows liblua.a is using NaN-packed 8-byte
TValues, while your main.c is picking up the definitions for naive
16-byte TValues. If the Linux output is placed along-side the Windows
output, and each line of Windows output is paired with two lines of
Linux output, then we get the following:

gc pointer: 0x23f3fe0   N/A
gc pointer: 0x23f4030   gc pointer: 003e4140
gc pointer: 0x23f4030   N/A
str value: Foo          gc pointer: 003e37b0
nr value: 5.200000      N/A
nr value: -3.223000     gc pointer: 39581062
str value: Foo          N/A
nr value: 10.823300     gc pointer: 93dd97f6
str value: Bar          N/A
gc pointer: 0x23f40e0   gc pointer: 003e41a8
gc pointer: 0x23f4130   N/A
N/A                     gc pointer: baadf00d
N/A                     N/A
N/A                     gc pointer: baadf00d
...

If your Windows TValues were indeed NaN-packed then your type code
extraction will almost certainly give a random value, explaining why
it always said "gc pointer". Furthermore, number values would almost
certainly not look like heap pointers, while non-number values would
look like heap pointers. Finally, pointers beyond the end of memory
would come out as a sentinel value. All of these things match what is
seen.