| Message ID | 4E566E6D.8060100@bell.net (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
> On 8/25/2011 10:06 AM, Carlos O'Donell wrote: >> On 8/25/2011 6:37 AM, Rolf Eike Beer wrote: >>> const&)]+0xbc): cannot reach >>> 00004abb__ZNSt8_Rb_treeIN5cmsys6StringESt4pairIKS1_iESt10_Select1stIS4_ESt4lessIS1_ESaIS4_EE8_S_rightEPSt18_Rb_tree_node_base+0, >>> recompile with -ffunction-sections >> So did you recompile with -ffunction-sections? >> >> The basic problem is that the linker was unable to insert a jump >> to the requested function because it was too far away. Some targets >> like hppa have short branch distances and we use intermediate stub >> tables to get around that. However, we can't insert stub tables just >> anywhere, they need to go between sections. Therefore you need to >> break up this object file. > I think there is a real bug here but nobody has provided a test case. > -ffunction-sections > probably won't help. Confirmed, it is a regression in gcc 4.5. If I build using 4.4.6 everything works fine. I'll file a bug report tonight. Eike -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>> On 8/25/2011 10:06 AM, Carlos O'Donell wrote: >>> On 8/25/2011 6:37 AM, Rolf Eike Beer wrote: >>>> const&)]+0xbc): cannot reach >>>> 00004abb__ZNSt8_Rb_treeIN5cmsys6StringESt4pairIKS1_iESt10_Select1stIS4_ESt4lessIS1_ESaIS4_EE8_S_rightEPSt18_Rb_tree_node_base+0, >>>> recompile with -ffunction-sections >>> So did you recompile with -ffunction-sections? >>> >>> The basic problem is that the linker was unable to insert a jump >>> to the requested function because it was too far away. Some targets >>> like hppa have short branch distances and we use intermediate stub >>> tables to get around that. However, we can't insert stub tables just >>> anywhere, they need to go between sections. Therefore you need to >>> break up this object file. >> I think there is a real bug here but nobody has provided a test case. >> -ffunction-sections >> probably won't help. > > Confirmed, it is a regression in gcc 4.5. If I build using 4.4.6 > everything works fine. I'll file a bug report tonight. Everything _compiles_ fine. The process later goes into an endless loop again if I call the compiled binary with a source directory. This does not happen with arguments like "--help" or "--version", so I overlooked that at first. So: -compiling/linking with g++ 4.5 fails -compiling/linking with g++ 4.4 works, but the result is unusable John, do you need anything more from me? Things I can test? Which version is your patch against? Eike -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 8/29/2011 4:12 AM, Rolf Eike Beer wrote: >> On 8/25/2011 10:06 AM, Carlos O'Donell wrote: >>> On 8/25/2011 6:37 AM, Rolf Eike Beer wrote: >>>> const&)]+0xbc): cannot reach >>>> 00004abb__ZNSt8_Rb_treeIN5cmsys6StringESt4pairIKS1_iESt10_Select1stIS4_ESt4lessIS1_ESaIS4_EE8_S_rightEPSt18_Rb_tree_node_base+0, >>>> recompile with -ffunction-sections >>> So did you recompile with -ffunction-sections? >>> >>> The basic problem is that the linker was unable to insert a jump >>> to the requested function because it was too far away. Some targets >>> like hppa have short branch distances and we use intermediate stub >>> tables to get around that. However, we can't insert stub tables just >>> anywhere, they need to go between sections. Therefore you need to >>> break up this object file. >> I think there is a real bug here but nobody has provided a test case. >> -ffunction-sections >> probably won't help. > Confirmed, it is a regression in gcc 4.5. If I build using 4.4.6 > everything works fine. I'll file a bug report tonight. > Interesting, there's not much difference in the PA backend for these two versions. Add me (danglin at gcc.gnu.org) to the CC list on the GCC bug report and I'll try to duplicate the problem. Thanks, Dave
You wrote: > On 8/29/2011 4:12 AM, Rolf Eike Beer wrote: > > Confirmed, it is a regression in gcc 4.5. If I build using 4.4.6 > > everything works fine. I'll file a bug report tonight. > > Interesting, there's not much difference in the PA backend for these two > versions. > > Add me (danglin at gcc.gnu.org) to the CC list on the GCC bug report and > I'll try to > duplicate the problem. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50230 Eike
On 29-Aug-11, at 2:31 PM, Rolf Eike Beer wrote: > You wrote: >> On 8/29/2011 4:12 AM, Rolf Eike Beer wrote: > >>> Confirmed, it is a regression in gcc 4.5. If I build using 4.4.6 >>> everything works fine. I'll file a bug report tonight. >> >> Interesting, there's not much difference in the PA backend for >> these two >> versions. >> >> Add me (danglin at gcc.gnu.org) to the CC list on the GCC bug >> report and >> I'll try to >> duplicate the problem. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50230 > > Eike The problem appears to be that comdat groups and stubs don't get along with each other. Comdat groups seem to get merged and this can result in out of range branches. Linking with the --unique='.text.*' option avoids the error, but this probably breaks comdat and discard support. For now, I think the best solution (untested) is to configure GCC with the --disable-comdat option. I'm going to file a binutils PR. Dave -- John David Anglin dave.anglin@bell.net -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 9/7/2011 7:35 PM, John David Anglin wrote: > > On 29-Aug-11, at 2:31 PM, Rolf Eike Beer wrote: > >> You wrote: >>> On 8/29/2011 4:12 AM, Rolf Eike Beer wrote: >> >>>> Confirmed, it is a regression in gcc 4.5. If I build using 4.4.6 >>>> everything works fine. I'll file a bug report tonight. >>> >>> Interesting, there's not much difference in the PA backend for these two >>> versions. >>> >>> Add me (danglin at gcc.gnu.org) to the CC list on the GCC bug report and >>> I'll try to >>> duplicate the problem. >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50230 >> >> Eike > > > The problem appears to be that comdat groups and stubs don't get along > with each other. Comdat groups seem to get merged and this can result > in out of range branches. > > Linking with the --unique='.text.*' option avoids the error, but this probably > breaks comdat and discard support. > > For now, I think the best solution (untested) is to configure GCC with the > --disable-comdat option. > > I'm going to file a binutils PR. Interesting analysis. I don't see how you can fix this though. Support multiple comdat groups and arrange for the merging to happen correctly? Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Index: config/pa/pa.c =================================================================== --- config/pa/pa.c (revision 178012) +++ config/pa/pa.c (working copy) @@ -7385,7 +7385,7 @@ return 24; else { - if (!TARGET_LONG_CALLS && distance < 240000) + if (!TARGET_LONG_CALLS && distance < MAX_PCREL17F_OFFSET) return 8; if (TARGET_LONG_ABS_CALL && !flag_pic) @@ -7598,7 +7598,7 @@ /* pc-relative branch. */ if (!TARGET_LONG_CALLS && ((TARGET_PA_20 && !sibcall && distance < 7600000) - || distance < 240000)) + || distance < MAX_PCREL17F_OFFSET)) length += 8; /* 64-bit plabel sequence. */ @@ -7957,7 +7957,7 @@ if (TARGET_FAST_INDIRECT_CALLS || (!TARGET_PORTABLE_RUNTIME && ((TARGET_PA_20 && !TARGET_SOM && distance < 7600000) - || distance < 240000))) + || distance < MAX_PCREL17F_OFFSET))) return 8; if (flag_pic) Index: config/pa/pa.h =================================================================== --- config/pa/pa.h (revision 178012) +++ config/pa/pa.h (working copy) @@ -1512,3 +1512,12 @@ #undef TARGET_HAVE_TLS #define TARGET_HAVE_TLS true #endif + +/* The maximum offset in bytes for a PA 1.X pc-relative call to the + tail of the preceding stub table. The selected offsets have been + chosen to allow approximately one call stub for every 86 instructions. + A long branch stub is two instructions when not generating PIC code. + More space is allowed for stubs when generating PIC code since HP-UX + and Linux import stubs are seven and four instructions, respectively. */ +#define MAX_PCREL17F_OFFSET \ + (flag_pic ? (TARGET_HPUX ? 198164 : 221312) : 240000)