[Bug target/35222] [4.3 Regression] EH output contains procedure label without P' selector

["dave at hiauly1 dot hia dot nrc dot ca" <gcc-bugzilla@gcc.gnu.org>]

------- 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