What is R_X86_64_PC32?

Steve Kargl sgk at troutmask.apl.washington.edu
Thu Jan 27 12:15:10 PST 2005


On Thu, Jan 27, 2005 at 01:27:04PM -0600, James R. Van Artsdalen wrote:
> Steve Kargl wrote:
> 
> >This simple fortran program:
> >
> >      program kk
> >      implicit none
> >      integer N
> >      parameter (N=32768)
> >      real input(N,N)
> >      input(1,1) = 1.e0
> >      end program kk
> >
> >
> >when compiled by either the system's f77 command or gfortran,
> >generates the following error:
> >
> >troutmask:kargl[217] f77 -o df df.f
> >/usr/lib/crt1.o(.text+0x15): In function `_start':
> >: relocation truncated to fit: R_X86_64_PC32 environ
> >Is this an indication that the stack isn't large enough?
> >
> I don't think this is anything you're doing.
> 
> The error is actually a relocation being applied to the startup code in 
> crt1.c:
> 
> /* The entry function. */
> void
> _start(char **ap, void (*cleanup)(void))
> {
>        int argc;
>        char **argv;
>        char **env;
>        const char *s;
> 
>        argc = *(long *)(void *)ap;
>        argv = ap + 1;
>        env = ap + 2 + argc;
> 
> I think the linker is getting the error trying to fixup the write to env 
> here:
> 
> 0000000000000000 <_start>:
>   0:   41 54                   push   %r12
>   2:   55                      push   %rbp
>   3:   53                      push   %rbx
>   4:   8b 2f                   mov    (%rdi),%ebp
>   6:   4c 8d 67 08             lea    0x8(%rdi),%r12
>   a:   48 63 dd                movslq %ebp,%rbx
>   d:   48 8d 5c df 10          lea    0x10(%rdi,%rbx,8),%rbx
>  12:   48 89 1d 00 00 00 00    mov    %rbx,0(%rip)        # 19 
> <_start+0x19>
> 
> I *think* that last line is the write to env?  In that case there's only 
> room for a 32-bit offset between the address of this code and that of env.
> 
> Peter, Dave: do we require that statically allocated data be within 2 GB 
> of any code that might reference it by name?
> 
> Even if that's true it's not obvious to me why your test program isn't 
> meeting such a requirement?

Thanks for the explanation.  It gets even worse if you try to compile
a static program.

troutmask:kargl[206] f77 -o df -static df.f
/usr/lib/crt1.o(.text+0x15): In function `_start':
: relocation truncated to fit: R_X86_64_PC32 environ
/usr/lib/libg2c.a(s_stop.o)(.text+0x39): In function `s_stop':
: relocation truncated to fit: R_X86_64_PC32 __isthreaded
/usr/lib/libg2c.a(setarg.o)(.text+0x2): In function `f_setarg':
: relocation truncated to fit: R_X86_64_PC32 f__xargc
/usr/lib/libg2c.a(setarg.o)(.text+0x9): In function `f_setarg':
: relocation truncated to fit: R_X86_64_PC32 f__xargv
/usr/lib/libg2c.a(err.o)(.text+0xa): In function `f__canseek':
: relocation truncated to fit: R_X86_64_PC32 __isthreaded
/usr/lib/libg2c.a(err.o)(.text+0x80): In function `f__canseek':
: relocation truncated to fit: R_X86_64_PC32 __isthreaded
/usr/lib/libg2c.a(err.o)(.text+0x146): In function `f__fatal':
: relocation truncated to fit: R_X86_64_PC32 .bss
/usr/lib/libg2c.a(err.o)(.text+0x172): In function `f__fatal':
: relocation truncated to fit: R_X86_64_PC32 .bss
/usr/lib/libg2c.a(err.o)(.text+0x17c): In function `f__fatal':
: relocation truncated to fit: R_X86_64_PC32 f__init
/usr/lib/libg2c.a(err.o)(.text+0x18a): In function `f__fatal':
: relocation truncated to fit: R_X86_64_PC32 f__curunit
/usr/lib/libg2c.a(err.o)(.text+0x194): In function `f__fatal':
: additional relocation overflows omitted from the output

It seems that FreeBSD is stuck with a 2GB address space if
you have static memory allocation.

-- 
Steve


More information about the freebsd-amd64 mailing list