libgcc problems

libgcc problems

[Andrey Slepuhin]

Hi,

To finalize a discussion about multiple instances of static
variables in libgcc.a (and while egcs-980115 is bootstrapped :-)),
I want to obtain *precise* answers to the following questions:

1) Should we enable by default run-time linking for AIX 4.2 and later?
2) Should we make a patch to move all libgcc's static variables
   into separate shared module for AIX? If yes, I can prepare
   such patch - this is not difficult and needs only few
   changes (I'm already have 80% of such patch).
3) If 1)-2) unacceptable, should we try to do some dirty hack to solve
   a problem with the following method: using pointers to variables
   instead of variables itself in libgcc, and initializing these
   pointers when program starts. This is possible in principle,
   but needs some additional code to be automatically generated
   by collect2, and some changes in libgcc.
4) If 1)-3) is unacceptable I'll treat egcs's exception handling
   on AIX broken.
5) Should we hope that a problem with correct TOC restoring will be
   fixed?

Regards,
Andrey.

P.S. It seems there is a bug in egcs-980115 calls.c because of #ifdef
usage inside a macro. Below there is a possible patch.

Re: libgcc problems

[David Edelsohn]

>>>>> Andrey Slepuhin writes:

Andrey> To finalize a discussion about multiple instances of static
Andrey> variables in libgcc.a (and while egcs-980115 is bootstrapped :-)),
Andrey> I want to obtain *precise* answers to the following questions:

Andrey> 1) Should we enable by default run-time linking for AIX 4.2 and later?

	This is not the default for AIX and xlc.  How much do we want to
GCC to create a SVR4 environment by default.

Andrey> 2) Should we make a patch to move all libgcc's static variables
Andrey> into separate shared module for AIX? If yes, I can prepare
Andrey> such patch - this is not difficult and needs only few
Andrey> changes (I'm already have 80% of such patch).

	This probably is the cleaner solution and will work regardless of
the AIX options.

Andrey> 5) Should we hope that a problem with correct TOC restoring will be
Andrey> fixed?

	Is this really a bug?  If I followed the earlier discussions, I
think this is a problem of mixing setjmp/longjmp across shared libraries.
But the AIX TOC anchor simply is a dedicated GPR which should be saved and
restored by setjmp/longjmp.  I guess that I do not understand why the TOC
is getting corrupted in this case.  Or should save/restore_stack_nonlocal
always save and restore the TOC as well as the backchain because the
parent function may be in a different module with a different TOC?  And
somehow the receiver automatically is suppose to find and fix its TOC
anchor when there was no accompanying store to prepare the value
beforehand? 

	How is the SVR4 GOT automagically fixed-up in this case?

David

Re: libgcc problems

[Andrey Slepuhin]

[-- Attachment #1: Type: text/plain, Size: 1759 bytes --]

On 18-Jan-98 David Edelsohn wrote:
>>>>>> Andrey Slepuhin writes:
> Andrey> 2) Should we make a patch to move all libgcc's static variables
> Andrey> into separate shared module for AIX? If yes, I can prepare
> Andrey> such patch - this is not difficult and needs only few
> Andrey> changes (I'm already have 80% of such patch).
> 
>       This probably is the cleaner solution and will work regardless of
> the AIX options.

But will this solution be accepted by egcs maintainers?

> 
> Andrey> 5) Should we hope that a problem with correct TOC restoring will be
> Andrey> fixed?
> 
>       Is this really a bug?  If I followed the earlier discussions, I
> think this is a problem of mixing setjmp/longjmp across shared libraries.
> But the AIX TOC anchor simply is a dedicated GPR which should be saved and
> restored by setjmp/longjmp.  I guess that I do not understand why the TOC
> is getting corrupted in this case.  Or should save/restore_stack_nonlocal
> always save and restore the TOC as well as the backchain because the
> parent function may be in a different module with a different TOC?  And
> somehow the receiver automatically is suppose to find and fix its TOC
> anchor when there was no accompanying store to prepare the value
> beforehand?

