------- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-05 00:15 ------- Subject: Re: Shared libstdc++ fails to link
> I'm not sure what "EH data" is being described here. Certainly, it > makes no sense at all to emit EH unwind information for functions which > are not part of the current object file; their unwind information will > be emitted with those function. > > What sort of data is being emitted? Unwind data. We're talking about functions compiled in the current object. On the HP-UX PA-RISC targets, unwind data is placed in the data subspace. In principle, there's no problem with other EH data as the HP linker can handle the relocations in "noload" subspaces. In HP-UX 10, one-only was implemented using COMDAT subspaces. When the linker sees the second or later occurence of a COMDAT subspace with the same name as the first one, it nullifies these subspaces and doesn't emit them in the final object. However, it turns out that that the linker can't handle relocations referring to symbols in that are in a nullified subspace if these references occur in a subspace that is loadable. Didn't see this when developing the DWARF2 unwind support for the 4.1 branch because of the following issue. There are numerous "one-only/weak" functions which don't bind locally in libstdc++. Previously, *ALL* these functions were determined to be nothrow and no unwind data was emitted for them. Now, unwind data is being emitted because these functions don't bind locally. This breaks the HP-UX 10 DWARF2 unwind implementation (obviously a latent bug) because of the relocation issue mentioned above. It also increases the amount of DWARF2 unwind data emitted on all targets using this exception mechanism and might have an impact on search performance when unwinding. It's my belief that DWARF2 unwind support present in GCC 4.1.0 and 4.1.1 for HP-UX 10 was usable in spite of the linker limitation. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
