------- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2008-02-17 16:45 ------- Subject: Re: [4.3 Regression] EH output contains procedure label without P' selector
> Does this also fail for hppa2.0w-hp-hpux11.11 which would be a secondary > target > unlike hppa1.1-hp-hpux10.20 which is neither primary nor secondary? It doesn't affect hppa2.0w-hp-hpux11.11. There is a difference in the methods used to achieve one-only support. hppa2.0w-hp-hpux11.11 uses secondary definitions and hppa1.1-hp-hpux10.20 COMDAT subspaces. My current understanding of the problem is that the error occurs when a COMDAT subspace is not used. This leads to the situation where the local symbols referenced in the EH data no longer are satisfied. It's still a puzzle as to why this didn't appear before. I'm testing a one line fix to the encoding to add the P' descriptor. This isn't exactly obvious as normally when the P' descriptor is used the pointer ends up pointing to a function descriptor rather than to the label in the code. However, in this case, the labels are local and not exported. I think the linker is smart enough in this case to create a direct pointer. I'm hoping in the COMDAT case that a function descriptor will be created and there won't be problems with unresolved symbols. If the above doesn't work, I have a small change to config.gcc to force sjlj exception suport. I've been trying to test the above change but hit the libstdc++ breakage on head. I have had one successful build with the change on hppa64-hp-hpux11.11 using 4.2.4. libstdc++ builds with the change on hppa2.0w-hp-hpux11.11 on head. Unfortunately, my hppa1.1-hp-hpux10.20 system is somewhat slow and I'm just restarting the build there. I'm also testing with 11.00. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35222
