[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