[Bug c++/12769] New: -mlongcall doesn't convert all calls to long calls in c++ programs

jfardo at laurelnetworks dot com gcc-bugzilla@gcc.gnu.org
Fri Oct 24 21:42:00 GMT 2003


PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12769

           Summary: -mlongcall doesn't convert all calls to long calls in
                    c++ programs
           Product: gcc
           Version: 3.3.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jfardo at laurelnetworks dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnu

If you compile and link an extremely large c++ powerpc application 
with -mlongcall, the program will fail to link with errors such as:

"relocation truncated to fit: R_PPC_REL24 _Unwind_Resume"

The -mlongcall flag seems to do the right thing with regard
to functions explicitly called in our application. However,
function calls that are generated by the compiler (such as
the call to _Unwind_Resume() to handle exception unwinding)
do not become long calls.

If you compile the example program below and run 'objdump -r'
you will see that the compiler only generates a R_PPC_REL24
relocation record for _Unwind_Resume. All other function calls
have 2 relocation records R_PPC_ADDR16_LO and R_PPC_ADDR16_HA.

// 
// powerpc-unknown-linux-gnu-c++ -mlongcall -c test.c++
//
class Foo
{
  public:
    Foo() {};
    ~Foo() {};
};

int main()
{
    Foo bar1;
    try {
        Foo bar2;
        throw 2;
    } catch (...) {
        throw;
    }

    return 0;
}

> powerpc-unknown-linux-gnu-objdump -r test.o

test.o:     file format elf32-powerpc

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE 
0000001e R_PPC_ADDR16_HA   _ZN3FooC1Ev
00000022 R_PPC_ADDR16_LO   _ZN3FooC1Ev
00000036 R_PPC_ADDR16_HA   _ZN3FooC1Ev
0000003a R_PPC_ADDR16_LO   _ZN3FooC1Ev
0000004a R_PPC_ADDR16_HA   __cxa_allocate_exception
0000004e R_PPC_ADDR16_LO   __cxa_allocate_exception
0000006a R_PPC_ADDR16_HA   _ZTIi
0000006e R_PPC_ADDR16_LO   _ZTIi
00000076 R_PPC_ADDR16_HA   __cxa_throw
0000007a R_PPC_ADDR16_LO   __cxa_throw
00000096 R_PPC_ADDR16_HA   _ZN3FooD1Ev
0000009a R_PPC_ADDR16_LO   _ZN3FooD1Ev
000000ae R_PPC_ADDR16_HA   __cxa_begin_catch
000000b2 R_PPC_ADDR16_LO   __cxa_begin_catch
000000be R_PPC_ADDR16_HA   __cxa_rethrow
000000c2 R_PPC_ADDR16_LO   __cxa_rethrow
000000d6 R_PPC_ADDR16_HA   __cxa_end_catch
000000da R_PPC_ADDR16_LO   __cxa_end_catch
000000f2 R_PPC_ADDR16_HA   _ZN3FooD1Ev
000000f6 R_PPC_ADDR16_LO   _ZN3FooD1Ev
00000108 R_PPC_REL24       _Unwind_Resume   
	 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is the source of the problem.


RELOCATION RECORDS FOR [.eh_frame]:
OFFSET   TYPE              VALUE 
00000012 R_PPC_ADDR32      __gxx_personality_v0
00000024 R_PPC_ADDR32      .text
0000002d R_PPC_ADDR32      .rodata



More information about the Gcc-bugs mailing list