Unfortunately my knowledge in discussed problem is poor, but the problem
occures not only when building shared libgcc. The following trivial
example (testsuite is attached) shows that throwing an exception from
shared library is totally broken on AIX due to the same reason.
(I also have this test failed on x86 linux with egcs-1.0 installed,
but didn't look why yet).
I'm also worried about duplicated __tiPc symbol. What does it mean?
should I prevent exporting it in collect2?

Regards,
Andrey.


[-- Attachment #2: throw-from-shared-test.tar.gz --]
[-- Type: application/x-gzip, Size: 522 bytes --]

Re: libgcc problems

[David Edelsohn]

>>>>> Andrey Slepuhin writes:

Andrey> I'm also worried about duplicated __tiPc symbol. What does it mean?
Andrey> should I prevent exporting it in collect2?

	I have no ideas about the origin or purpose of this symbol.

David

Re: libgcc problems

[Andrey Slepuhin]

On 19-Jan-98 David Edelsohn wrote:
>>>>>> Andrey Slepuhin writes:
> 
> Andrey> I'm also worried about duplicated __tiPc symbol. What does it mean?
> Andrey> should I prevent exporting it in collect2?
> 
>       I have no ideas about the origin or purpose of this symbol.

I guess that this is typeinfo function for char*, i.e I should
disable exporting all typeinfo functions in collect2. But what other
automatically generated symbols I should disable for export?
I'm slightly confused with this situation because there are
two possible solutions:
1) To disable export of automatically generated symbols or to make
   non-global. This solution leads to some duplicated code, but
   avoids overhead with global calls.
2) To export automatically generated symbols and to resolve
   conflicts using -frepo option, which currently resolves
   only template conflicts.

Any opinion?

Andrey.

Re: libgcc problems

[David Edelsohn]

>>>>> Andrey Slepuhin writes:

Andrey> I'm also worried about duplicated __tiPc symbol. What does it mean?
Andrey> should I prevent exporting it in collect2?

Andrey> I guess that this is typeinfo function for char*, i.e I should
Andrey> disable exporting all typeinfo functions in collect2. But what other
Andrey> automatically generated symbols I should disable for export?

Andrey> I'm slightly confused with this situation because there are
Andrey> two possible solutions:

Andrey> 1) To disable export of automatically generated symbols or to make
Andrey> non-global. This solution leads to some duplicated code, but
Andrey> avoids overhead with global calls.

Andrey> 2) To export automatically generated symbols and to resolve
Andrey> conflicts using -frepo option, which currently resolves
Andrey> only template conflicts.

	Does solution 1 mean not exporting symbols with double-underscore
("__") prefix?

David

Re: libgcc problems

[Andrey Slepuhin]

On 19-Jan-98 David Edelsohn wrote:
>>>>>> Andrey Slepuhin writes:
> 
> Andrey> I'm also worried about duplicated __tiPc symbol. What does it mean?
> Andrey> should I prevent exporting it in collect2?
> 
> Andrey> I guess that this is typeinfo function for char*, i.e I should
> Andrey> disable exporting all typeinfo functions in collect2. But what other
> Andrey> automatically generated symbols I should disable for export?
> 
> Andrey> I'm slightly confused with this situation because there are
> Andrey> two possible solutions:
> 
> Andrey> 1) To disable export of automatically generated symbols or to make
> Andrey> non-global. This solution leads to some duplicated code, but
> Andrey> avoids overhead with global calls.
> 
> Andrey> 2) To export automatically generated symbols and to resolve
> Andrey> conflicts using -frepo option, which currently resolves
> Andrey> only template conflicts.
> 
>       Does solution 1 mean not exporting symbols with double-underscore
> ("__") prefix?

It seems that at least there are some exceptions to this rule (as with
__terminate_func, which should be available anywhere to be accessed
from inline set_terminate()).

Andrey.

Re: libgcc problems

[David Edelsohn]

>>>>> Andrey Slepuhin writes:

>> Does solution 1 mean not exporting symbols with double-underscore
>> ("__") prefix?

Andrey> It seems that at least there are some exceptions to this rule (as with
Andrey> __terminate_func, which should be available anywhere to be accessed
Andrey> from inline set_terminate()).

	Maybe it is easier to test for the exceptional cases that *should*
be exported.

David

Re: libgcc problems

[David Edelsohn]

>>>>> Andrey Slepuhin writes:

