Re: GC and stack marking

[Eli Zaretskii]

> Date: Thu, 22 May 2014 10:59:00 -0400
> From: Barry OReilly <address@hidden>
> Cc: address@hidden
> 
> > Yes. I looked at all the local variables in that stack frame, and
> > their addresses on the stack are different from the one that
> > triggers the problem.
> 
> [I assume you mean "void* values on the stack" rather than "addresses
> on the stack".]

No, I meant addresses on the stack.  Like this:

 (gdb) info locals
 foo = 0xbaadf00d
 bar = 191919191
 baz = 0 '\000'
 (gdb) p/x &foo
 $1 = 0x12345678
 (gdb) p/x &bar
 $2 = 0x23456789
 (gdb) p/x &baz
 $3 = 0x87654321

I compared these addresses with the value the 'pp' variable had in
mark_memory, here:

  for (pp = start; (void *) pp < end; pp++)
    for (i = 0; i < sizeof *pp; i += GC_POINTER_ALIGNMENT)
      {
        void *p = *(void **) ((char *) pp + i);
        mark_maybe_pointer (p);
        if (POINTERS_MIGHT_HIDE_IN_OBJECTS)
          mark_maybe_object (XIL ((intptr_t) p));
      }

when the value of 'p' was the address of the hash-table struct that
was passed to mark_maybe_pointer.

> So when you printed the value of a one byte variable like
> stack_top_variable, you printed it with any alignment padding there
> might be?

I didn't print any values, just the addresses, see above.  That's
because I already knew the address of the stack slot where the
offending value was stored, so I didn't need to look for it.  That
address was the value of 'pp' above.

> And you accounted for the compiler reordering stack variables, eg to
> more optimally align data?

Yes, in a way: I looked at the disassembly of the offending function,
and reviewed every reference to a stack slot via $ebp and $esp.  Since
I knew the values of $ebp and $esp of that function when mark_stack
was called, and I also knew the address of the stack slot where the
offending value was stored, it was simple to calculate the offsets
from $ebp and $esp corresponding to that stack slot.  I looked for
those offsets in the disassembly, but they weren't there.

> I confirmed for example that stack_top_variable and message_p are
> allocated next to each other on the stack in my build, with the i
> variable not between them in memory.

Again, I checked all the locals in that function, and I also checked
all the references to the stack in the disassembly, thus accounting
for temporary values that have no C variables in the source.  I think
this covers all the possibilities, and isn't affected by how the
compiler allocates the variables on the stack.