On 03/29/2017 02:56 PM, David Edelsohn wrote:
On Wed, Mar 29, 2017 at 4:48 PM, Jeff Law <l...@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
