[LLVMdev] HowToUseJIT: failed assertion on PPC/Mac OS X

Chris Lattner sabre at nondot.org
Sun Feb 20 09:54:29 PST 2005


On Sun, 20 Feb 2005, Evan Jones wrote:

> On Feb 20, 2005, at 11:12, Evan Jones wrote:
>> I can "fix" it by changing JITResolver::getFunctionStub to use 
>> F->isExternal() instead of F->hasExternalLinkage(). However, this then 
>> breaks when calling *real* external functions (native code).
> I obviously should not post to mailing lists before I've eaten. With my "fix" 
> I get an assertion when taking an address of a function, not with native 
> code:

FWIW I'm looking into this too, my darwin build is just out of date so 
it's taking a while. :)

> The backtrace is the same as before: a recursive JIT loop. In this case, 
> F->isExternal() returns "true" because the function has not yet been loaded 
> (?). A hack to fix both issues is to change the conditional to test both 
> F->hasExternalLinkage() && F->isExternal().

I'm suspicious of two things.  First the above conditional does make 
sense, but second, why does it only happen with the HowToUseTheJIT 
example, and not every program run by lli (for example).  My guess is that 
the ExistingModuleProvider used by the HowToUseTheJIT example is doing 
something funny.  :(

> I don't quite get what is going on here. From what I understand, external 
> linkage means that the function is visible outside the current module? So a 
> function declared in a C file would have external linkage, while a "static" 
> function would have internal linkage. The GlobalValue::isExternal() method 
> should return true if the global value is defined outside the current 
> translation unit.

Yes, linkage determines whether something is accessible inside or outside 
the module, and isExternal() determines whether it is *defined* inside of 
outside the module.  Note that only some combinations of these make sense.
:)

> From my understanding, "foo()"->isExternal() should return *false*, since it 
> is defined in the current translation unit. However, it doesn't because none 
> of the basic blocks for the body have not yet been loaded (?).

Yes, that is what doesn't make sense to me.  I bet it's the 
ExistingModuleProvider or something else strange.

> At any rate, I've attached a new patch which "works for me" on PPC and x86. 
> At this point, I really don't know what is going on, so I really don't know 
> if it is correct.

Thanks for taking a look at this, I'll get back to you in a few minutes. 
:)

-Chris

-- 
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/




More information about the llvm-dev mailing list