Hi David
Okay, really, really stupid me didn't realise that replacing
sel_get_any_typed_uid() with sel_getUid() would not be a good idea to get rid
of the "method deprecated" warnings. Changing it back and suppressing the
deprecated-declarations warnings solved the problem: most unit tests except
some interpreted ones pass for me now.
How can I fix this bit of code (TypesForMethodName() in LKModule.m) so that it
works with the new runtime and doesn't use a deprecated function?
Thanks
Chris
On 15/12/2010, at 21:50 PM, Christopher Armstrong wrote:
> 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
--------
Christopher Armstrong
[email protected]
_______________________________________________
Etoile-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-discuss
