Hi Nicolas,
On Wed, May 24, 2017 at 11:28 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Great, you reproduced exact same behavior. The problem I have is effectively where to put the breakpoint. I think we can believe the output of (gdb) call printCallStack()
here's one issue; the computation to see if the frame pointer is in use fails. I'm executing this at the compilation break point for FilePath class>pathName:isEncoded:
(gdb) print /x CStackPointer $7 = 0xef91d0 (gdb) print /x CFramePointer $8 = 0x0 (gdb) print cFramePointerInUse $9 = 0 (gdb) info registers rax 0x68588f 6838415 rbx 0xffffffff 4294967295 rcx 0x68588f 6838415 rdx 0xabababab003a643a -6076574521274768326 rsi 0xfde9 65001 rdi 0x0 0 rbp 0xef5db0 0xef5db0 rsp 0xef5c50 0xef5c50 r8 0x0 0 r9 0xfffffffffbefbc48 -68174776 r10 0xe36e626d44726839 -2058599758222432199 r11 0x8101010101010100 -9151031864016699136 r12 0xffffffff 4294967295 r13 0x20 32 r14 0x7ffc202018f0 140720847460592 r15 0xf2faf0 15923952 rip 0x4015d9 0x4015d9 <warning+9> eflags 0x206 [ PF IF ] cs 0x33 51 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x53 83 gs 0x2b 43 (gdb)
I've tried other means:
- analyze direct usage of registers RCX & co from VMMaker if ever it could conflicts with WIN64 logical register assignment But I did not find anything
- compile with MSVC 2017 if ever the compiler could spit different warnings and give a clue alas it fails very early in readImageFromFileHeapSizeStartingAt (during
checkAssumedCompactClasses) the failure is incomprehensible, because the debugger shows identical contents if I print:
*((sqInt *)(classTableFirstPage+8+(51<<3))) 140697255509608__int64 *((sqInt *)(specialObjectsOop+8+(7<<3))) 140697255509608 __int64
nonetheless, the debugger enters into the if and execute invalidCompactClassError("Array");
I'll have to debug it at assembler level, but it's driving me away from the original problem...
Hmmm. I doubt this is a problem because the assert and debug VMs would print a warning if this were wrong and they seem to be doing fine (I'm using the clang build).
2017-05-25 2:38 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Nicolas,
the VM gets quite far before some unknown problem in path namemanipulation. I'm drunning the debug VM under gdb via (gdb) run -trace=259 trunk50-64.image (See Cogit>>sendTrace: for a definition of the flags)
and this is the output
... UnixFileDirectory class>pathNameDelimiter Array(Object)>at: BlockClosure>value: AcornFileDirectory class>isActiveDirectoryClass SmalltalkImage>getSystemAttribute: ByteString(String)>isString ByteString(ArrayedCollection)>size ByteString(ArrayedCollection)>size SmallInteger>= Array(Object)>at: BlockClosure>value: MacFileDirectory class>isActiveDirectoryClass MacFileDirectory class>pathNameDelimiter Character>= Array(Object)>at: BlockClosure>value: DosFileDirectory class(FileDirectory class)>isActiveDirectoryClass DosFileDirectory class>pathNameDelimiter DosFileDirectory class(FileDirectory class)>primPathNameDelimiter Character>= FilePath class>pathName: FilePath class>pathName:isEncoded:
Alas there's no debug information to be had:
(gdb) where #0 0x00000000000008d4 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?)
So my next step is to put a breakpoint for the selector #pathName:isEncoded: and step from there.
(gdb) b warning Breakpoint 1 at 0x4015d9: file ../../spur64src/vm/gcc3x-cointerp.c, line 44. (gdb) run -breaksel pathName:isEncoded: trunk50-64.image The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /cygdrive/z/oscogvm/build.win6 4x64/squeak.cog.spur/builddbg/vm/Squeak.exe -breaksel pathName:isEncoded: trunk50-64.image [New Thread 4080.0x5ec] [New Thread 4080.0xb30] etc...
_,,,^..^,,,_ best, Eliot