Differences in GCC and ICC compiled objects? re: relocatable.

[jkwi]

Compiling a C module in with a large app (>2GB data) and getting relocatable errors
with GCC and not ICC. Linking with the ICC compiled object is no problem.
We need this to work with both. What magic is ICC pulling off?

./classification.o: In function `BB_detection':
./classification.c:118: relocation truncated to fit: R_X86_64_PC32 against `.bss'

Can anyone familiar with the output of readelf see why the GCC
object is not relocatable and the ICC one is? Would another tool
be more suitable?

icc -I../include -g -v -sox -fPIC -mcmodel=medium -DDEBUG -c ./classification.c
cc -I../include -g -v -fPIC -mcmodel=medium -DDEBUG -c ./classification.c

This module does not use more than 2GB data itself, I just need it to be linked with
code that does, so -fPIC. I left off the medium memory model switch on both with no impact.
Everything is static except for the -shared-intel -mcmodel=medium on the main link (ifort is used).

Could it have something to do with the relocation types shown here?

GCC
Relocation section '.rela.text' at offset 0xd040 contains 449 entries:
Offset Info Type Sym. Value Sym. Name + Addend
00000000004e 001700000002 R_X86_64_PC32 0000000000000000 .rodata + fffffffffffffffc
00000000008e 000400000002 R_X86_64_PC32 0000000000000000 .bss + 1e5c
0000000000bc 000400000002 R_X86_64_PC32 0000000000000000 .bss + 105c


ICC
Relocation section '.rela.text' at offset 0xf222 contains 732 entries:
Offset Info Type Sym. Value Sym. Name + Addend
000000000030 00780000001a R_X86_64_GOTPC32 0000000000000000 _GLOBAL_OFFSET_TABLE_ + fffffffffffffffc
000000000036 000600000019 R_X86_64_GOTOFF64 0000000000000000 _2il0floatpacket.15 + 0
000000000057 000700000019 R_X86_64_GOTOFF64 0000000000000008 _2il0floatpacket.16 + 0
00000000009f 00780000001a R_X86_64_GOTPC32 0000000000000000 _GLOBAL_OFFSET_TABLE_ + fffffffffffffffc

gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51)
icc (ICC) 11.1 20100806

The full output of readelf -all are at these links.

ICC
http://www.box.com/s/2iqnqydmi0mdz52xs9ac

GCC
http://www.box.com/s/jjcgq1x2s5ybpg7s9b6g

Thanks.

[Georg_Z_Intel]

Hello,

without knowing details of your project, have you tried adding the following option to your GCC build:

-mmlarge-data-threshold=1

Of course, this requires a full rebuild.

Best regards,

Georg Zitzlsberger

[jkwi]

Thanks for the tip. Did not know about that flag and after doing a little research, it seems to be a source of confusion. Anyway, I tried it and it doesn't help. It does alter the object, from readelf output the section headers get moved and I do see the TYPE of relocations changes to R_X86_64_GOT* similar to ICC but still no go.

GCC with -mlarge-data-threshold=1

Relocation section '.rela.text' at offset 0xd3b8 contains 452 entries:
Offset Info Type Sym. Value Sym. Name + Addend
000000000013 00250000001a R_X86_64_GOTPC32 0000000000000000 _GLOBAL_OFFSET_TABLE_ + fffffffffffffffc
000000000055 001700000002 R_X86_64_PC32 0000000000000000 .rodata + fffffffffffffffc
00000000008a 001600000019 R_X86_64_GOTOFF64 0000000000001e60 Rain_Norain_NS.4269 + 0
0000000000b8 001200000019 R_X86_64_GOTOFF64 0000000000001060 cos_buff_NS.4275 + 0
0000000000ed 001300000019 R_X86_64_GOTOFF64 0000000000001500 HBB_km_NS.4274 + 0
000000000122 001500000019 R_X86_64_GOTOFF64 0000000000001c00 BB_flag_NS.4270 + 0

The GCC docs says that "all objects" must have the flag with the same threshold, some are built
with Intel fortran so how could they?

ICC must be doing something that GCC is not... if I slip the ICC compiled object into the build stream everything is fine.

[Georg_Z_Intel]

Hello,

as my quick shot did not help I need to get a deeper understanding of your build system now.

Let's only look at the scenario that's not working for you:
You mentioned that you're using GCC for C/C++ code and our FORTRAN compiler for FORTRAN code. When linking all compilation units you get the "relocation truncated to fit" error messages.
Could you please provide the exact compiler options for compiling C/C++ and FORTRAN compilation units plus the ones for the link phase. Please also provide the error message you get during link phase. I'll try to reproduce your problem.
You can make use of a private reply if you don't want the information to be public.

Thank you & best regards,

Georg Zitzlsberger

[jkwi]

Thanks, I'll be sending a note with details as soon as I get everything together.

A more general question I have is how relocations and mcmodel are handled.

For ICC if I have for example:
Main (>2GB) -mcmodel=medium -shared-intel (in this case our main is Fortran (ifort).
libA.a -fpic doesn't use >2GB, do I need mcmodel flags on compile?
libB.a -fpic
libz.a ?
math libs and other things I don't control.

I realize -fpic is always used for generating shared libs but is -fpic enough
to make the objects in the static libs relocatable?

Thanks.

[ama1]

We are using HDF4 and HDF5 and custom libraries. HDF4/HDF5 are built with "-fPIC -mcmodel=medium -shared-intel". The custom libraries are built with -mcmodel=medium (static libs produced). We have tried adding -fPIC to custom libraries too.