Hi David
I upgraded llvm/clang to the latest version. I also had to patch LanguageKit
with the following diff to get it to compile:
ch...@debian:~/etoile/Etoile/Languages$ svn diff
Index: LanguageKit/LKModule.m
===================================================================
--- LanguageKit/LKModule.m (revision 6652)
+++ LanguageKit/LKModule.m (working copy)
@@ -18,7 +18,7 @@
#if defined(GNU_RUNTIME)
static const char *TypesForMethodName(NSString *methodName)
{
- return sel_getType_np(sel_get_any_typed_uid([methodName UTF8String]));
+ return sel_getType_np(sel_getUid([methodName UTF8String]));
}
#else
static const char *TypesForMethodName(NSString *methodName)
Index: LanguageKit/CodeGen/CodeGenModule.cpp
===================================================================
--- LanguageKit/CodeGen/CodeGenModule.cpp (revision 6652)
+++ LanguageKit/CodeGen/CodeGenModule.cpp (working copy)
@@ -16,6 +16,8 @@
#include "llvm/Analysis/Verifier.h"
#include <llvm/Support/IRBuilder.h>
#include <llvm/Support/MemoryBuffer.h>
+#include <llvm/Support/system_error.h>
+#include <llvm/System/system_error.h>
#include <llvm/Target/TargetData.h>
#include <string>
@@ -82,8 +84,9 @@
// inline them.
if (NULL == SmallIntMessages)
{
+ llvm::error_code ec;
SmallIntMessages = ParseBitcodeFile(
- MemoryBuffer::getFile(MsgSendSmallIntFilename),
+ MemoryBuffer::getFile(MsgSendSmallIntFilename,
ec),
Context);
}
@@ -413,9 +416,10 @@
void CodeGenModule::compile(void)
{
EndModule();
+ error_code ec;
llvm::Linker::LinkModules(TheModule,
ParseBitcodeFile(
- MemoryBuffer::getFile(MsgSendSmallIntFilename),
+ MemoryBuffer::getFile(MsgSendSmallIntFilename,
ec),
Context), 0);
DUMP(TheModule);
LOG("\n\n\n Optimises to:\n\n\n");
The output of valgrind is:
ch...@debian:~/etoile/Etoile/Languages/Smalltalk/Tests/TestKVC$ valgrind edlc
-f test.st
==22403== Memcheck, a memory error detector.
==22403== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==22403== Using LibVEX rev 1854, a library for dynamic binary translation.
==22403== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==22403== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation
framework.
==22403== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==22403== For more details, rerun with: -v
==22403==
vex x86->IR: unhandled instruction bytes: 0x66 0x66 0x66 0x66
==22403== valgrind: Unrecognised instruction at address 0x70A51E3.
==22403== Your program just tried to execute an instruction that Valgrind
==22403== did not recognise. There are two possible reasons for this.
==22403== 1. Your program has a bug and erroneously jumped to a non-code
==22403== location. If you are running Memcheck and you just saw a
==22403== warning about a bad jump, it's probably your program's fault.
==22403== 2. The instruction is legitimate but Valgrind doesn't handle it,
==22403== i.e. it's Valgrind's fault. If you think this is the case or
==22403== you are not sure, please let us know and we'll try to fix it.
==22403== Either way, Valgrind will now raise a SIGILL signal which will
==22403== probably kill your program.
==22403==
==22403== Process terminating with default action of signal 4 (SIGILL)
==22403== Illegal opcode at address 0x70A51E3
==22403== at 0x70A51E3: CodeGenModule::LLVMFunctionTypeFromString(char
const*, bool&, llvm::Type const*&) (in
/usr/local/GNUstep/Local/Library/Frameworks/LanguageKitCodeGen.framework/Versions/0/libLanguageKitCodeGen.so.0.6)
==22403== by 0x6CCF843: ???
==22403==
==22403== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 310 from 2)
==22403== malloc/free: in use at exit: 6,682,010 bytes in 110,027 blocks.
==22403== malloc/free: 137,042 allocs, 27,015 frees, 11,820,498 bytes allocated.
==22403== For counts of detected errors, rerun with: -v
==22403== searching for pointers to 110,027 not-freed blocks.
==22403== checked 17,325,184 bytes.
==22403==
==22403== LEAK SUMMARY:
==22403== definitely lost: 204,221 bytes in 1,056 blocks.
==22403== possibly lost: 1,365,021 bytes in 48,002 blocks.
==22403== still reachable: 5,112,768 bytes in 60,969 blocks.
==22403== suppressed: 0 bytes in 0 blocks.
==22403== Rerun with --leak-check=full to see details of leaked memory.
I'm not sure if any of this helps:
Cheers
Chris
On 15/12/2010, at 09:05 AM, Christopher Armstrong wrote:
> Hi David
>
> Sorry, I should be more diligent in chasing this up. I'll try with
> valgrind tonight. I've never used it before. Is there a particular
> configuration or set of options that you know will detect the issue
> quickly?
>
> Thanks
> Chris
>
> On Tue, 14 Dec 2010 21:18 +0000, "David Chisnall" <[email protected]>
> wrote:
>> Looking more carefully, this is a bit weird...
>>
>> The pthread_getspecific call seems to be failing, which makes it seem
>> that the call that created the corresponding key has not been called (can
>> you check that?). Even that shouldn't be causing a crash here. This
>> doesn't look like it's anywhere near any LanguageKit code, so my guess is
>> some memory corruption elsewhere (possibly due to LanguageKit).
>>
>> Can you try running it in valgrind and seeing if you can find some
>> invalid writes?
>>
>> David
>>
>> On 11 Dec 2010, at 05:37, Christopher Armstrong wrote:
>>
>>> #0 0xb6f40ed0 in pthread_getspecific () from /lib/i686/cmov/libpthread.so.0
>>> #1 0xb78c3034 in GSCurrentThread () at NSThread.m:344
>>> #2 0xb77ad63d in +[NSAutoreleasePool addObject:] (self=0xb7a50500,
>>> _cmd=0xb7a7cf48, anObj=0x8ec31e8) at NSAutoreleasePool.m:232
>>> #3 0xb7855ba7 in -[NSObject autorelease] (self=0x8ec31e8, _cmd=0xb5854660)
>>> at NSObject.m:1601
>>> #4 0xb58547f7 in ?? ()
>>> #5 0x08ec31e8 in ?? ()
>>> #6 0xb5854660 in ?? ()
>>> #7 0xb77ad624 in +[NSAutoreleasePool currentPool] (self=0x8ec31e8,
>>> _cmd=0xb5854678) at NSAutoreleasePool.m:228
>>
>> --
>> This email complies with ISO 3103
>>
>>
>> _______________________________________________
>> 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
--------
Christopher Armstrong
[email protected]
_______________________________________________
Etoile-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-discuss
