[LLVMdev] Redefining function

Jeffrey Yasskin jyasskin at google.com
Mon Feb 1 09:41:06 PST 2010


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 need to call
freeMachineCodeForFunction(x) before you call
x->replaceAllUsesWith(y).

And yes, putting your code (and a gdb-produced stack trace when
there's a crash) somewhere we can see it (for example, pastebin.com)
will always help us debug problems.

On Sunday, January 31, 2010, Conrado Miranda <miranda.conrado at gmail.com> wrote:
> 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 google.com> wrote:
>
>
> On Sun, Jan 31, 2010 at 7:35 AM, Conrado Miranda
> <miranda.conrado at gmail.com> wrote:
>> Great! It just worked. I was a bit worried about using pointers to call
>> functions because it's a little too overwhelming in a big project, I think.
>>
>> Just for the record, if the function code isn't freed with
>> freeMachineCodeForFunction, I get a segmentation fault during
>> recompileAndRelinkFunction with this stack dump:
>> Running pass 'X86 Machine Code Emitter' on function '@do_print'
>
> Well, it's not supposed to segfault. At worst, it should give you an
> assertion error when you do something wrong (when it's compiled with
> asserts, of course). Could you either file a bug, or send me the exact
> code you were using with the command line you used to compile it
> against svn head?
>
> Thanks,
> Jeffrey
>
>



More information about the llvm-dev mailing list