Differences in GCC and ICC compiled objects? relocatable.

Discussion in 'C Programming' started by J K, Feb 22, 2012.

  1. J K

    J K Guest

    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
     
    J K, Feb 22, 2012
    #1
    1. Advertising

  2. J K

    James Kuyper Guest

    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.
     
    James Kuyper, Feb 22, 2012
    #2
    1. Advertising

  3. J K

    jacob navia Guest

    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.
     
    jacob navia, Feb 22, 2012
    #3
  4. J K

    jacob navia Guest

    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.
     
    jacob navia, Feb 22, 2012
    #4
  5. J K

    J K Guest

    On Feb 22, 4:26 pm, jacob navia <> wrote:
    > 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


    Thanks for the responses. I did look for GCC specific usenet forums
    and
    yes, 'dead' is the word I would use.
    I'll try the mailing lists.

    >
    > 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.
     
    J K, Feb 23, 2012
    #5
  6. J K

    Noob Guest

    J K wrote:

    > Thanks for the responses. I did look for GCC specific usenet forums
    > and yes, 'dead' is the word I would use. I'll try the mailing lists.


    I would have sworn that GCC had set up a gateway between
    gnu.gcc.help and the corresponding mailing list. Judging
    by the lack of activity in the newsgroup, it is obviously
    not true anymore.

    Your best bet is, indeed, the gcc-help mailing list.

    http://gcc.gnu.org/lists.html

    Regards.
     
    Noob, Feb 23, 2012
    #6
  7. J K

    James Kuyper Guest

    On 02/23/2012 10:10 AM, J K wrote:
    > On Feb 22, 4:26 pm, jacob navia <> 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,
     
    James Kuyper, Feb 23, 2012
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Klaus Schneider
    Replies:
    1
    Views:
    581
    Rolf Magnus
    Dec 2, 2004
  2. Patrick Laurent

    How to force 'inline' with GCC or ICC

    Patrick Laurent, May 15, 2005, in forum: C++
    Replies:
    44
    Views:
    43,428
    jagadev
    Oct 6, 2006
  3. Preben
    Replies:
    2
    Views:
    592
    Preben
    Sep 25, 2006
  4. Replies:
    5
    Views:
    724
  5. easter bunny

    icc, gcc sse alignement

    easter bunny, Jul 3, 2007, in forum: C++
    Replies:
    2
    Views:
    415
    easter bunny
    Jul 4, 2007
Loading...

Share This Page