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

    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':
    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 ./
    cc -I../include -g -v -fPIC -mcmodel=medium -DDEBUG -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?

    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 +
    0000000000bc 000400000002 R_X86_64_PC32 0000000000000000 .bss +

    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.


    J K, Feb 22, 2012
    1. Advertisements

  2. J K

    James Kuyper Guest

    Then why didn't you post to a gcc-specific forum?
    Yes, you should. You'll get better answers in the right forums.
    James Kuyper, Feb 22, 2012
    1. Advertisements

  3. J K

    jacob navia Guest

    Le 22/02/12 21:03, J K a écrit :
    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
  4. J K

    jacob navia Guest

    Le 22/02/12 21:42, James Kuyper a écrit :
    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
  5. J K

    J K Guest

    Thanks for the responses. I did look for GCC specific usenet forums
    yes, 'dead' is the word I would use.
    I'll try the mailing lists.
    J K, Feb 23, 2012
  6. J K

    Noob Guest

    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.


    Noob, Feb 23, 2012
  7. J K

    James Kuyper Guest

    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:
    James Kuyper, Feb 23, 2012
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.