Re: [Pharo-users] FFI 64 bit libClang issue on Sierra.

2017-11-16 Thread Todd Blanchard 
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: 0x00011e33136b 
libclang.dylib`::clang_getRangeStart(range=CXSourceRange @ 0x7fff55f4e380) 
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] = 0x, [1] = 0x)
  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: 0x00011e33136b 
libclang.dylib`::clang_getRangeStart(range=CXSourceRange @ 0x7fff55f4e380) 
at CXSourceLocation.cpp:89
frame #1: 0x000109e20b5a Pharo`primitiveCalloutWithArgs at 
X64SysVFFIPlugin.c:6041
frame #2: 0x000109cb964c Pharo`primitiveExternalCall at 
gcc3x-cointerp.c:77188
frame #3: 0x000109cb1629 Pharo`interpretMethodFromMachineCode at 
gcc3x-cointerp.c:19719
frame #4: 0x000109cb77fc 
Pharo`ceSendsupertonumArgs(selector=4713336760, superNormalBar=0, 
rcvr=4692466872, numArgs=1) at gcc3x-cointerp.c:17767
frame #5: 0x00011774a135
frame #6: 0x000109c76227 Pharo`interpret at gcc3x-cointerp.c:2703
frame #7: 0x000109dbbf31 Pharo`-[sqSqueakMainApplication 
runSqueak](self=0x608d7370, _cmd="runSqueak") at 
sqSqueakMainApplication.m:201
frame #8: 0x7fff81e5a8dd Foundation`__NSFirePerformWithOrder + 368
frame #9: 0x7fff803b1d37 
CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 
23
frame #10: 0x7fff803b1ca7 CoreFoundation`__CFRunLoopDoObservers + 391
frame #11: 0x7fff803926d9 CoreFoundation`__CFRunLoopRun + 873
frame #12: 0x7fff80392114 CoreFoundation`CFRunLoopRunSpecific + 420
frame #13: 0x7fff7f8f2ebc HIToolbox`RunCurrentEventLoopInMode + 240
frame #14: 0x7fff7f8f2bf9 HIToolbox`ReceiveNextEventCommon + 184
frame #15: 0x7fff7f8f2b26 
HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 71
frame #16: 0x7fff7de89a54 AppKit`_DPSNextEvent + 1120
frame #17: 0x7fff7e6057ee AppKit`-[NSApplication(NSEvent) 
_nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2796
frame #18: 0x7fff7de7e3db AppKit`-[NSApplication run] + 926
frame #19: 0x7fff7de48e0e AppKit`NSApplicationMain + 1237
frame #20: 0x000109db5baf Pharo`main(argc=1, argv=0x7fff55f8bca8, 
envp=0x7fff55f8bcb8) at main.m:52
frame #21: 0x7fff95b18235 libdyld.dylib`start + 1
frame #22: 0x7fff95b18235 libdyld.dylib`start + 1
(lldb) up
frame #1: 0x000109e20b5a 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  wrote:
> 
> 
> 
> On 15 November 2017 at 00:07, Todd Blanchard  > wrote:
> I've got it loaded, have fixed up the library path and fixed the test for

Re: [Pharo-users] FFI 64 bit libClang issue on Sierra.

2017-11-14 Thread Ben Coman 
On 15 November 2017 at 00:07, Todd Blanchard  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