This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)


Richard Henderson <rth@redhat.com> writes:

> On 01/17/2012 04:07 AM, Rainer Orth wrote:
>> * The 32-bit failures on Solaris 8 to 10 have a different root cause:
>>   _Unwind_Find_FDE returns NULL for an address in _ZGTtL2f1v (f1()).  It
>>   turns out that there are two copies of the unwinder in eh-1.exe: one
>>   from libgcc_s.so.1, and another one from libgcc_eh.a.  eh-1.o has a
>>   reference to _Unwind_Resume (don't yet know why), which is resolved
>>   from libgcc_eh.a.  This doesn't happen on Solaris 11, which uses the
>>   dl_iterate_phdr based unwinder, thus no __register_frame_info_bases.
>
> Er.. how did we get two copies?

The link line boils down to

ld -o eh-1.exe crt1.o crti.o crtbegin.o eh-1.o -litm -lstdc++ -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh crtend.o crtn.o

The eh-1.o reference to _Unwind_Resume drags in one copy of the unwinder
from libgcc_eh.a, while libstdc++.so is linked against libgcc_s.so.1,
providing another copy.

> I don't think this change is correct, as it seems just as likely
> that we'd hit the same problem with real applications.  This just
> seems like it's papering over the real problem.

Quite possible.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]