similar to: [LLVMdev] Could you add tests for dlsym stubs?

See http://llvm.org/bugs/show_bug.cgi?id=4406 The testcase at http://llvm.org/bugs/attachment.cgi?id=3141 needs to be updated to free the machine code with: ee->freeMachineCodeForFunction(cast<Function>(ll_main)); Once that's done, though, the AssertingVH is still triggered on destruction of the Module. It turns out that the stub for the external "write" is not

When testing which “dl library” we must use for dl* symbols, autoconf runs a test similar to: $ cat conftest.c char dlopen (); int main () { return dlopen (); } $ gcc -o conftest $CFLAGS conftest.c [try various -ldl options here] When using ‘CFLAGS="-fsanitize=address"’ this succeeds even if no dl libraries are used at all, since it appears that using this option causes dlopen

I had this problem a while back and received this response from Jeffrey. FWIW this is fixed in 2.7 by defaulting to CodeModel::Large and using indirect (far) calls. -----Original Message----- From: Jeffrey Yasskin [mailto:jyasskin at google.com] Sent: Monday, December 07, 2009 11:32 AM To: Howell, Nathan Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] 2.6 JIT using wrong address for

We generating object files, not using the JIT so I don't know if those fixes applies in our case. As far as using PIC goes, the ELFCodeEmitter has asserts to tell you that PIC isn't currently supported. Will have to get the 2.7 update and try it out. Thanks. -----Original Message----- From: Howell, Nathan [mailto:nhowell at ebay.com] Sent: Thursday, June 17, 2010 3:45 PM To: Eli

On Jun 10, 2009, at 12:17 PM, Jeffrey Yasskin wrote: > In X86CodeGen.cpp, the following code appears in the handler used for > CALL64pcrel32 instructions: > > // Assume undefined functions may be outside the Small > codespace. > bool NeedStub = > (Is64BitMode && > (TM.getCodeModel() == CodeModel::Large || >

On Fri, Feb 26, 2010 at 1:26 PM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Hi Jeffrey, > On Feb 26, 2010, at 16:02, Jeffrey Yasskin wrote: > > [sidenote: Please try to avoid extraneous whitespace and line wrapping > changes in your patches. It makes it harder to see what you're actually > changing] > > Sorry just saw some preexisting code was not in 80

On Thu, Jun 11, 2009 at 12:54 PM, Evan Cheng<evan.cheng at apple.com> wrote: > > > > On Jun 10, 2009, at 12:17 PM, Jeffrey Yasskin wrote: > >> In X86CodeGen.cpp, the following code appears in the handler used for >> CALL64pcrel32 instructions: >> >>       // Assume undefined functions may be outside the Small codespace. >>       bool NeedStub =

I had that problem too: http://llvm.org/bugs/show_bug.cgi?id=5116. To work around the problem, you can: * Switch to the thread-unsafe lazy jit. * Allocate your JIT code within 2GB of your text segment. * Find a way to look up the external function with dlsym or maybe the ExecutionEngine's LazyFunctionCreator instead of addGlobalMapping. * Upgrade to the top of the svn tree. On Mon, Dec 7,

In X86CodeGen.cpp, the following code appears in the handler used for CALL64pcrel32 instructions: // Assume undefined functions may be outside the Small codespace. bool NeedStub = (Is64BitMode && (TM.getCodeModel() == CodeModel::Large || TM.getSubtarget<X86Subtarget>().isTargetDarwin())) || Opcode == X86::TAILJMPd;

Hi Jeffrey, On Feb 26, 2010, at 16:02, Jeffrey Yasskin wrote: > [sidenote: Please try to avoid extraneous whitespace and line wrapping changes in your patches. It makes it harder to see what you're actually changing] Sorry just saw some preexisting code was not in 80 columns. > > On Fri, Feb 26, 2010 at 4:57 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Hi

Just updated the source and now I get the unreachable error again. The JIT doesn't know how to handle a RAUW on a value it has emitted. UNREACHABLE executed at /home/conrado/engines/llvm/lib/ExecutionEngine/JIT/JITEmitter.cpp:1542! I think that it's not helpful now, but I can post the program, if you want me to. On Sun, Jan 31, 2010 at 2:49 PM, Jeffrey Yasskin <jyasskin at

Thanks Jeffrey ! If possible, keep me inform (on revision number), I'm interested to see how you will do the unit test. (For my future patch... :) ). Thanks again. Olivier. On Wed, Feb 10, 2010 at 6:22 PM, Jeffrey Yasskin <jyasskin at google.com>wrote: > Thanks for the patch! I'll clean this up, convert your sample to a > unit test, and commit it for 2.7. > > On Sun,

Hm, I wonder if the error message for llvm_unreachable should change. I think I remember a couple people focusing incorrectly on the UNREACHABLE instead of the actual error message above it (which means it's our fault, not theirs). Miranda, this is pointing at the same problem you had before. You have a function JIT-compiled, and you're trying to RAUW (ReplaceAllUsesWith) it. You'll

Thanks for the quick answer! Syncing to r61112 got rid of the ICE, but I still get the following error: make "DESTDIR=" "RPATH_ENVVAR=DYLD_LIBRARY_PATH" "TARGET_SUBDIR=i686-apple-darwin9" "bindir=/Users/jyasskin/src/llvm-gcc-4.2/trunk/obj/../install/bin" "datadir=/Users/jyasskin/src/llvm-gcc-4.2/trunk/obj/../install/share"

On Mon, Jan 11, 2010 at 1:39 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > The JIT tries to handle this in some cases > (http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/ExecutionEngine/ExecutionEngine.cpp?annotate=92771#l942), > but doesn't handle it for functions. There aren't any tests, so I'm > not surprised it's broken. > > The JIT would be

Good catch! I meant "for iterator" of course. Attached is a corrected patch together with an old patch for clang just to keep them together. Could someone commit these, please? Thanks, Victor 2009/11/4 Jeffrey Yasskin <jyasskin at google.com> > + // Otherwise this is a copy constructor for const_iterator. > > Do you mean "for iterator"? > > Otherwise,

Reminding about the patches... Is there a problem with them or simply nobody have looked at them since? Victor 2009/11/4 Victor Zverovich <victor.zverovich at googlemail.com> > Good catch! I meant "for iterator" of course. Attached is a corrected patch > together with an old patch for clang just to keep them together. > Could someone commit these, please? > >

On Fri, Apr 16, 2010 at 9:30 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > On Sun, Apr 11, 2010 at 10:07 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: >> I'll forward your next draft back to the stackless folks, unless you >> want to pick up the thread with them. > > Their reply: http://thread.gmane.org/gmane.comp.python.stackless/4464/focus=4475

No anchor naming options that I can find. But I'll keep an eye out for things that may improve anchor readability. --mike-m On 2010-05-08, at 12:53 PM, Jeffrey Yasskin wrote: > mike-m, is there any way to configure doxygen to produce > human-readable anchors? They might have avoided the duplication on > this thread, since Erick and John could have seen that I was linking > to

Hi Jeffrey, I'm still in the process of learning the unittest technology. While I did get distracted with test-suite and test, and therefore the requisite installs of llvm-gcc, and DejaGNU, I think I'm back on track now. So that was a waste of time. By the way the reference I have to the unittests target was in an archive for this list. Is there no llvm level doc for this? Regardless the