This is the mail archive of the gcc@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]

Re: libgcc_s.so.1 ASIS won't work with glibc.


On Tue, Jul 03, 2001 at 07:53:02AM -0700, H . J . Lu wrote:
> When you recompile glibc with g++ v3, your binaries get
> 
> 1. The g++ v2 EH from libgcc.a in g++ v2. And
> 2. The frame functions in glibc linked against libgcc.a in g++ v3.

Ok, what are the reasons that the DSO would use the v2 EH
that it has included in itself?  It is earlier in the search
order than glibc.  (I'm going to ignore -Bsymbolic, symbol
versioning, and other scenerios that result in multiple 
versions of libgcc active -- that didn't work before either,
and was in fact most of the driving force for the existance
of libgcc_s.so.)

Since these functions are present in the DSO, the DSO uses
exception handling (since the crtbegin references are weak,
which is not enough to pull the routines out of libgcc.a),
which means that all of the associated routines like __throw,
__frame_state_for, etc, are also present.

Since we've already established that the DSO is before glibc,
that means _none_ of the routines in glibc are going to get
used at all.

Therefore your argument is false.

There _is_ a failure mode here, but it is not the one you
describe.  If the application throws through qsort (or one of
the other similar functions glibc compiles with -fexceptions),
the __frame_state_for linked into the application will not be
able to interpret the pc-relative FDE encodings.

I don't know what to say about this.  I believe that this 
situation is rare enough as to not be worth worring about 
overmuch.



r~


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