[PATCH] Real fix for AIX exception handling

[Jeff Law]

On 03/29/2017 02:56 PM, David Edelsohn wrote:
> On Wed, Mar 29, 2017 at 4:48 PM, Jeff Law <law@redhat.com> wrote:
>> On 03/29/2017 02:21 PM, David Edelsohn wrote:
>>>
>>>
>>> The problem is GCC EH tables and static linking.  libstdc++ and the
>>> main application are ending up with two separate copies of the tables
>>> to register EH frames.
>>>
>>> Static linking worked in GCC 4.8, but not in GCC 4.9.  I have been
>>> trying to understand what changed and if GCC 4.8 worked by accident.
>>>
>>> Note that AIX does not install a separate libstdc++ static archive and
>>> instead statically links against the shared object.  libstdc++
>>> apparently uses the EH table referenced when it was bound by collect2
>>> and the application uses the one created when the executable is
>>> created -- the libgcc_eh.a solution doesn't work.  Again, the question
>>> is why this apparently functioned correctly for GCC.4.8.
>>>
>>> There was a change to constructor order around that time and that may
>>> have affected where EH frames were recorded.
>>
>> Hmm, the act of statically linking against the shared libstdc++ certainly
>> adds a wrinkle here.
>>
>> It's been a *long* time since I had to think about this stuff for a non-ELF
>> system.  Please correct me if I goof anything up.
>>
>> Since we build a shared libstdc++, doesn't that set up a library ctor which
>> should register the EH tables for the library as a whole?
>>
>> When we link against that library statically, we have to arrange to run the
>> library's ctor from the main program's global ctors.  Right?  ie, it should
>> be OK to have separate copies -- we just have to get them all registered
>> properly?  Right?
>
> GCC has to get them all of the EH frames registered into one table,
> otherwise libgcc walks the frames to find a catcher for an exception
> and doesn't find the address of the program counter in the sorted
> table because that range was recorded in the other table.
Right.  We have to register all the frame_infos into a single table.   I 
was mostly focused on the registration mechanism.  My recollection is 
that we'll create a library-wide ctor for libstdc++ which would register 
the frame_infos for the library and that ctor should be run by the main 
program.  The main program will collect its own frame_infos and register 
them as well.

At least that's my fuzzy recollection.

jeff