Hi David Finally sat down and re-ran the test cases with some debug info.
For the TestBlockAssignment test case, the type inside LoadValueOfTypeAtOffsetFromObject() is '@' (as below): className = FilteredStringPrinter ivarName = myBlock type = @ offset = 4 The results of the other test cases I run were different, but I don't know how to debug them (they are crashing inside llvm:ExtractTypeInfo()). Thanks Chris On 20/10/2010, at 23:28 PM, David Chisnall wrote: > > On 20 Oct 2010, at 00:19, Christopher Armstrong wrote: > >> Hi David >> >> I think I'm running 32bit Linux, as uname -a gives me i686. It is an SMP >> kernel. >> >> I compiled clang in release mode, but tried compiling LanguageKit in >> debug mode. When I attach GDB to edlc, I can't seem to get the type >> encoding parameter for LoadValueOfTypeAtOffsetFromObject(), as my call >> stack is corrupted. Should I try LLVM/Clang in debug mode? > > You can just add a printf() statement in there? > >> If you note below when I run edlc in interpreter mode, the exception >> thrown if about not supporting type conversion for '^' - is this what >> you were looking for? > > Yup, I think that's probably it. There's a very ugly hack to work around the > braindead calling convention on Linux. LKObject is a union of a SmallInt and > an id. We pretend that we are really passing a pointer to this union, so the > encoding is something like ^(LKObject_hack=i@). > > This needs special-casing everywhere. I don't think I've done it at all in > the interpreter, so ignore that for now. I should have done it in the > compiler, however. > >> Interestingly, some stuff works with the interpreter, but not always >> i.e. it sometimes just segmentation faults. > > You should only see problems with the interpreter for messages that can > return small ints, or take them as an argument. > >> I'll take a better look tonight. >> >> Thanks again >> Chris >> >> On Tue, 19 Oct 2010 13:02 +0100, "David Chisnall" <[email protected]> >> wrote: >>> Hmm, these all seem to be caused by the ugly hack that's needed for >>> mapping Smalltalk objects to Objective-C objects / SmallInt typedefs. >>> The problem is that Linux uses a braindead calling convention where a >>> union of two pointer-sized quantities is passed on the stack, rather than >>> in a register. >>> >>> I am not sure this is actually needed on 64-bit Linux; you can try >>> commenting out the #define BRAINDEAD_ABI in LKObject.h. >>> >>> It is needed on 32-bit Linux, so I'll have a look at the issue there. >>> When the assertion fails in LoadValueOfTypeAtOffsetFromObject(), can you >>> tell me what the type encoding is? >>> >>> David >>> >>> On 19 Oct 2010, at 11:39, Christopher Armstrong wrote: >>> >>>> Hi David >>>> >>>> Thanks for fixing that error so quickly, but now I have new set :-(. If it >>>> helps, I'm running Debian 5.0 i686 under VMWare Fusion 2.0 on an Intel >>>> Macbook. I've tried compiling in debug mode, but the stack traces are >>>> useless. >>>> >>>> It randomly segfaults, but most of the time I get stuff like this: >>>> >>>> ch...@debian:~/etoile/Etoile/Languages/Smalltalk/Tests/TestBlockAssignment$ >>>> edlc -f test.st >>>> edlc: CodeGenLexicalScope.cpp:1025: llvm::Value >>>> *CodeGenLexicalScope::LoadValueOfTypeAtOffsetFromObject(const char *, >>>> const char *, const char *, unsigned int, llvm::Value *): Assertion >>>> `isLKObject(type)' failed. >>>> Aborted >>>> ch...@debian:~/etoile/Etoile/Languages/Smalltalk/Tests/TestBlockAssignment$ >>>> edlc -i -f test.st >>>> 2010-10-16 23:48:48.230 edlc[26090] <NSException: 0x9460a10> >>>> NAME:LKInterpreterException REASON:ObjC to FFI type conversion not >>>> supported for '^' INFO:(nil) >>>> 2010-10-16 23:48:48.231 edlc[26090] Failed to compile input. >>>> >>>> In another case: >>>> >>>> ch...@debian:~/etoile/Etoile/Languages/Smalltalk/Tests/TestBlockAssignment$ >>>> cd ../TestBlockReturn >>>> ch...@debian:~/etoile/Etoile/Languages/Smalltalk/Tests/TestBlockReturn$ >>>> edlc -f test.st >>>> edlc: Analysis.cpp:121: llvm::GlobalVariable* >>>> llvm::ExtractTypeInfo(llvm::Value*): Assertion `(GV || >>>> isa<ConstantPointerNull>(V)) && "TypeInfo must be a global variable or >>>> NULL"' failed. >>>> Stack dump: >>>> 0. Running pass 'X86 DAG->DAG Instruction Selection' on function >>>> '@_i_SmalltalkTool__run' >>>> Aborted >>>> ch...@debian:~/etoile/Etoile/Languages/Smalltalk/Tests/TestBlockReturn$ >>>> ch...@debian:~/etoile/Etoile/Languages/Smalltalk/Tests/TestBlockReturn$ >>>> edlc -i -f test.st >>>> 2010-10-16 23:50:15.770 edlc[26095] <NSException: 0xb5703538> >>>> NAME:LKInterpreterException REASON:ObjC to FFI type conversion not >>>> supported for '^' INFO:(nil) >>>> 2010-10-16 23:50:15.770 edlc[26095] Failed to compile input. >>>> >>>> And another case (with non-deterministic results): >>>> >>>> ch...@debian:~/etoile/Etoile/Languages/Smalltalk/Tests/TestCascadedMessages$ >>>> edlc -f test.st >>>> edlc: Analysis.cpp:121: llvm::GlobalVariable* >>>> llvm::ExtractTypeInfo(llvm::Value*): Assertion `(GV || >>>> isa<ConstantPointerNull>(V)) && "TypeInfo must be a global variable or >>>> NULL"' failed. >>>> Stack dump: >>>> 0. Running pass 'X86 DAG->DAG Instruction Selection' on function >>>> '@_i_SmalltalkTool__run' >>>> Aborted >>>> ch...@debian:~/etoile/Etoile/Languages/Smalltalk/Tests/TestCascadedMessages$ >>>> edlc -i -f test.st >>>> Segmentation fault >>>> ch...@debian:~/etoile/Etoile/Languages/Smalltalk/Tests/TestCascadedMessages$ >>>> edlc -i -f test.st >>>> A simple test? >>>> ch...@debian:~/etoile/Etoile/Languages/Smalltalk/Tests/TestCascadedMessages$ >>>> edlc -i -f test.st >>>> Segmentation fault >>>> >>>> But interestingly, some stuff seems to work: >>>> >>>> ch...@debian:~/etoile/Etoile/Languages/Smalltalk/Tests/TestClassMethods1$ >>>> edlc -f test.st >>>> edlc: Analysis.cpp:121: llvm::GlobalVariable* >>>> llvm::ExtractTypeInfo(llvm::Value*): Assertion `(GV || >>>> isa<ConstantPointerNull>(V)) && "TypeInfo must be a global variable or >>>> NULL"' failed. >>>> Stack dump: >>>> 0. Running pass 'X86 DAG->DAG Instruction Selection' on function >>>> '@_i_SmalltalkTool__run' >>>> Aborted >>>> ch...@debian:~/etoile/Etoile/Languages/Smalltalk/Tests/TestClassMethods1$ >>>> edlc -i -f test.st >>>> simple class method invocation >>>> simple class method invocation 2 >>>> ch...@debian:~/etoile/Etoile/Languages/Smalltalk/Tests/TestClassMethods1$ >>>> edlc -i -f test.st >>>> simple class method invocation >>>> simple class method invocation 2 >>>> ch...@debian:~/etoile/Etoile/Languages/Smalltalk/Tests/TestClassMethods1$ >>>> edlc -i -f test.st >>>> simple class method invocation >>>> simple class method invocation 2 >>>> ch...@debian:~/etoile/Etoile/Languages/Smalltalk/Tests/TestClassMethods1$ >>>> edlc -i -f test.st >>>> simple class method invocation >>>> simple class method invocation 2 >>>> >>>> Cheers >>>> Chris >>>> >>>> On 18/10/2010, at 22:07 PM, David Chisnall wrote: >>>> >>>>> Hi Chris, >>>>> >>>>> Sorry about this - it's an issue that only occurs on platforms where int >>>>> and void* are different sizes, so I didn't see it. It should be fixed in >>>>> r6444. >>>>> >>>>> David >>>>> >>>>> On 18 Oct 2010, at 10:03, Christopher Armstrong wrote: >>>>> >>>>>> Hi all >>>>>> >>>>>> I'm trying to run some of the test Smalltalk scripts in the Etoile >>>>>> distribution. I have installed the latest SVN versions of GNUstep, >>>>>> Etoile and LLVM/Clang. Everything has been compiled with clang. >>>>>> >>>>>> When I try and run any script, I get the following error: >>>>>> >>>>>> ch...@debian:~/etoile/Etoile/Languages/Smalltalk/Tests/TestBlockReturn$ >>>>>> edlc -f test.st >>>>>> edlc: Constants.cpp:1215: static llvm::Constant* >>>>>> llvm::ConstantExpr::getPointerCast(llvm::Constant*, const llvm::Type*): >>>>>> Assertion `S->getType()->isPointerTy() && "Invalid cast"' failed. >>>>>> Aborted >>>>>> ch...@debian:~/etoile/Etoile/Languages/Smalltalk/Tests/TestBlockReturn$ >>>>>> >>>>>> Any clue what this means? If I attach gdb to edlc, the backtrace at the >>>>>> point the exception is thrown is: >>>>>> #0 0xb802c424 in __kernel_vsyscall () >>>>>> #1 0xb701b640 in raise () from /lib/i686/cmov/libc.so.6 >>>>>> #2 0xb701d018 in abort () from /lib/i686/cmov/libc.so.6 >>>>>> #3 0xb70145be in __assert_fail () from /lib/i686/cmov/libc.so.6 >>>>>> #4 0xb5bb4576 in llvm::ConstantExpr::getPointerCast () >>>>>> from >>>>>> /usr/local/GNUstep/Local/Library/Frameworks/LanguageKitCodeGen.framework/Versions/Current/./LanguageKitCodeGen >>>>>> #5 0xb5ec84e8 in ?? () from >>>>>> /usr/local/GNUstep/Local/Library/Frameworks/LanguageKitCodeGen.framework/Versions/Current/./LanguageKitCodeGen >>>>>> #6 0xb5ec9544 in ?? () from >>>>>> /usr/local/GNUstep/Local/Library/Frameworks/LanguageKitCodeGen.framework/Versions/Current/./LanguageKitCodeGen >>>>>> #7 0x000004bf in ?? () >>>>>> #8 0xb5ecbf00 in ?? () from >>>>>> /usr/local/GNUstep/Local/Library/Frameworks/LanguageKitCodeGen.framework/Versions/Current/./LanguageKitCodeGen >>>>>> #9 0xb5f3c3a0 in ?? () from >>>>>> /usr/local/GNUstep/Local/Library/Frameworks/LanguageKitCodeGen.framework/Versions/Current/./LanguageKitCodeGen >>>>>> #10 0x08d9ed50 in ?? () >>>>>> #11 0x08ddf49c in ?? () >>>>>> #12 0xb54bc018 in CodeGenLexicalScope::InitialiseFunction >>>>>> (this=0x8dcaa40, humanna...@0xbff45568, symbols=0xbff45680, >>>>>> MethodTypes=0x8dca3d8 "^{LKObject_hack=(?...@i)}...@0:8", locals=1, >>>>>> loca...@0x8dcaa50, ar...@0x8dcaa80) >>>>>> at >>>>>> /home/chris/etoile/Etoile/Languages/LanguageKit/CodeGen/CodeGenLexicalScope.cpp:665 >>>>>> #13 0xb54b4e86 in CodeGenMethod::CodeGenMethod (Mod=0x0, this=0x8dcaa40, >>>>>> MethodTypes=0x8dca3d8 "^{LKObject_hack=(?...@i)}...@0:8", >>>>>> localNames=0xbff45680, >>>>>> locals=1, MethodName=0x8dca878 "createCounter") at >>>>>> /home/chris/etoile/Etoile/Languages/LanguageKit/CodeGen/CodeGenModule.cpp:226 >>>>>> #14 0xb54b5089 in CodeGenModule::BeginInstanceMethod >>>>>> (MethodName=0x8dca878 "createCounter", this=0x8d9f038, >>>>>> localNames=0xbff45680, locals=1, >>>>>> MethodTypes=0x8dca3d8 "^{LKObject_hack=(?...@i)}...@0:8") at >>>>>> /home/chris/etoile/Etoile/Languages/LanguageKit/CodeGen/CodeGenModule.cpp:242 >>>>>> Segmentation fault >>>>>> >>>>>> (The segmentation fault is from GDB) >>>>>> >>>>>> Thanks >>>>>> Chris >>>>>> -------- >>>>>> Christopher Armstrong >>>>>> [email protected] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Etoile-discuss mailing list >>>>>> [email protected] >>>>>> https://mail.gna.org/listinfo/etoile-discuss >>>>> >>>>> -- Send from my Jacquard Loom >>>>> >>>>> >>>>> _______________________________________________ >>>>> Etoile-discuss mailing list >>>>> [email protected] >>>>> https://mail.gna.org/listinfo/etoile-discuss >>>> >>>> -------- >>>> Christopher Armstrong >>>> [email protected] >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Etoile-discuss mailing list >>>> [email protected] >>>> https://mail.gna.org/listinfo/etoile-discuss >>> >>> -- Send from my Jacquard Loom >>> >>> >>> _______________________________________________ >>> Etoile-discuss mailing list >>> [email protected] >>> https://mail.gna.org/listinfo/etoile-discuss >>> >> -- >> Christopher Armstrong >> carmstrong ^^AT^ fastmail dOT com /Dot/ au >> >> >> _______________________________________________ >> Etoile-discuss mailing list >> [email protected] >> https://mail.gna.org/listinfo/etoile-discuss > > > -- Sent from my PDP-11 > > > _______________________________________________ > Etoile-discuss mailing list > [email protected] > https://mail.gna.org/listinfo/etoile-discuss -------- Christopher Armstrong [email protected] _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
