On Dec-11, Tanton Gibbs wrote: > I'm still not sure what the problem is...but if you turn --gc-debug > off, then the array diminsions are correct...e.g., 10 for the first > dimension. Therefore, the calculation of the array index is > performed correctly. However, with --gc-debug on, the array > dimension is correct for the first dimension (0,0 - 0,20) as well as > the first element of the first dimension...(1,0). But it is wrong > for all of the others. It becomes 1 instead of 10. I have no clue > yet why...still looking into it. However, all tests pass on Tru64 if > --gc-debug is off.
Are the Tru64 registers scanned for live PMCs/Buffers? I don't know what things would typically get missed that way, but it's a known problem for most architectures (or was until recently? What's the status on this?) Does Tru64 have hardware breakpoints? They're nice for this sort of thing -- find a value that eventually becomes incorrect, take the address of it at a point when it is still correct, then watch what it points to: (gdb) p interpreter->ctx.pmc_reg.registers[0]->cache.int_val $6 = 1 (gdb) p &interpreter->ctx.pmc_reg.registers[0]->cache.int_val $7 = (INTVAL *) 0x810c904 (gdb) watch *$7 Hardware watchpoint 2: *$7 (gdb) continue . . . Except that the garbage collector tends to move stuff around, which can defeat this scheme. I doubt any of this was useful, but just in case...
