[PATCH] Real fix for AIX exception handling

[PATCH] Real fix for AIX exception handling

[Michael Haubenwallner]

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

Hi,

as far as I have discovered, the real problem with AIX exception handling is
that the exception landing pads are symbols that must not (but still are)
exported from shared libraries - even libstdc++.

I'm wondering if attached libtool(!)-patch would fix even that GDB problem
once applied to each(!) shared library creation procedure.

However, each workaround still applies as long as there's a single shared
library involved that has not stopped exporting these symbols yet.

Thoughts?

Maybe gcc's collect2 should apply this additional symbol filter itself when
calling (AIX) ld, rather than leaving this to each build system?

Thanks!
/haubi/

[-- Attachment #2: 0001-AIX-Stop-exporting-more-_GLOBAL__-symbols.patch --]
[-- Type: text/x-patch, Size: 2017 bytes --]

From 32ca0e6f7bf8d096cc653ac455d66c270b75fdf0 Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner <michael.haubenwallner@ssi-schaefer.com>
Date: Wed, 2 Mar 2016 15:06:48 +0100
Subject: [PATCH 1/4] AIX: Stop exporting more _GLOBAL__ symbols.

* m4/libtool.m4 (_LT_LINKER_SHLIBS): On AIX, GNU g++ generates
_GLOBAL__ symbols as, amongst others, landing pads for C++ exceptions.
These symbols must not be exported from shared libraries, or exception
handling may break for applications with runtime linking enabled.
---
 m4/libtool.m4 | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index ee292af..c2e996c 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -4943,6 +4943,7 @@ m4_if([$1], [CXX], [
     else
       _LT_TAGVAR(export_symbols_cmds, $1)='`func_echo_all $NM | $SED -e '\''s/B\([[^B]]*\)$/P\1/'\''` -PCpgl $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B") || (\$ 2 == "L") || (\$ 2 == "W") || (\$ 2 == "V") || (\$ 2 == "Z")) && ([substr](\$ 1,1,1) != ".")) { if ((\$ 2 == "W") || (\$ 2 == "V") || (\$ 2 == "Z")) { print \$ 1 " weak" } else { print \$ 1 } } }'\'' | sort -u > $export_symbols'
     fi
+    _LT_TAGVAR(exclude_expsyms, $1)='_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*|_GLOBAL__[FID]_.*'
     ;;
   pw32*)
     _LT_TAGVAR(export_symbols_cmds, $1)=$ltdll_cmds
@@ -5398,6 +5399,7 @@ _LT_EOF
 	else
 	  _LT_TAGVAR(export_symbols_cmds, $1)='`func_echo_all $NM | $SED -e '\''s/B\([[^B]]*\)$/P\1/'\''` -PCpgl $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B") || (\$ 2 == "L") || (\$ 2 == "W") || (\$ 2 == "V") || (\$ 2 == "Z")) && ([substr](\$ 1,1,1) != ".")) { if ((\$ 2 == "W") || (\$ 2 == "V") || (\$ 2 == "Z")) { print \$ 1 " weak" } else { print \$ 1 } } }'\'' | sort -u > $export_symbols'
 	fi
+	_LT_TAGVAR(exclude_expsyms, $1)='_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*|_GLOBAL__[FID]_.*'
 	aix_use_runtimelinking=no
 
 	# Test if we are trying to use run time linking or normal
-- 
2.10.2

Re: [PATCH] Real fix for AIX exception handling

[David Edelsohn]

> As far as I have discovered, the real problem with AIX exception handling is
> that the exception landing pads are symbols that must not (but still are)
> exported from shared libraries - even libstdc++.
>
> I'm wondering if attached libtool(!)-patch would fix even that GDB problem
> once applied to each(!) shared library creation procedure.
>
> However, each workaround still applies as long as there's a single shared
> library involved that has not stopped exporting these symbols yet.
>
> Thoughts?
>
> Maybe gcc's collect2 should apply this additional symbol filter itself when
> calling (AIX) ld, rather than leaving this to each build system?
>
> * m4/libtool.m4 (_LT_LINKER_SHLIBS): On AIX, GNU g++ generates
> _GLOBAL__ symbols as, amongst others, landing pads for C++ exceptions.
> These symbols must not be exported from shared libraries, or exception
> handling may break for applications with runtime linking enabled.

Hi, Michael

Thanks for the analysis.

The problem with EH for GDB involves static linking, not runtime
linking. And there seems to be different behavior for GCC 4.8 and GCC
4.9.

The patch seems correct for the runtime linking case, but I don't
believe that it solves all of the EH issues -- at least more
explanation is needed.

I think that the problem for static linking needs to be addressed by collect2.

Thanks, David

P.S. Please explicitly copy me on AIX patches.

Re: [PATCH] Real fix for AIX exception handling

[Jeff Law]

On 03/27/2017 09:41 AM, David Edelsohn wrote:
>> As far as I have discovered, the real problem with AIX exception handling is
>> that the exception landing pads are symbols that must not (but still are)
>> exported from shared libraries - even libstdc++.
>>
>> I'm wondering if attached libtool(!)-patch would fix even that GDB problem
>> once applied to each(!) shared library creation procedure.
>>
>> However, each workaround still applies as long as there's a single shared
>> library involved that has not stopped exporting these symbols yet.
>>
>> Thoughts?
>>
>> Maybe gcc's collect2 should apply this additional symbol filter itself
>> calling (AIX) ld, rather than leaving this to each build system?
>>
>> * m4/libtool.m4 (_LT_LINKER_SHLIBS): On AIX, GNU g++ generates
>> _GLOBAL__ symbols as, amongst others, landing pads for C++ exceptions.
>> These symbols must not be exported from shared libraries, or exception
>> handling may break for applications with runtime linking enabled.
>
> Hi, Michael
>
> Thanks for the analysis.
>
> The problem with EH for GDB involves static linking, not runtime
> linking.
That seems to be my understanding as well.

> And there seems to be different behavior for GCC 4.8 and GCC
> 4.9.
Could it perhaps be an IPA issue -- we know IPA can change symbol 
scope/linkage  in some cases.  Maybe it's mucking things up.  Is there 
more detail in a thread elsewhere on this issue?

>
> The patch seems correct for the runtime linking case, but I don't
> believe that it solves all of the EH issues -- at least more
> explanation is needed.
The current libtool.m4 in GCC looks out of date relative to what's in 
Michael's patch.  So we'd either need a patch specific to the version in 
GCC right now or we'd need to update libtool.m4 then apply Michael's patch.

>
> I think that the problem for static linking needs to be addressed by collect2.
Could be -- I just don't have enough background to know either way.

jeff

Re: [PATCH] Real fix for AIX exception handling

[David Edelsohn]

On Wed, Mar 29, 2017 at 3:50 PM, Jeff Law <law@redhat.com> wrote:
> On 03/27/2017 09:41 AM, David Edelsohn wrote:
>>>
>>> As far as I have discovered, the real problem with AIX exception handling
>>> is
>>> that the exception landing pads are symbols that must not (but still are)
>>> exported from shared libraries - even libstdc++.
>>>
>>> I'm wondering if attached libtool(!)-patch would fix even that GDB
>>> problem
>>> once applied to each(!) shared library creation procedure.
>>>
>>> However, each workaround still applies as long as there's a single shared
>>> library involved that has not stopped exporting these symbols yet.
>>>
>>> Thoughts?
>>>
>>> Maybe gcc's collect2 should apply this additional symbol filter itself
>>> calling (AIX) ld, rather than leaving this to each build system?
>>>
>>> * m4/libtool.m4 (_LT_LINKER_SHLIBS): On AIX, GNU g++ generates
>>> _GLOBAL__ symbols as, amongst others, landing pads for C++ exceptions.
>>> These symbols must not be exported from shared libraries, or exception
>>> handling may break for applications with runtime linking enabled.
>>
>>
>> Hi, Michael
>>
>> Thanks for the analysis.
>>
>> The problem with EH for GDB involves static linking, not runtime
>> linking.
>
> That seems to be my understanding as well.
>
>> And there seems to be different behavior for GCC 4.8 and GCC
>> 4.9.
>
> Could it perhaps be an IPA issue -- we know IPA can change symbol
> scope/linkage  in some cases.  Maybe it's mucking things up.  Is there more
> detail in a thread elsewhere on this issue?

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.

Thanks, David

Re: [PATCH] Real fix for AIX exception handling

[Jeff Law]

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?

[ Again, just trying to start from the basics as it's been a horribly 
long time since I've pondered such stuff. ]

Jeff

Re: [PATCH] Real fix for AIX exception handling

[David Edelsohn]

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.

One can understand how this ended up broken, but I am trying to
understand how it worked correctly in GCC 4.8.  And, as we all know,
GDB functionality on AIX is limited.

Thanks, David

Re: [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

Re: [PATCH] Real fix for AIX exception handling

[David Edelsohn]

On Wed, Mar 29, 2017 at 5:20 PM, Jeff Law <law@redhat.com> wrote:
> 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.

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

Re: [PATCH] Real fix for AIX exception handling

[Jeff Law]

On 03/29/2017 03:22 PM, David Edelsohn wrote:
> On Wed, Mar 29, 2017 at 5:20 PM, Jeff Law <law@redhat.com> wrote:
>> 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.
>
> Yes, collect2 essentially creates a constructor that it schedules at a
> high priority to record the frames that it found during the scan.
OK.  So I'd first verify there is a constructor for the libstdc++ 
library as a whole via nm/objdump.  Then I'd verify that library 
constructor shows up in the ctor list for the main executable -- not 
sure the best way to do that.

jeff

Re: [PATCH] Real fix for AIX exception handling

[Michael Haubenwallner]

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

On 03/29/2017 10:21 PM, David Edelsohn wrote:
> On Wed, Mar 29, 2017 at 3:50 PM, Jeff Law <law@redhat.com> wrote:
>> On 03/27/2017 09:41 AM, David Edelsohn wrote:
>>>>
>>>> As far as I have discovered, the real problem with AIX exception handling
>>>> is
>>>> that the exception landing pads are symbols that must not (but still are)
>>>> exported from shared libraries - even libstdc++.
>>>>
>>>> I'm wondering if attached libtool(!)-patch would fix even that GDB
>>>> problem
>>>> once applied to each(!) shared library creation procedure.
>>>>
>>>> However, each workaround still applies as long as there's a single shared
>>>> library involved that has not stopped exporting these symbols yet.
>>>>
>>>> Thoughts?
>>>>
>>>> Maybe gcc's collect2 should apply this additional symbol filter itself
>>>> calling (AIX) ld, rather than leaving this to each build system?
>>>>
>>>> * m4/libtool.m4 (_LT_LINKER_SHLIBS): On AIX, GNU g++ generates
>>>> _GLOBAL__ symbols as, amongst others, landing pads for C++ exceptions.
>>>> These symbols must not be exported from shared libraries, or exception
>>>> handling may break for applications with runtime linking enabled.
>>>
>>>
>>> Hi, Michael
>>>
>>> Thanks for the analysis.
>>>
>>> The problem with EH for GDB involves static linking, not runtime
>>> linking.
>>
>> That seems to be my understanding as well.
>>
>>> And there seems to be different behavior for GCC 4.8 and GCC
>>> 4.9.
>>
>> Could it perhaps be an IPA issue -- we know IPA can change symbol
>> scope/linkage  in some cases.  Maybe it's mucking things up.  Is there more
>> detail in a thread elsewhere on this issue?
> 
> 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.

When statically linked, shouldn't collect2 add libstdc++'s EH frames to
the main executable's registration table again?
Or is libstdc++'s constructor called instead?

> 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.

Wild guess:
When (and how) did you disable runtime linking (-G) for libstdc++?
Maybe there's a side effect related to -bsymbolic when statically linking
a shared object.

> Note that AIX does not install a separate libstdc++ static archive and
> instead statically links against the shared object.

Note that libtool's --with-aix-soname=svr4 would behave different here...

> 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.

Next wild guess: When libstdc++'s EH frames are registered calling
libstdc++'s constructor even when statically linked rather than being
added to main executable's table, both registered EH tables may overlap
each other - where attached patch might help...

Thanks!
/haubi/

[-- Attachment #2: 0001-libgcc-On-AIX-increase-chances-to-find-landing-pads-.patch --]
[-- Type: text/x-patch, Size: 2505 bytes --]

From 7ed6bd3bba4e3161e761d4cdb8393ec9bcf98038 Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner <michael.haubenwallner@ssi-schaefer.com>
Date: Mon, 8 Feb 2016 12:37:56 +0100
Subject: [PATCH] libgcc: On AIX, increase chances to find landing pads for
 exceptions.

* unwind-dw2-fde.c (_Unwind_Find_FDE): Stop assuming registered
object's address ranges to not overlap.
---
 libgcc/ChangeLog        |  6 ++++++
 libgcc/unwind-dw2-fde.c | 20 ++++++++++++++++++++
 2 files changed, 26 insertions(+)

diff --git a/libgcc/ChangeLog b/libgcc/ChangeLog
index 4bae69f..ffa6f60 100644
--- a/libgcc/ChangeLog
+++ b/libgcc/ChangeLog
@@ -1,3 +1,9 @@
+2016-02-08  Michael Haubenwallner  <michael.haubenwallner@ssi-schaefer.com>
+
+	On AIX, increase chances to find landing pads for exceptions.
+	* unwind-dw2-fde.c (_Unwind_Find_FDE): Stop assuming registered
+	object's address ranges to not overlap.
+
 2017-03-10  John Marino  <gnugcc@marino.st>
 
 	* config/aarch64/freebsd-unwind.h: New file.
diff --git a/libgcc/unwind-dw2-fde.c b/libgcc/unwind-dw2-fde.c
index 02b588d..9cf2d65 100644
--- a/libgcc/unwind-dw2-fde.c
+++ b/libgcc/unwind-dw2-fde.c
@@ -1054,7 +1054,27 @@ _Unwind_Find_FDE (void *pc, struct dwarf_eh_bases *bases)
 	f = search_object (ob, pc);
 	if (f)
 	  goto fini;
+	/* In an ideal world, even on AIX, we could break here because
+	   objects would not overlap.  But the larger an application is,
+	   the more likely an "overlap" may happen (on AIX) because of:
+	   - Shared libraries do export the FDE symbols ("_GLOBAL__F*"),
+	     which is a bug in their build system, out of gcc's control.
+	   - Other shared libraries, or the main executable, may contain
+	     identical or similar object files - which is suboptimal, but
+	     may be intentional.  However, exporting their FDE symbols,
+	     which may have identical symbol names as in their original
+	     shared libraries, again is a bug in their build system, but
+	     still out of gcc's control.
+	   - When enabled, run time linking may redirect adresses of
+	     duplicate FDE symbols from their original shared library's
+	     address range into another shared library's or the main
+	     executable's address range, when they share the same FDE
+	     symbol name.
+	   This results in address ranges being registered by different
+	   object to potentially overlap.  */
+#if !(defined(_POWER) && defined(_AIX))
 	break;
+#endif
       }
 
   /* Classify and search the objects we've not yet processed.  */
-- 
2.10.2

Re: [PATCH] Real fix for AIX exception handling

[David Edelsohn]

On Thu, Mar 30, 2017 at 4:11 AM, Michael Haubenwallner
<michael.haubenwallner@ssi-schaefer.com> wrote:
> On 03/29/2017 10:21 PM, David Edelsohn wrote:
>> On Wed, Mar 29, 2017 at 3:50 PM, Jeff Law <law@redhat.com> wrote:
>>> On 03/27/2017 09:41 AM, David Edelsohn wrote:
>>>>>
>>>>> As far as I have discovered, the real problem with AIX exception handling
>>>>> is
>>>>> that the exception landing pads are symbols that must not (but still are)
>>>>> exported from shared libraries - even libstdc++.
>>>>>
>>>>> I'm wondering if attached libtool(!)-patch would fix even that GDB
>>>>> problem
>>>>> once applied to each(!) shared library creation procedure.
>>>>>
>>>>> However, each workaround still applies as long as there's a single shared
>>>>> library involved that has not stopped exporting these symbols yet.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Maybe gcc's collect2 should apply this additional symbol filter itself
>>>>> calling (AIX) ld, rather than leaving this to each build system?
>>>>>
>>>>> * m4/libtool.m4 (_LT_LINKER_SHLIBS): On AIX, GNU g++ generates
>>>>> _GLOBAL__ symbols as, amongst others, landing pads for C++ exceptions.
>>>>> These symbols must not be exported from shared libraries, or exception
>>>>> handling may break for applications with runtime linking enabled.
>>>>
>>>>
>>>> Hi, Michael
>>>>
>>>> Thanks for the analysis.
>>>>
>>>> The problem with EH for GDB involves static linking, not runtime
>>>> linking.
>>>
>>> That seems to be my understanding as well.
>>>
>>>> And there seems to be different behavior for GCC 4.8 and GCC
>>>> 4.9.
>>>
>>> Could it perhaps be an IPA issue -- we know IPA can change symbol
>>> scope/linkage  in some cases.  Maybe it's mucking things up.  Is there more
>>> detail in a thread elsewhere on this issue?
>>
>> 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.
>
> When statically linked, shouldn't collect2 add libstdc++'s EH frames to
> the main executable's registration table again?
> Or is libstdc++'s constructor called instead?
>
>> 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.
>
> Wild guess:
> When (and how) did you disable runtime linking (-G) for libstdc++?
> Maybe there's a side effect related to -bsymbolic when statically linking
> a shared object.

Yes, two hypotheses are:

1) The removal of -G AIX linker option that allowed runtime overriding
of libstdc++ symbols and somehow allowed merging of symbols when
linking statically.

2) Change in order of initialization from AIX default breadth first to
force SVR4-like depth first.

>
>> Note that AIX does not install a separate libstdc++ static archive and
>> instead statically links against the shared object.
>
> Note that libtool's --with-aix-soname=svr4 would behave different here...
>
>> 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.
>
> Next wild guess: When libstdc++'s EH frames are registered calling
> libstdc++'s constructor even when statically linked rather than being
> added to main executable's table, both registered EH tables may overlap
> each other - where attached patch might help...

Thanks, David

Re: [PATCH] Real fix for AIX exception handling

[Jeff Law]

On 03/30/2017 02:11 AM, Michael Haubenwallner wrote:
>
> When statically linked, shouldn't collect2 add libstdc++'s EH frames to
> the main executable's registration table again?
> Or is libstdc++'s constructor called instead?
I would think the latter -- because libstdc++ is already linked into a 
DSO.  If libstdc++ was an archive library, then it would be the former.

Jeff