Bug 50230

Summary: [4.5 regression] compiling CMake on PA-RISC fails due to unreachable symbols
Product: gcc Reporter: Rolf Eike Beer <eike>
Component: c++Assignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED INVALID    
Severity: normal CC: danglin
Priority: P3    
Version: 4.5.2   
Target Milestone: ---   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2011-09-04 00:00:00

Description Rolf Eike Beer 2011-08-29 18:29:58 UTC
I tried to compile CMake, branch next, revision
60b6b190cb569a18b6cf415d85ff59fa120a1035. The exact version isn't really
important, the same behaviour can be produced with every CMake version from the next branch since at least 3 month. Before that I was running on gcc 4.4.x so I didn't see the issue. Using the released version 2.8.5 can also be used to provoke the error.

I have a working version of CMake 2.8.4 installed, which was built with gcc 4.4.x (no idea with which exact version). Binutils used to build that CMake was very likely
2.20.1.

If I just use "cmake /path/to/cmake/source/ && make" I get this result:

Linking CXX executable ../bin/ccmake
/usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld:
libCMakeLib.a(cmGlobalGenerator.cxx.o)(.text._ZNSt8_Rb_treeIN5cmsys6StringESt4pairIKS1_iESt10_Select1stIS4_ESt4lessIS1_ESaIS4_EE16_M_insert_uniqueERKS4_[std::_Rb_tree<cmsys::String,
std::pair<cmsys::String const, int>,
std::_Select1st<std::pair<cmsys::String const, int> >,
std::less<cmsys::String>, std::allocator<std::pair<cmsys::String const,
int> > >::_M_insert_unique(std::pair<cmsys::String const, int>
const&)]+0xbc): cannot reach
00004abb__ZNSt8_Rb_treeIN5cmsys6StringESt4pairIKS1_iESt10_Select1stIS4_ESt4lessIS1_ESaIS4_EE8_S_rightEPSt18_Rb_tree_node_base+0,
recompile with -ffunction-sections
/usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld:
libCMakeLib.a(cmGlobalGenerator.cxx.o)(.text._ZNSt8_Rb_treeIN5cmsys6StringESt4pairIKS1_iESt10_Select1stIS4_ESt4lessIS1_ESaIS4_EE16_M_insert_uniqueERKS4_[std::_Rb_tree<cmsys::String,
std::pair<cmsys::String const, int>,
std::_Select1st<std::pair<cmsys::String const, int> >,
std::less<cmsys::String>, std::allocator<std::pair<cmsys::String const,
int> > >::_M_insert_unique(std::pair<cmsys::String const, int>
const&)]+0xbc): cannot handle R_PARISC_PCREL17F for
std::_Rb_tree<cmsys::String, std::pair<cmsys::String const, int>,
std::_Select1st<std::pair<cmsys::String const, int> >,
std::less<cmsys::String>, std::allocator<std::pair<cmsys::String const,
int> > >::_S_right(std::_Rb_tree_node_base*)
/usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld:
final link failed: Bad value
collect2: ld returned 1 exit status

If I add -ffunction-section then ccmake (and cmake and cpack) build fine,
but ctest fails:

Linking CXX executable ../bin/ctest
/usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld:
libCMakeLib.a(cmMakefile.cxx.o)(.text._ZN10cmMakefile14AddSourceGroupEPKcS1_+0x40):
cannot reach 00008647__ZNSaIcEC1Ev@@GLIBCXX_3.4+0, recompile with
-ffunction-sections
/usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld:
libCMakeLib.a(cmMakefile.cxx.o)(.text._ZN10cmMakefile14AddSourceGroupEPKcS1_+0x40):
cannot handle R_PARISC_PCREL17F for
std::allocator<char>::allocator()@@GLIBCXX_3.4
/usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld:
final link failed: Bad value
collect2: ld returned 1 exit status

This is the same static library that causes problems, but this time on a
different executable. So I think John is right and there is really a bug
somewhere.

Just for reference, this are the sizes of the binaries that I currently
have on my system:

-rwxr-xr-x 1 root root 3080228 Apr 26 12:51 /usr/bin/ccmake
-rwxr-xr-x 1 root root 3050408 Apr 26 12:51 /usr/bin/cmake
-rwxr-xr-x 1 root root 4092940 Apr 26 12:51 /usr/bin/ctest

And this is what happens with -ffunction-sections for those that compile:

-rwxr-xr-x 1 buildbot buildbot  9738726 Aug 26 09:15 ccmake
-rwxr-xr-x 1 buildbot buildbot  9608066 Aug 26 09:16 cmake
-rwxr-xr-x 1 buildbot buildbot 10302152 Aug 26 09:16 cpack

I have no idea how big the current results would get as every of the 4
possible candidates fails to link. libCMakeLib.a is 21149998 bytes.

If I use gcc 4.4.6 everything compiles fine but the result is broken. The compiled binary goes into an endless loop if I call the compiled binary with a source directory. This does not happen with arguments like "--help" or "--version".