Andrey> The only possible
Andrey> problem is if a shared library will be loaded via dlopen(). I'm not
Andrey> sure that in this case imported symbols will be resolved (David,
Andrey> remember my unaccepted -dll collect2 flag? With the solution above
Andrey> it also can be used to tell collect2 that we should use real library
Andrey> instead of import list).

	dlopen() behavior depends on options used when the application was
linked, e.g. -brtl.  Symbols listed as deferred imports will be resolved
immediately and automatically unless RTLD_NOAUTODEFER option is used in
dlopen() call [L_NOAUTODEFER option is passed to AIX load() call].
An explicit call to resolve defered symbols then is required.

David

libgcc problems

[Andrey Slepuhin]

Hi,

It seems I found a good solution for our libgcc problems.
In general, we can link shared library without libgcc,
but we can use an import file with all global libgcc symbols
instead. This import file should begin with

#! .

line, which means that imported symbols will be resolved
from main executable. As I understand this works on all AIXes.
We also can use a reduced libgcc when building shared library and
can use an import list which contains, for example, only global variables.
This avoids overhead with glink code for libgcc's functions, but
make impossible automatic generation of import list by collect2.

I checked that such solution works, and it can solve most problems
when linking shared object with a static library. The only possible
problem is if a shared library will be loaded via dlopen(). I'm not
sure that in this case imported symbols will be resolved (David,
remember my unaccepted -dll collect2 flag? With the solution above
it also can be used to tell collect2 that we should use real library
instead of import list).

Regards,
Andrey.

Re: libgcc problems

[Mike Stump]

If possible, making the variables external and weak or common might be
the way to go.

Re: libgcc problems

[Andrey Slepuhin]

On 19-Jan-98 Mike Stump wrote:
> If possible, making the variables external and weak or common might be
> the way to go.

AIX native ld doesn't support weak symbols. As for common symbols,
they cannot help to resolve multiple instances in different shared
libraries.

Andrey.

Re: libgcc problems

[Richard Henderson]

On Thu, Jan 15, 1998 at 12:07:22PM -0500, David Edelsohn wrote:
> 	The SVR4 case only seems to handle a secondary GOT.  How does SVR4
> handle this normally?  It looks like one needs to materialize a copy of
> the original TOC anchor.

The __builtin_setjmp's jmp_buf is 5 words, three of which are used
in the normal case.  Perusing the source it seems that things are
not set up as nice as they could be for adding machine dependent
stuff, but it still should not be too difficult to arrange for
whatever you need to be stored in the two remaining words.

In fact, I have some changes laying about that made the builtin
setjmp/longjmp more efficient on Alpha -- let me know what registers
need saving and I'll see about fixing it up for ppc as well.


r~

Re: libgcc problems

[David Edelsohn]

>>>>> Andrey Slepuhin writes:

Andrey> I agree that it is better to have local copies of __sjthrow() and
Andrey> other exception handling functions - this avoid overhead with
Andrey> glink code. But __terminate_func is rare used and can go to
Andrey> shared library. More difficult to decide what to do with
Andrey> top_elt and get_eh_context, which are static variables and *must*
Andrey> have only one instance. I didn't looked if there is any overhead
Andrey> accessing non-local variables (as with non-local functions). If no,
Andrey> they also can be shared.

	The overhead for shared variables is the linker and loader need to
arrange to resolve them in each TOC used to access them.  Shared variables
are accessed via the TOC and the loader fills in their address.  Because
of the clumsy way that static variable currently are handled by GCC,
shared variables actually are better and use up less TOC entries.

