This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
pic code generation
- To: gcc at gcc dot gnu dot org
- Subject: pic code generation
- From: Fergus Henderson <fjh at cs dot mu dot oz dot au>
- Date: Mon, 28 May 2001 01:23:18 +1000
There's a bug in my Mercury front-end that I'm having trouble with;
if anyone has any hints, I'd appreciate it.
The bug occurs when compiling with `-fpic'. The symptom is warnings
from the linker when linking the generated object file into a shared
object:
/usr/i486-linux/bin/ld: bag.pic_o: warning: unresolvable relocation
against symbol `mercury__builtin__builtin__type_ctor_info_int_0'
from .text section
Unsurprisingly, programs linked with this shared object go on to
crash at runtime when executing the relevant bit of code.
It works fine when I compile via C, rather than interfacing directly
with the GCC back-end. The main differences in the generated assembler
file seem to be that when I compile by interfacing directly with the GCC
back-end, using `leal foo@GOTOFF(%ebx)' rather than `movl foo@GOT(%ebx)':
call .LPR0
addl $_GLOBAL_OFFSET_TABLE_, %ebx
movl 24(%esp), %ecx
- movl mercury__builtin__builtin__type_ctor_info_int_0@GOT(%ebx), %eax
+ leal mercury__builtin__builtin__type_ctor_info_int_0@GOTOFF(%ebx), %e
ax
pushl %ecx
movl 24(%esp), %edx
pushl %edx
pushl %eax
What is the difference in semantics between these two assembler fragments?
Any ideas as to what I might be doing wrong in the front-end that could
cause this?
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.