On Wed, Mar 29, 2017 at 5:20 PM, Jeff Law <l...@redhat.com> wrote: > 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.
Yes, collect2 essentially creates a constructor that it schedules at a high priority to record the frames that it found during the scan. Thanks, David
