RE: AIX 5.1 dlopen shared library exception handling problem

RE: AIX 5.1 dlopen shared library exception handling problem

[Coulter, Scott]

Does it make sense that this behavior would show up only when loading the library
with dlopen() and not when linking to the library directly?
 
I've already built a test version of our app with only a minimal number of our classes,
trying to see whether this is another instance of the known problem with duplicate symbols.
I haven't yet identified any duplicates.  I'm now working on writing an even smaller
test without any of our app's framework in place.
 
--sdc
scott.coulter@retek.com
 

	-----Original Message----- 
	From: David Edelsohn [mailto:dje@watson.ibm.com] 
	Sent: Thu 2/5/2004 12:25 PM 
	To: Joe Buck 
	Cc: Coulter, Scott; gcc@gcc.gnu.org 
	Subject: Re: AIX 5.1 dlopen shared library exception handling problem 
	
	

	>>>>> Joe Buck writes:
	
	>> Please see existing Bugzilla bug report 13391.
	
	Joe> It doesn't look the same.  You say in that bug report that the issue is
	Joe> that collect2 becomes confused by duplicate symbols.  But in this case,
	Joe> dlopen() is being used to open the shared library, and collect2 is not
	Joe> involved.
	
	        Collect2 generated the shared library.
	
	        According to an analysis in a related bug report, it appears that
	GCC's assumption about the sorting of FDEs is getting confused by the
	address ranges of shared libraries used by AIX.  The duplicate symbols
	cause FDEs for the same symbol to appear in multiple shared libraries.
	
	David
	

Re: AIX 5.1 dlopen shared library exception handling problem

[David Edelsohn]

>>>>> Coulter, Scott writes:

Scott> Does it make sense that this behavior would show up only when loading the library
Scott> with dlopen() and not when linking to the library directly?
 
	The problem is due to the number of libraries and where they are
loaded in memory.  Dynamic linking at startup versus dlopen() changes
that.

David

RE: AIX 5.1 dlopen shared library exception handling problem

[Coulter, Scott]

Many, many thanks to Joerg, and the others who responded to my question.
The patch suggested in PR13878 does indeed seem to fix my problem, both in
my small test case, and in our full application.
 
I hope we can get either this fix, or something related, into future releases of
gcc for the AIX platform.  I'm no compiler guru, but if there's any way I can help
track down the root causes of this issue, please let me know...
 
Scott Coulter
scott.coulter@retek.com
 

	-----Original Message----- 
	From: Joerg.Richter@pdv-FS.de [mailto:Joerg.Richter@pdv-FS.de] 
	Sent: Fri 2/6/2004 3:36 AM 
	To: dje@watson.ibm.com 
	Cc: Joe.Buck@synopsys.com; Coulter, Scott; gcc@gcc.gnu.org 
	Subject: Re: AIX 5.1 dlopen shared library exception handling problem 
	
	

	>       According to an analysis in a related bug report, it appears that
	> GCC's assumption about the sorting of FDEs is getting confused by the
	> address ranges of shared libraries used by AIX.  The duplicate symbols
	> cause FDEs for the same symbol to appear in multiple shared libraries.
	
	Please note that this are two different issues. Duplicate symbols in user
	code can cause uncaught exceptions. But only when they are both the first
	definition in both translation units. I think GCC uses their name to name
	the unwind table or something related. So the unwind information for one
	translation unit is lost.
	
	I tried to describe the second cause for uncaught exceptions in bug report
	13878. There are no duplicate symbols (in user code) involved. All unwind
	information is still present. But due to the fact that some fdes are shared
	between shared libraries GCC runtime doesn't find the right fde.
	
	The patch in PR13878 fixes the second issue. Not the first.
	
	
	   Joerg
	

Re: AIX 5.1 dlopen shared library exception handling problem

[Joerg.Richter]

>	According to an analysis in a related bug report, it appears that
> GCC's assumption about the sorting of FDEs is getting confused by the
> address ranges of shared libraries used by AIX.  The duplicate symbols
> cause FDEs for the same symbol to appear in multiple shared libraries.

Please note that this are two different issues. Duplicate symbols in user
code can cause uncaught exceptions. But only when they are both the first
definition in both translation units. I think GCC uses their name to name
the unwind table or something related. So the unwind information for one
translation unit is lost.

I tried to describe the second cause for uncaught exceptions in bug report
13878. There are no duplicate symbols (in user code) involved. All unwind
information is still present. But due to the fact that some fdes are shared
between shared libraries GCC runtime doesn't find the right fde. 

The patch in PR13878 fixes the second issue. Not the first.


   Joerg

Re: AIX 5.1 dlopen shared library exception handling problem

[Joe Buck]

On Thu, Feb 05, 2004 at 12:25:12PM -0500, David Edelsohn wrote:
> >>>>> Joe Buck writes:
> 
> >> Please see existing Bugzilla bug report 13391.
> 
> Joe> It doesn't look the same.  You say in that bug report that the issue is
> Joe> that collect2 becomes confused by duplicate symbols.  But in this case,
> Joe> dlopen() is being used to open the shared library, and collect2 is not
> Joe> involved.
> 
> 	Collect2 generated the shared library.

Of course; next time I'll drink my coffee before sending mail.

Re: AIX 5.1 dlopen shared library exception handling problem

[David Edelsohn]

>>>>> Joe Buck writes:

>> Please see existing Bugzilla bug report 13391.

Joe> It doesn't look the same.  You say in that bug report that the issue is
Joe> that collect2 becomes confused by duplicate symbols.  But in this case,
Joe> dlopen() is being used to open the shared library, and collect2 is not
Joe> involved.

	Collect2 generated the shared library.

	According to an analysis in a related bug report, it appears that
GCC's assumption about the sorting of FDEs is getting confused by the
address ranges of shared libraries used by AIX.  The duplicate symbols
cause FDEs for the same symbol to appear in multiple shared libraries.

David

Re: AIX 5.1 dlopen shared library exception handling problem

[Joe Buck]

On Thu, Feb 05, 2004 at 10:16:19AM -0500, David Edelsohn wrote:
> 	Please see existing Bugzilla bug report 13391.

It doesn't look the same.  You say in that bug report that the issue is
that collect2 becomes confused by duplicate symbols.  But in this case,
dlopen() is being used to open the shared library, and collect2 is not
involved.

Re: AIX 5.1 dlopen shared library exception handling problem

[David Edelsohn]

	Please see existing Bugzilla bug report 13391.

David

AIX 5.1 dlopen shared library exception handling problem

[Coulter, Scott]

On the AIX 5.1 platform, using gcc 3.3.2, and run-time loading a shared library
via dlopen( ), I find that exceptions which are thrown by the shared library and should
be caught by the executable are not, in fact, caught.  If I link in the shared library at 
build-time, but leave the rest of the code unchanged, the relevant catch block
functions as expected.
 
Also, the identical code base functions correctly on Solaris and HPUX with similar gcc builds.
 
Sorry if this is vague; I'm still working to isolate a test-case from our code that I can send along.
 
/home/coultes >gcc -v
Reading specs from /u03/rpas/scott/aix51.gcc-3.3.2/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.3.2/specs
Configured with: ../gcc-3.3.2/configure --prefix=/u03/rpas/scott/aix51.gcc-3.3.2 --enable-shared --enable-threads=posix --disable-nls --enable-languages=c,c++
Thread model: aix
gcc version 3.3.2

Thanks for any help you can suggest,
Scott Coulter
scott.coulter@retek.com