So:
-compiling/linking with g++ 4.5 fails
-compiling/linking with g++ 4.4 works, but the result is unusable

I have not modified any settings when compiling CMake. See also  https://bugs.gentoo.org/374465 for other problems compiling CMake on PA-RISC, no idea if this is related.
Comment 1 John David Anglin 2011-09-04 15:04:37 UTC
I am unable to duplicate this problem.  I successfully built debian
cmake_2.8.5-1 with both gcc-4.4 and 4.5.  There were no testsuite errors
in either case.

My tools are:
gcc version 4.4.6 (Debian 4.4.6-6)
gcc version 4.5.3 (Debian 4.5.3-5)
binutils 2.21.53.20110805

It is possible your tools are miscompiled.  For example, some
fixes to reorg were backported in May.  These caused GCC to be
miscompiled and produce incorrect code when optimizing at -O1 and above.

Given that I can't duplicate the problem, further information is needed.

You need to look at the object cmGlobalGenerator.cxx.o with objdump/readelf
and see if the call site for the branch to __ZNSt8_Rb_treeIN5cmsys6StringESt4pairIKS1_iESt10_Select1stIS4_ESt4lessIS1_ESaIS4_EE8_S_rightEPSt18_Rb_tree_node_base
is >= 240000 bytes from the start of the section containing the call.

I think it more likely that this is a binutils problem.
Comment 2 Rolf Eike Beer 2011-09-05 15:48:10 UTC
> It is possible your tools are miscompiled.  For example, some
> fixes to reorg were backported in May.  These caused GCC to be
> miscompiled and produce incorrect code when optimizing at -O1 and above.
>
> Given that I can't duplicate the problem, further information is needed.

Seems that trying to debug this issue now also destroyed the version I
have on my system (or just the libstdc++, I don't know). What I did today
is:

rebuild binutils 2.21.1 using the gcc-4.5.3 I have installed
rebuild binutils 2.21.1 using the gcc-4.5.3 I have installed once again
rebuild gcc 4.5.3
rebuild binutils 2.21.1 again
created new build directory
cd this build directory
/path/to/cmake-next/configure
make

This fails with:

/usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld:
cmPropertyDefinitionMap.o(.text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_[__gnu_cxx::new_allocator<std::pair<std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
cmDocumentationSection*> >::construct(std::pair<std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
cmDocumentationSection*>*, std::pair<std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
cmDocumentationSection*> const&)]+0x54): cannot reach
000025c2__ZNSt4pairIKSsP22cmDocumentationSectionEC1ERKS3_+0, recompile
with -ffunction-sections
/usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld:
cmPropertyDefinitionMap.o(.text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_[__gnu_cxx::new_allocator<std::pair<std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
cmDocumentationSection*> >::construct(std::pair<std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
cmDocumentationSection*>*, std::pair<std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
cmDocumentationSection*> const&)]+0x54): cannot handle R_PARISC_PCREL17F
for std::pair<std::basic_string<char, std::char_traits<char>,
std::allocator<char> > const,
cmDocumentationSection*>::pair(std::pair<std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
cmDocumentationSection*> const&)
/usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld:
final link failed: Bad value

objdump shows this:

objdump -x ./Bootstrap.cmk/cmPropertyDefinitionMap.o | grep
_ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5
332
.text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_
000000a0  00000000  00000000  00006008  2**2
00000000 l    d 
.text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_
 00000000
.text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_
00000000  w    F
.text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_
 000000a0
_ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_
000009e0 R_PARISC_SEGREL32 
.text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_
000009e4 R_PARISC_SEGREL32 
.text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_+0x0000009c
00000054 R_PARISC_PCREL17F 
_ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_
RELOCATION RECORDS FOR
[.text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_]:
000013b0 R_PARISC_PCREL32 
.text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_+0x00000008
Comment 3 dave.anglin 2011-09-05 16:28:00 UTC
> rebuild binutils 2.21.1 using the gcc-4.5.3 I have installed
> rebuild binutils 2.21.1 using the gcc-4.5.3 I have installed once  
> again
> rebuild gcc 4.5.3
> rebuild binutils 2.21.1 again
> created new build directory
> cd this build directory
> /path/to/cmake-next/configure
> make
>
> This fails with:


Would you send me the exact source or a link to it offline?

Is incremental linking being used?  The branch is close to the start  
of the section and
it's not obvious why it shouldn't be able to reach the stub.  Could  
you try the failing link
command with --stub-group-size=-1?

Dave
--
John David Anglin	dave.anglin@bell.net
Comment 4 John David Anglin 2011-09-05 18:38:04 UTC
I see a similar error with cmake-next.
Comment 5 John David Anglin 2011-09-05 20:11:53 UTC
This is a binutils problem.  Stubs and section merging don't
play well together.  I'll see if I can fix the default linker
script.

The error doesn't occur if the linker option '--unique=.text.*'
is used.