Right, so I have my own debug VM (64 bit Pharo Cog) and a debug version of libclang.

I can attach with lldb and set a breakpoint on clang_getRangeStart

Then I debug the test that gets diagnostics and I see that the CXSourceRange has data.  Then I step into 'range start' and I land in my breakpoint for clang_getRangeStart and I can see that the argument to the function - supposedly a CXSourceRange passed by value - is all zero'd memory.

So it appears that in the 64bit VM, structs passed by value doesn't work right.

I've traced back up the stack and I confess the marshaling code is totally beyond my comprehension.  This is what I was able to get:

Process 1126 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 2.1
    frame #0: 0x000000011e33136b libclang.dylib`::clang_getRangeStart(range=CXSourceRange @ 0x00007fff55f4e380) at CXSourceLocation.cpp:89
   86    
   87  CXSourceLocation clang_getRangeStart(CXSourceRange range) {
   88    // Special decoding for CXSourceLocations for CXLoadedDiagnostics.
-> 89    if ((uintptr_t)range.ptr_data[0] & 0x1) {
   90      CXSourceLocation Result = { { range.ptr_data[0], nullptr }, 0 };
   91      return Result;    
   92    }
Target 0: (Pharo) stopped.
(lldb) p range
(CXSourceRange) $0 = {
  ptr_data = ([0] = 0x0000000000000000, [1] = 0x0000000000000000)
  begin_int_data = 0
  end_int_data = 0
}
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 2.1
  * frame #0: 0x000000011e33136b libclang.dylib`::clang_getRangeStart(range=CXSourceRange @ 0x00007fff55f4e380) at CXSourceLocation.cpp:89
    frame #1: 0x0000000109e20b5a Pharo`primitiveCalloutWithArgs at X64SysVFFIPlugin.c:6041
    frame #2: 0x0000000109cb964c Pharo`primitiveExternalCall at gcc3x-cointerp.c:77188
    frame #3: 0x0000000109cb1629 Pharo`interpretMethodFromMachineCode at gcc3x-cointerp.c:19719
    frame #4: 0x0000000109cb77fc Pharo`ceSendsupertonumArgs(selector=4713336760, superNormalBar=0, rcvr=4692466872, numArgs=1) at gcc3x-cointerp.c:17767
    frame #5: 0x000000011774a135
    frame #6: 0x0000000109c76227 Pharo`interpret at gcc3x-cointerp.c:2703
    frame #7: 0x0000000109dbbf31 Pharo`-[sqSqueakMainApplication runSqueak](self=0x00006080000d7370, _cmd="runSqueak") at sqSqueakMainApplication.m:201
    frame #8: 0x00007fff81e5a8dd Foundation`__NSFirePerformWithOrder + 368
    frame #9: 0x00007fff803b1d37 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
    frame #10: 0x00007fff803b1ca7 CoreFoundation`__CFRunLoopDoObservers + 391
    frame #11: 0x00007fff803926d9 CoreFoundation`__CFRunLoopRun + 873
    frame #12: 0x00007fff80392114 CoreFoundation`CFRunLoopRunSpecific + 420
    frame #13: 0x00007fff7f8f2ebc HIToolbox`RunCurrentEventLoopInMode + 240
    frame #14: 0x00007fff7f8f2bf9 HIToolbox`ReceiveNextEventCommon + 184
    frame #15: 0x00007fff7f8f2b26 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 71
    frame #16: 0x00007fff7de89a54 AppKit`_DPSNextEvent + 1120
    frame #17: 0x00007fff7e6057ee AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2796
    frame #18: 0x00007fff7de7e3db AppKit`-[NSApplication run] + 926
    frame #19: 0x00007fff7de48e0e AppKit`NSApplicationMain + 1237
    frame #20: 0x0000000109db5baf Pharo`main(argc=1, argv=0x00007fff55f8bca8, envp=0x00007fff55f8bcb8) at main.m:52
    frame #21: 0x00007fff95b18235 libdyld.dylib`start + 1
    frame #22: 0x00007fff95b18235 libdyld.dylib`start + 1
(lldb) up
frame #1: 0x0000000109e20b5a Pharo`primitiveCalloutWithArgs at X64SysVFFIPlugin.c:6041
   6038 result2 = floatObjectOf(floatRet1);
   6039 goto l14;
   6040 }
-> 6041 intRet1 = dispatchFunctionPointerwithwithwithwithwithwith(((SixteenByteReturn (*)(sqIntptr_t, sqIntptr_t, sqIntptr_t, sqIntptr_t, sqIntptr_t, sqIntptr_t)) (((void *) address2))), ((calloutState1->integerRegisters))[0], ((calloutState1->integerRegisters))[1], ((calloutState1->integerRegisters))[2], ((calloutState1->integerRegisters))[3], ((calloutState1->integerRegisters))[4], ((calloutState1->integerRegisters))[5]);
   6042 /* begin maybeOwnVM:threadIndex: */
   6043
   6044 #  if COGMTVM

The struct that should have shown up appears in Pharo as 

"CXSourceRangeStruct ( 
ptr_data1: (void*)@ 16r7FDF356C77B0
ptr_data2: (void*)@ 16r7FDF356D0C70
begin_int_data: 21
end_int_data: 28
)"

Open to ideas at this point but I think to progress I would require deep knowledge of Intel calling conventions and I don't really know where to go next.

Try to isolate the functions into a little dynamic lib and file a bug?

On Nov 14, 2017, at 4:34 PM, Ben Coman <btc@openinworld.com> wrote:



On 15 November 2017 at 00:07, Todd Blanchard <tblanchard@mac.com> wrote:
I've got it loaded, have fixed up the library path and fixed the test for version (built in lib returns very different version string).

I have many tests green.  However, as before, tests involving CXSourceRange that return CXSourceLocations return all zero'd data.  The CXSourceRange struct looks sane.

The calls to CXSourceLocation clang_getRangeStart(CXSourceRange range);

and its twin RangeEnd result in zero'd structs.

Any idea on where I can look to try to figure out where this is going wrong?  

I have compiled little C programs and verified that both struct sizes agree in FFI and native code (24 bytes each).

Not sure what to try next.
 c
-Todd Blanchard

Compile your own debug-VM** and make a little C wrapper MyCXSourceRange to forward to Clang's CXSourceRange, and set a gdb a breakpoint in MyCXSourceRange and compare 64 bit and 32 bit versions.  

That still leaves differences in the callout before your breakpoint in MyCXSourceRange is reached, so just do two callouts in a row and trace from the first to the second. 

** https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/Cog/build.linux64x64/pharo.cog.spur/build.debug

cheers -ben