Bugs using -fPIC on linux (i86 RedHat 5.0)?
Jeffrey A Law
law@cygnus.com
Mon Dec 29 10:20:00 GMT 1997
In message < 19971229091404.35828@dot.cygnus.com >you write:
> On Mon, Dec 29, 1997 at 03:22:09PM +0100, Marius Kjeldahl wrote:
> > (I do not know _why_ it runs without -fPIC - maybe it simply
> > does not gain me the real benefit of a shared library, meaning several
> > applications will load the library into their own private memory space
> > - just guessing here).
>
> A pretty good guess -- the pages start out shared and then get dirtied
> by the relocations that are applied, which makes them not shared. The
> fact that it does work has its uses though.
>
> > In looking at the temporary assembler file, the lines it objects to is:
> >
> > call @PLT
>
> This is a compiler bug, as the target symbol for the call is missing.
> Can you give us the preprocessed file that generates this problem?
Well, on the x86, I don't see how you can get @PLT without a
function name -- unless the compiler mis-compiled itself or we have
a SYMBOL_REF with a null name. From i386.c:
case SYMBOL_REF:
case LABEL_REF:
if (GET_CODE (x) == SYMBOL_REF)
assemble_name (file, XSTR (x, 0));
else
{
ASM_GENERATE_INTERNAL_LABEL (buf, "L",
CODE_LABEL_NUMBER (XEXP (x, 0)));
assemble_name (asm_out_file, buf);
}
if (GET_CODE (x) == SYMBOL_REF && CONSTANT_POOL_ADDRESS_P (x))
fprintf (file, "@GOTOFF(%%ebx)");
else if (code == 'P')
fprintf (file, "@PLT");
More information about the Gcc
mailing list