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.