[Vm-dev] Debugging Win64 Cog Spur

Eliot Miranda eliot.miranda at gmail.com
Thu May 25 15:49:07 UTC 2017


Hi Nicolas,

On Wed, May 24, 2017 at 11:28 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at 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 at gmail.com>:
>
>> Hi Nicolas,
>>
>>     the VM gets quite far before some unknown problem in path name
>> manipulation.  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
>>
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170525/cffbe933/attachment.html>


More information about the Vm-dev mailing list