[LLVMdev] non_lazy_ptr question
Talin
viridia at gmail.com
Mon Aug 23 23:56:53 PDT 2010
So, I've got a case where I am attempting to pass the address of a static
symbol from a module written in Tart (the language I am working on), to a
module written in C (which is part of Tart's runtime library). This works
fine on Linux, but fails on OS X because the address being passed is the
"non_lazy_ptr" symbol, not the symbol itself.
In my .bc file, I've got code that looks like this:
@gc_safepoint_map = external global [0 x i32] ; <[0 x i32]*> [#uses=1]
%init = invoke {} @GC_init(i32* getelementptr inbounds ([0 x i32]*
@gc_safepoint_map, i32 0, i32 0))
to label %nounwind unwind label %catch, !dbg !400 ; <{}> [#uses=0]
In other words, we have an external symbol that is being passed to an
external function. (BTW, gc_safepoint_map is the map of all of the stack
offsets containing pointers, indexed by the program counter address of the
safe point. It's generated by a custom linker pass.)
However, the code that is being generated looks like this:
movl L_gc_safepoint_map$non_lazy_ptr, %eax
movl %eax, (%esp)
call _GC_init
In other words, it's passing the 'non_lazy_ptr' version of the symbol
directly to GC_init, without dereferencing it. This makes the code go boom.
OK, so my question is:
- Where exactly would this dereference normally occur?
- Would it be in the calling module (written in bitcode)? If so, do I
need to generate bitcode to dereference the symbol, or is there
some means
to do this automatically? If I need to generate the bitcode
myself, how do I
tell whether the current target is one that needs this?
- Conversely, would I need to write code on the callee side (written
in C). In this case, I don't have access to target data, just
cmake config
variables. Again, I'd need to come up with some test I can write in cmake
language that lets me know whether or not I need to do the special
dereference.
- Alternatively perhaps there is some linker flag I can set that makes
this problem go away.
Any suggestions?
--
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100823/be43afa5/attachment.html>
More information about the llvm-dev
mailing list