Andrey> Interesting, is there some code reserved for exception handling
Andrey> in AIX libc (or all C++ specific code is in xlC's libC), and if yes,
Andrey> can this code be used for gcc's purposes. E.g. if libc already
Andrey> containes pointer to terminate handler, we can use it instead
Andrey> of __terminate_func.
Andrey> David, do you have any references to mentioned PowerOpen ABI?
Andrey> This is very interesting in any case...

	libC.a handles exception handling, but I am not sure whether it
could be used to supply GCC's stack walking functionality.  The traceback
table already is documented in the GCC output_epilog routine for the
rs6000 port and /usr/include/sys/debug.h.

David

Re: libgcc problems

[David Edelsohn]

>>>>> Jeffrey A Law writes:

>> Understand. Uphh! After long debugging I found a problem! This is because
>> in current exception handling implementation __sjthrow() code can not
>> be in shared library. Otherwise, no operation to restore original TOC
>> anchor pointer is performed.

	I guess I do not understand if this is a general problem and
nonlocal_goto_receiver needs to be fixed regardless.  Is the issue that
__sjthrow() must have local copies for each module or __sjthrow() cannot
throw through a shared library?  If the former, isn't this yet another
reason not to make libgcc.a shared -- at least on AIX?

	The general answer is to find someone who has the time to
correctly implement exception handling on AIX.  The PowerOpen ABI adds an
epilogue to each function which specifically provides the information
necessary to walk the stack.  This will save the sjlj space, be compatible
with C-Set++, and be more efficient.  Someone just needs to take the time
to teach the GCC exception handling code about this -- I can provide
guidance but do not have the time to implement it myself.

	I would think that implementing exception handling correctly for
AIX would be a better way to spend the time than fixing something that
only is broken because of the sjlj implementation of exception handling.

David

Re: libgcc problems

[David Edelsohn]

>>>>> Jeffrey A Law writes:

>> The SVR4 case only seems to handle a secondary GOT.  How does SVR4
>> handle this normally?  It looks like one needs to materialize a copy of
>> the original TOC anchor.

Jeff> I don't know about the rs6000/ppc case, but on the PA the TOC is 
Jeff> always at a known offset from the stack.  We just restore it in
Jeff> the receiver code.  Any chance of pulling it out of the stack?

	The rs6000/ppc SVR4 case written by Meissner only is enabled for
the minimal-toc case.  If SVR4 always needs the GOT restored, that
pattern will not be invoked for rs6000 SVR4 either.

	I understand that the GOT is at a fixed address (the TOC anchor is
not), but I am trying to understand if SVR4 somehow automatically knows to
restore the GOT when AIX does not.

	I never have really thought about how to get GCC to materialze the
TOC anchor.  It's value only is created by the linker when an executable
or library is bound.  This is functionality normally left to the linker
because only it knows these values.

David

Re: libgcc problems

[pooh]

On 14-Jan-98 David Edelsohn wrote:
> Andrey Slepuhin writes:
> 
>> I disabled exporting these symbols in collect2, but still have problems.
>> Now linking process damages nop instruction after "bl __cp_exception_info",
>> which is present in .s file. The only difference with original successful
>> build is that some symbols (including __cp_exception_info) from libgcc.a
>> are reexported when building shared libstdc++. The test example is trivial
>> and is attached. I don't understand such strange behaviour :-(
>>
>> What about original problem with multiple instances of libgcc's
>> static variables? Your opinion?
> 
>  I am not sure what you mean by "damages nop instruction".  The no-op
> (cror 31,31,31) specificallly is there as a place-holder for the linker.  If
> you call outside
> of the linkage unit, the linker fills in the instruction to restore the TOC.
> On AIX a
> function pointer really is a function descriptor with the pointer to the
> entry
> to the local
> function, the local TOC anchor, and an environment which is NULL for C.  The
> linker
> fills in the local TOC anchor for the descriptor.  If the call was resolved
> outside the
> module, the linker replaces the no-op with a restore of the original TOC
> anchor
> pointer
> to the TOC register.

Understand. Uphh! After long debugging I found a problem! This is because
in current exception handling implementation __sjthrow() code can not
be in shared library. Otherwise, no operation to restore original TOC
anchor pointer is performed.

Regards,
Andrey.

Re: libgcc problems

[David Edelsohn]

>>>>> pooh  writes:

>> Another idea: should collect2 not export any symbols with names reserved for
>> the implementation, e.g. ones beginning with double underscore and ones
>> beginning with
>> single underscore and capital letter?

Andrey> Good question! It seems to me that the answer should be yes except
Andrey> symbols which can be inserted into code directly by compiler.

	I guess I do not follow the exception case.  Why or when should
the compiler "insert" such symbols meant to be exported.

>> I do not know whether _ptrgl and _savef14 was an illegal name or all
>> single underscore names should be protected.  AIX does not prepend
>> underscores to user symbols.  I do not know enough about the current
>> implementation to state categorically that those symbols never need to
>> be exported in some other instance.

Andrey> We shouldn't take care about symbols like _ptrgl or _savef14 unless
Andrey> we want to enable reexporting symbols from static libraries (exactly
Andrey> a problem I got playing with libgcc), because these symbols are
Andrey> contained in a static member of libc.a.

	Did collect2 try to re-export these reserved symbols itself or did
you do something extra which caused the problem?  GCC/collect2 never
should re-export symbols from a static library unless a user explicitly
creates an export list and (hopefully) knows what he or she is doing.

David

Re: libgcc problems

[Andrey Slepuhin]

On 15-Jan-98 David Edelsohn wrote:
> Andrey> We shouldn't take care about symbols like _ptrgl or _savef14 unless
> Andrey> we want to enable reexporting symbols from static libraries (exactly
> Andrey> a problem I got playing with libgcc), because these symbols are
> Andrey> contained in a static member of libc.a.
> 
>       Did collect2 try to re-export these reserved symbols itself or did
> you do something extra which caused the problem?  GCC/collect2 never
> should re-export symbols from a static library unless a user explicitly
> creates an export list and (hopefully) knows what he or she is doing.

I did something extra, i.e. playing with libgcc, I enabled collect2 to
reexport some symbols from static libraries, which normally should be
disabled.

Andrey.

Re: libgcc problems

[David Edelsohn]

>>>>> Jeffrey A Law writes:

>> Understand. Uphh! After long debugging I found a problem! This is because
>> in current exception handling implementation __sjthrow() code can not
>> be in shared library. Otherwise, no operation to restore original TOC
>> anchor pointer is performed.

Jeff> Sounds like the rs6000.md needs a nonlocal_goto_receiver pattern to
Jeff> restore the TOC.

	rs6000.md does have a nonlocal_goto_receiver pattern added by
Meissner, but it only handles the GCC minimal-toc case where GCC has
allocated a secondary TOC register.  The code assumes that the system TOC
is correct in order to access the secondary TOC anchor value.  It looks
like all nonlocal patterns for AIX assume that all of the functions are
within the same module.

	The SVR4 case only seems to handle a secondary GOT.  How does SVR4
handle this normally?  It looks like one needs to materialize a copy of
the original TOC anchor.

David

Re: libgcc problems

[Andrey Slepuhin]

On 15-Jan-98 David Edelsohn wrote:
>>>>>> Jeffrey A Law writes:
> 
>>> Understand. Uphh! After long debugging I found a problem! This is because
>>> in current exception handling implementation __sjthrow() code can not
>>> be in shared library. Otherwise, no operation to restore original TOC
>>> anchor pointer is performed.
> 
>       I guess I do not understand if this is a general problem and
> nonlocal_goto_receiver needs to be fixed regardless.  Is the issue that
> __sjthrow() must have local copies for each module or __sjthrow() cannot
> throw through a shared library?  If the former, isn't this yet another
> reason not to make libgcc.a shared -- at least on AIX?

I agree that it is better to have local copies of __sjthrow() and
other exception handling functions - this avoid overhead with
glink code. But __terminate_func is rare used and can go to
shared library. More difficult to decide what to do with
top_elt and get_eh_context, which are static variables and *must*
have only one instance. I didn't looked if there is any overhead
accessing non-local variables (as with non-local functions). If no,
they also can be shared.

>       The general answer is to find someone who has the time to
> correctly implement exception handling on AIX.  The PowerOpen ABI adds an
> epilogue to each function which specifically provides the information
> necessary to walk the stack.  This will save the sjlj space, be compatible
> with C-Set++, and be more efficient.  Someone just needs to take the time
> to teach the GCC exception handling code about this -- I can provide
> guidance but do not have the time to implement it myself.

Interesting, is there some code reserved for exception handling
in AIX libc (or all C++ specific code is in xlC's libC), and if yes,
can this code be used for gcc's purposes. E.g. if libc already
containes pointer to terminate handler, we can use it instead
of __terminate_func.
David, do you have any references to mentioned PowerOpen ABI?
This is very interesting in any case...

> 
>       I would think that implementing exception handling correctly for
> AIX would be a better way to spend the time than fixing something that
> only is broken because of the sjlj implementation of exception handling.

I'm not sure that AIX native tools don't use some global variables,
but these tools are not limited by a condition of static libgcc.
So, exception handling implementations other than sjlj may also cause
problems on AIX unless we make some of libgcc code shared.

Andrey.

Re: libgcc problems

[pooh]

On 14-Jan-98 David Edelsohn wrote:
 
>  GCC now is getting into the realm of C++ compiler support libraries.  These
> are
> very carefully crafted for AIX.  GCC is trying to stuff its SVR4 policies
> into
> AIX and
> creating problems.  I am not sure exactly how to fix this and which problem
> to
> fix.  I think
> the right answer is to fix libgcc.a to utilize these symbols in a safe way
> instead of relying
> upon SVR4 linker details to hide the problem.  Obviously, that is easy for me
> to say from
> my perspective and my priorities although I cannot fix it myself.  The world
> is
> not SVR4/ELF
> -- at least not yet.

I guess that the *only* way to solve a problem of multiple instances
of libgcc's static variables for *all* AIXes is to move these statics
into shared object which can be inserted into libgcc.a. We shouldn't
afraid LD_LIBRARY_PATH problem - it doesn't exist for AIX native linker,
but all shared libraries will be nailed to libgcc location (so, we need
to relink them when changing gcc version).

>  Another idea: should collect2 not export any symbols with names reserved for
> the implementation, e.g. ones beginning with double underscore and ones
> beginning with
> single underscore and capital letter?

Good question! It seems to me that the answer should be yes except symbols
which can be inserted into code directly by compiler.

> I do not know whether _ptrgl and _savef14 was
> an illegal name or all single underscore names should be protected.  AIX does
> not
> prepend underscores to user symbols.  I do not know enough about the current
> implementation to state categorically that those symbols never need to be
> exported in
> some other instance.

We shouldn't take care about symbols like _ptrgl or _savef14 unless
we want to enable reexporting symbols from static libraries (exactly
a problem I got playing with libgcc), because these symbols are
contained in a static member of libc.a.

Regards,
Andrey.

Re: libgcc problems

[Jeffrey A Law]

  In message < 9801151707.AA23404@rios1.watson.ibm.com >you write:
  > 	rs6000.md does have a nonlocal_goto_receiver pattern added by
  > Meissner, but it only handles the GCC minimal-toc case where GCC has
  > allocated a secondary TOC register.  The code assumes that the system TOC
  > is correct in order to access the secondary TOC anchor value.  It looks
  > like all nonlocal patterns for AIX assume that all of the functions are
  > within the same module.
  > 
  > 	The SVR4 case only seems to handle a secondary GOT.  How does SVR4
  > handle this normally?  It looks like one needs to materialize a copy of
  > the original TOC anchor.
I don't know about the rs6000/ppc case, but on the PA the TOC is 
always at a known offset from the stack.  We just restore it in
the receiver code.  Any chance of pulling it out of the stack?

jeff

Re: libgcc problems

[Andrey Slepuhin]

On 15-Jan-98 Jeffrey A Law wrote:
> 
>   > Understand. Uphh! After long debugging I found a problem! This is because
>   > in current exception handling implementation __sjthrow() code can not
>   > be in shared library. Otherwise, no operation to restore original TOC
>   > anchor pointer is performed.
> Sounds like the rs6000.md needs a nonlocal_goto_receiver pattern to restore
> the TOC.

I'm not sure, because I saw nonlocal_goto_receiver pattern in rs6000.md
(I can not guess if it is correct), but may be a problem is due to the fact
that __sjthrow ends with __builtin_longjmp?

Andrey.

Re: libgcc problems

[Jeffrey A Law]

  > Understand. Uphh! After long debugging I found a problem! This is because
  > in current exception handling implementation __sjthrow() code can not
  > be in shared library. Otherwise, no operation to restore original TOC
  > anchor pointer is performed.
Sounds like the rs6000.md needs a nonlocal_goto_receiver pattern to restore
the TOC.
jeff