Differences in GCC and ICC compiled objects? relocatable.

Posted in the Intel forums but this may be more of a GCC issue.
Please advise if I should post
elsewhere.

Compiling a C module in with a large app (>2GB data) and getting
relocatable errors
with GCC and not ICC.

../classification_dpr_BB.o: In function `BB_detection_dpr':
/homedata/johnk/dpr/src_20120126/DD2_V2.20120126/src/./
classification_dpr_BB.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_dpr_BB.c
cc -I../include -g -v -fPIC -mcmodel=medium -DDEBUG -c ./
classification_dpr_BB.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 on the main link
(ifort is used).

Could it have something to do with the relocation types?

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

On 02/22/2012 03:03 PM, J K wrote:
> Posted in the Intel forums but this may be more of a GCC issue.

Then why didn't you post to a gcc-specific forum?

> Please advise if I should post
> elsewhere.

Yes, you should. You'll get better answers in the right forums.

Le 22/02/12 21:03, J K a écrit :
> Posted in the Intel forums but this may be more of a GCC issue.
> Please advise if I should post
> elsewhere.
>
> Compiling a C module in with a large app (>2GB data) and getting
> relocatable errors
> with GCC and not ICC.
>
> ./classification_dpr_BB.o: In function `BB_detection_dpr':
> /homedata/johnk/dpr/src_20120126/DD2_V2.20120126/src/./
> classification_dpr_BB.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?
>

Obviously PC relative addressing is limited to + or - 2GB since it is 32
bits. The compiler is generating PC relative addresses for looking up
the data segment and that can't work with more than 2GB of data.


Many things remained 32 bits in today's 64 bit systems because of
performance reasons.

lcc-win assumes also that the static data is less than 2GB. Some
customers did not like this, for instance the limitation to having code
in the first 4GB of the address space.

To get rid of that limitation I was forced to avoid to generate any
call instructions since calls can go forward or backwards up to 2GB.

The solution is to load a 64 bit address into a register and then jump
to that registers using the indirect call instruction. (A FAR call)

Similar work arounds can be found for addressing a table (FAR data).

Here is the same. The compiler is generating PC relative addressing and
to get around that limitation you should have a different code
generation strategy. Sometimes compilers allow the user to specify that
(memory models). I do not know if gcc does that, maybe it doesn't, and
in that case use intel since it works (and generates much better code by
the way)

Intel uses a GOT, gcc doesn't. Probably intel does that to avoid PC
relative relocations, and gcc doesn't.

Le 22/02/12 21:42, James Kuyper a écrit :
> On 02/22/2012 03:03 PM, J K wrote:
>> Posted in the Intel forums but this may be more of a GCC issue.
>
> Then why didn't you post to a gcc-specific forum?
>
>> Please advise if I should post
>> elsewhere.
>
> Yes, you should. You'll get better answers in the right forums.

GCC forums in usenet are dead since at least 5 years or more.

Please: If you do not know the answer to a question just keep silent
(it is not a blame) and do not redirect people to non-existent forums

Gcc developers can be reached by their mailing lists, and gnu, but
do not expect quick answers to abstract problems unless, of course,
you are willing to pay consulting fees.

That is my experience with those forums. Other people could have
better experience, who knows. I never had any answers to any question
I asked there. It is true that the questions were hard.

On 02/23/2012 10:10 AM, J K wrote:
> On Feb 22, 4:26 pm, jacob navia <ja...@spamsink.net> wrote:
....
>> Please: If you do not know the answer to a question just keep silent
>> (it is not a blame) and do not redirect people to non-existent forums

That I don't know the answer, despite being an expert in the topic of
this forum, is a symptom of the fact that it's not the right forum for
this question. To remain silent in the face of that fact would be doing
a disservice to the OP.

I didn't specify usenet newsgroups - I deliberately used the more
general term "forums" to include the possibility that the most active
gcc forums might be based upon some entirely different social networking
medium, such as:

>> Gcc developers can be reached by their mailing lists,