* versioning of _Unwind_*() symbols @ 2004-04-19 18:48 David Mosberger 2004-04-20 23:21 ` Jim Wilson 0 siblings, 1 reply; 69+ messages in thread From: David Mosberger @ 2004-04-19 18:48 UTC (permalink / raw) To: gcc In reference to this bug report: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14925 Why are the _Unwind_*() symbols being versioned? Do the GCC developers care about C++ ABI compatibility? --david ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-19 18:48 versioning of _Unwind_*() symbols David Mosberger @ 2004-04-20 23:21 ` Jim Wilson 2004-04-20 23:28 ` David Mosberger 2004-04-20 23:41 ` H. J. Lu 0 siblings, 2 replies; 69+ messages in thread From: Jim Wilson @ 2004-04-20 23:21 UTC (permalink / raw) To: davidm; +Cc: gcc David Mosberger wrote: > Why are the _Unwind_*() symbols being versioned? > Do the GCC developers care about C++ ABI compatibility? Yes, we care about C++ ABI compatibility. I am not a library expert, so I don't know all of the ramifications of versioning symbols, but my understanding is that it is standard practice to version symbols exported by standard shared libraries. If we ever find a mistake, and need to fix a bug or change an interface, then the versioning helps us ensure that programs and/or shared libraries linked against the old version of the function still get the old version of the function. The situation here is a bit special. We added routines to libgcc which are required by C++ ABI. Then you contributed patches to remove them from libgcc and replace them with equivalent versions from libunwind. Unfortunately, this means anything linked against an old version of libgcc can no longer find the old routines they need. This implies that removing the routines from libgcc was wrong. Note that glibc does the same thing as libgcc, it versions all exported standard functions put in libc.so. Suppose someone writes their own memcpy function which is better than the one in libc.so, and then relinks libc.so to remove the glibc memcpy function. What happens? Programs linked against the old libc.so no longer work, because they can't find the glibc versioned mempcy function anymore. It seems to make sense that relinking glibc to remove functions is wrong, and by extension, it is also wrong for libgcc. So it seems that libgcc wasn't doing anything wrong, rather our attempt to remove functions from libgcc to save space was wrong. We can remove them from libgcc.a, but not from libgcc_s.so. This seems to match with Mark's suggestion of putting the functions back in libgcc_s.so to maintain backwards compatibility. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-20 23:21 ` Jim Wilson @ 2004-04-20 23:28 ` David Mosberger 2004-04-21 0:25 ` Jim Wilson 2004-04-20 23:41 ` H. J. Lu 1 sibling, 1 reply; 69+ messages in thread From: David Mosberger @ 2004-04-20 23:28 UTC (permalink / raw) To: Jim Wilson; +Cc: davidm, gcc >>>>> On Tue, 20 Apr 2004 15:40:25 -0700, Jim Wilson <wilson@specifixinc.com> said: Jim> So it seems that libgcc wasn't doing anything wrong, rather our Jim> attempt to remove functions from libgcc to save space was Jim> wrong. We can remove them from libgcc.a, but not from Jim> libgcc_s.so. When built against libunwind, libgcc_s.so should have a dependency on libunwind.so and hence no symbols got lost. However, there is still a versioning issue. AFAIK, the C++ ABI doesn't specify (allow?) versioned symbols. Certainly Intel's _Unwind_*() routines also are not versioned. --david ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-20 23:28 ` David Mosberger @ 2004-04-21 0:25 ` Jim Wilson 0 siblings, 0 replies; 69+ messages in thread From: Jim Wilson @ 2004-04-21 0:25 UTC (permalink / raw) To: David Mosberger; +Cc: gcc On Tue, 2004-04-20 at 16:06, David Mosberger wrote: > When built against libunwind, libgcc_s.so should have a dependency > on libunwind.so and hence no symbols got lost. The old versions of the functions were lost. > However, there is still a versioning issue. AFAIK, the C++ ABI > doesn't specify (allow?) versioned symbols. Certainly Intel's > _Unwind_*() routines also are not versioned. You seem to have glossed over the glibc comments here. glibc versions symbols. If glibc can and does version symbols, then it seems to me that libgcc also can and should version symbols. Do the ANSI or POSIX standards say anything about symbol versioning? I doubt that they do. Hence whether the C++ ABI says anything about versioning is irrelevant. Versioning is a system issue. In order to provide compatibility from one gcc/glibc version to the next, we version symbols. I see nothing wrong with this. As I mentioned before, the only problem here seems to be that we dropped symbols from libgcc to save space. But this loses compatibility, which is a bigger problem than saving space, so we should put the symbols back. This won't break libunwind, as libunwind is linked in before libgcc, so we still get the libunwind versions of the routines if libunwind has them. If a system vendor chooses to ship libunwind as a required part of a linux distro, then and only then, can we drop the symbols from libgcc, as then we no longer need them for compatibility with the system version of libgcc_s.so. This assumes we don't need compatibility with previous linux distro releases, and/or there is a separate libgcc_s.so for compatibility with old linux distro releases. Note that one way to get libunwind accepted as a standard part of a linux distro is to add it to a package that is already a standard part of a linux distro. This will be a lot of FSF paperwork though. libffi is technically not part of gcc, and some people have been trying to fix this for about 9 months with no apparent success so far. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-20 23:21 ` Jim Wilson 2004-04-20 23:28 ` David Mosberger @ 2004-04-20 23:41 ` H. J. Lu 2004-04-20 23:51 ` David Mosberger 1 sibling, 1 reply; 69+ messages in thread From: H. J. Lu @ 2004-04-20 23:41 UTC (permalink / raw) To: Jim Wilson; +Cc: davidm, gcc On Tue, Apr 20, 2004 at 03:40:25PM -0700, Jim Wilson wrote: > > This seems to match with Mark's suggestion of putting the functions back > in libgcc_s.so to maintain backwards compatibility. It is a very tricky thing to do with the current Linux dynamic linker. Those removed functions should be restored. The question is where they come from. We can't use the old definiton since we want to use the ones in libunwind. In glibc, we do foo () { h = dlopen (libgcc) fn = dlsym (h, "foo"); (*fn) ... } so that we can define foo in glibc as a wrapper for foo in libgcc. Maybe we can do the same for libgcc. H.J. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-20 23:41 ` H. J. Lu @ 2004-04-20 23:51 ` David Mosberger 2004-04-20 23:52 ` H. J. Lu 0 siblings, 1 reply; 69+ messages in thread From: David Mosberger @ 2004-04-20 23:51 UTC (permalink / raw) To: H. J. Lu; +Cc: Jim Wilson, davidm, gcc >>>>> On Tue, 20 Apr 2004 16:28:02 -0700, "H. J. Lu" <hjl@lucon.org> said: HJ> On Tue, Apr 20, 2004 at 03:40:25PM -0700, Jim Wilson wrote: >> This seems to match with Mark's suggestion of putting the functions back >> in libgcc_s.so to maintain backwards compatibility. HJ> It is a very tricky thing to do with the current Linux dynamic linker. HJ> Those removed functions should be restored. The question is where HJ> they come from. We can't use the old definiton since we want to use HJ> the ones in libunwind. In glibc, we do HJ> foo () HJ> { HJ> h = dlopen (libgcc) HJ> fn = dlsym (h, "foo"); HJ> (*fn) ... HJ> } HJ> so that we can define foo in glibc as a wrapper for foo in libgcc. HJ> Maybe we can do the same for libgcc. I didn't think libgcc could/should rely on dlopen()? But in any case, for libgcc_s.so, it's sufficient to have a dependency on libunwind.so. The dynamic linker will then take care of loading libunwind.so before loading libgcc_s.so. --david ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-20 23:51 ` David Mosberger @ 2004-04-20 23:52 ` H. J. Lu 2004-04-21 0:19 ` David Mosberger 0 siblings, 1 reply; 69+ messages in thread From: H. J. Lu @ 2004-04-20 23:52 UTC (permalink / raw) To: davidm; +Cc: Jim Wilson, gcc On Tue, Apr 20, 2004 at 04:35:46PM -0700, David Mosberger wrote: > >>>>> On Tue, 20 Apr 2004 16:28:02 -0700, "H. J. Lu" <hjl@lucon.org> said: > > HJ> On Tue, Apr 20, 2004 at 03:40:25PM -0700, Jim Wilson wrote: > > >> This seems to match with Mark's suggestion of putting the functions back > >> in libgcc_s.so to maintain backwards compatibility. > > HJ> It is a very tricky thing to do with the current Linux dynamic linker. > HJ> Those removed functions should be restored. The question is where > HJ> they come from. We can't use the old definiton since we want to use > HJ> the ones in libunwind. In glibc, we do > > HJ> foo () > HJ> { > HJ> h = dlopen (libgcc) > HJ> fn = dlsym (h, "foo"); > HJ> (*fn) ... > HJ> } > > HJ> so that we can define foo in glibc as a wrapper for foo in libgcc. > HJ> Maybe we can do the same for libgcc. > > I didn't think libgcc could/should rely on dlopen()? > > But in any case, for libgcc_s.so, it's sufficient to have a dependency > on libunwind.so. The dynamic linker will then take care of loading > libunwind.so before loading libgcc_s.so. > The current Linux dynamic linker may or may not allow you to move a versioned definition from one DSO to another: http://sources.redhat.com/ml/libc-alpha/2003-09/msg00154.html H.J. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-20 23:52 ` H. J. Lu @ 2004-04-21 0:19 ` David Mosberger 2004-04-21 0:44 ` Jim Wilson 0 siblings, 1 reply; 69+ messages in thread From: David Mosberger @ 2004-04-21 0:19 UTC (permalink / raw) To: H. J. Lu; +Cc: davidm, Jim Wilson, gcc >>>>> On Tue, 20 Apr 2004 16:41:52 -0700, "H. J. Lu" <hjl@lucon.org> said: >> But in any case, for libgcc_s.so, it's sufficient to have a dependency >> on libunwind.so. The dynamic linker will then take care of loading >> libunwind.so before loading libgcc_s.so. HJ> The current Linux dynamic linker may or may not allow you to move a HJ> versioned definition from one DSO to another: HJ> http://sources.redhat.com/ml/libc-alpha/2003-09/msg00154.html But if the _Unwind_*() symbols weren't versioned in the first place, there would be no problem at all. I do understand that versioning may make sense in _general_, but we're talking about the C++ _ABI_ here. If it's not _binary_ compatible, then it's simply not compatible. No? --david ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-21 0:19 ` David Mosberger @ 2004-04-21 0:44 ` Jim Wilson 2004-04-21 1:24 ` Daniel Jacobowitz ` (2 more replies) 0 siblings, 3 replies; 69+ messages in thread From: Jim Wilson @ 2004-04-21 0:44 UTC (permalink / raw) To: David Mosberger; +Cc: H. J. Lu, gcc On Tue, 2004-04-20 at 16:51, David Mosberger wrote: > I do understand that versioning may make sense in _general_, but we're > talking about the C++ _ABI_ here. If it's not _binary_ compatible, > then it's simply not compatible. No? Why does glibc bother to versions symbols when they are all binary compatible? The answer is that while the intent is for everything to be binary compatible, we occasionally find bugs, and the symbol versioning allows us to fix bugs without losing backwards compatibility. Also, standards occsionally change, and this presumably allows for some compatibility across standards. We have incidentally found a number of bugs in the C++ ABI simply by comparing the HP, Intel, and GNU C++ compilers against each other. Some of these problems have required compiler changes. Some of them have required C++ ABI changes. I think all of these compilers are known to have at least one bug that prevents them from being fully compliant, and some (e.g. the HP one) may never be fixed, because of backwards compatibility problems. There is also the issue that we have extensions to the C++ ABI, as we ran into problems making C++ exceptions work with thread cancellation. What is wrong with putting the symbols back in libgcc_s.so? If you link with libunwind before libgcc, programs will use the libunwind versions won't they? Maybe the issue is that system libraries that were linked again libgcc will still use the libgcc version? That gets us back to the issue I mentioned before, which is that this is really a system packaging issue, not a libgcc vesioning issue. If a linux distro ships with libunwind as a standard package, then everything is OK. If libunwind is an add on package, then we can't replace the versioned libgcc functions, we can only replace the internal unversioned functions. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-21 0:44 ` Jim Wilson @ 2004-04-21 1:24 ` Daniel Jacobowitz 2004-04-21 1:46 ` Jim Wilson 2004-04-21 1:39 ` H. J. Lu 2004-04-21 6:09 ` PATCH: Put libunwind.a in libgcc_s.so: " H. J. Lu 2 siblings, 1 reply; 69+ messages in thread From: Daniel Jacobowitz @ 2004-04-21 1:24 UTC (permalink / raw) To: Jim Wilson; +Cc: David Mosberger, H. J. Lu, gcc On Tue, Apr 20, 2004 at 05:26:02PM -0700, Jim Wilson wrote: > Why does glibc bother to versions symbols when they are all binary > compatible? > > The answer is that while the intent is for everything to be binary > compatible, we occasionally find bugs, and the symbol versioning allows > us to fix bugs without losing backwards compatibility. Also, standards > occsionally change, and this presumably allows for some compatibility > across standards. The latter issue is not a problem here. Presumably, the former isn't either - a standard has to take the pre-symbol-versioning approach of simply renaming functions when their signatures or behavior change significantly. > What is wrong with putting the symbols back in libgcc_s.so? If you link > with libunwind before libgcc, programs will use the libunwind versions > won't they? Dubious - behavior with both versioned and unversioned definitions present can be pretty random. > Maybe the issue is that system libraries that were linked again libgcc > will still use the libgcc version? That gets us back to the issue I > mentioned before, which is that this is really a system packaging issue, > not a libgcc vesioning issue. If a linux distro ships with libunwind as > a standard package, then everything is OK. If libunwind is an add on > package, then we can't replace the versioned libgcc functions, we can > only replace the internal unversioned functions. The issue that I see is that code linked against libgcc's implementation of the C++ ABI can not be used with anyone else's implementation of the C++ ABI. If that is not binary incompatibility, then what do you think is? Putting explicit "GCC_3.x" identifiers on the symbol reference means that the binary demands GCC's implementation and demands that it come from libgcc_s.so.1. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-21 1:24 ` Daniel Jacobowitz @ 2004-04-21 1:46 ` Jim Wilson 2004-04-21 2:09 ` David Mosberger 2004-04-21 2:21 ` Gabriel Dos Reis 0 siblings, 2 replies; 69+ messages in thread From: Jim Wilson @ 2004-04-21 1:46 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: David Mosberger, H. J. Lu, gcc On Tue, 2004-04-20 at 17:45, Daniel Jacobowitz wrote: > The issue that I see is that code linked against libgcc's > implementation of the C++ ABI can not be used with anyone else's > implementation of the C++ ABI. How is this any different than what glibc does? Code linked against glibc's implementation of the ISO C and POSIX library standards can not be used with anyone else's implementation of the ISO C and POSIX library standards, because glibc versions symbols. If you didn't want to use the routines from glibc, you shouldn't have linked them in. I fail to see any difference between what glibc does and what libgcc does. Perhaps I am wrong, but no one has yet pointed out any flaw in my argument. Actually, come to think of it, glibc tends to use weak aliases a lot. Does that help solve the problem if libgcc starts using weak aliases? I haven't tried thinking this through. Or perhaps there is some other difference between how glibc and libgcc are structured that lets versioned symbols work for glibc? -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-21 1:46 ` Jim Wilson @ 2004-04-21 2:09 ` David Mosberger 2004-04-21 4:44 ` Daniel Jacobowitz 2004-04-21 2:21 ` Gabriel Dos Reis 1 sibling, 1 reply; 69+ messages in thread From: David Mosberger @ 2004-04-21 2:09 UTC (permalink / raw) To: Jim Wilson; +Cc: Daniel Jacobowitz, David Mosberger, H. J. Lu, gcc >>>>> On 20 Apr 2004 18:24:42 -0700, Jim Wilson <wilson@specifixinc.com> said: Jim> How is this any different than what glibc does? Code linked against Jim> glibc's implementation of the ISO C and POSIX library standards can not Jim> be used with anyone else's implementation of the ISO C and POSIX library Jim> standards, because glibc versions symbols. If you didn't want to use Jim> the routines from glibc, you shouldn't have linked them in. I believe ISO C and POSIX only define APIs, not ABIs. --david ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-21 2:09 ` David Mosberger @ 2004-04-21 4:44 ` Daniel Jacobowitz 0 siblings, 0 replies; 69+ messages in thread From: Daniel Jacobowitz @ 2004-04-21 4:44 UTC (permalink / raw) To: davidm; +Cc: Jim Wilson, H. J. Lu, gcc On Tue, Apr 20, 2004 at 06:38:46PM -0700, David Mosberger wrote: > >>>>> On 20 Apr 2004 18:24:42 -0700, Jim Wilson <wilson@specifixinc.com> said: > > Jim> How is this any different than what glibc does? Code linked against > Jim> glibc's implementation of the ISO C and POSIX library standards can not > Jim> be used with anyone else's implementation of the ISO C and POSIX library > Jim> standards, because glibc versions symbols. If you didn't want to use > Jim> the routines from glibc, you shouldn't have linked them in. > > I believe ISO C and POSIX only define APIs, not ABIs. Thank you, David. That was precisely my point. The LSB, for instance, defines an ABI. I believe it _does_ account for symbol versioning, and there are non-glibc compliant implementations. The C++ ABI doesn't account for symbol versioning - reasonable, since it supports non-ELF targets - but the question at hand is, does that cut out the possibility of versioning the symbols? I was staying out of this discussion because I don't have a clear answer to that question, but I do think that the answer is: yes, it does eliminate the possibility. How to implement this properly is unclear. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-21 1:46 ` Jim Wilson 2004-04-21 2:09 ` David Mosberger @ 2004-04-21 2:21 ` Gabriel Dos Reis 2004-04-21 18:26 ` Mark Mitchell 1 sibling, 1 reply; 69+ messages in thread From: Gabriel Dos Reis @ 2004-04-21 2:21 UTC (permalink / raw) To: Jim Wilson; +Cc: Daniel Jacobowitz, David Mosberger, H. J. Lu, gcc Jim Wilson <wilson@specifixinc.com> writes: | I fail to see any difference between what glibc does and what libgcc | does. I believe the main difference is that libgcc is tightly coupled with the compiler and glibc is more much decoupled. libgcc is fixed by the compiler. That makes its versioning more debatable. I'm not sure we can reason on what glibc does and transpose the outcome to libgcc. -- Gaby ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-21 2:21 ` Gabriel Dos Reis @ 2004-04-21 18:26 ` Mark Mitchell 2004-04-21 19:17 ` H. J. Lu 0 siblings, 1 reply; 69+ messages in thread From: Mark Mitchell @ 2004-04-21 18:26 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Jim Wilson, Daniel Jacobowitz, David Mosberger, H. J. Lu, gcc Gabriel Dos Reis wrote: >Jim Wilson <wilson@specifixinc.com> writes: > >| I fail to see any difference between what glibc does and what libgcc >| does. > >I believe the main difference is that libgcc is tightly coupled with >the compiler and glibc is more much decoupled. libgcc is fixed by the >compiler. That makes its versioning more debatable. >I'm not sure we can reason on what glibc does and transpose the >outcome to libgcc. > > I agree with David Mosberger. I think that it was a mistake to version the symbols. The C++ ABI is designed so that compilers can interoperate; clearly, if GCC-compiled objects contain references to versioned symbols, then other compilers cannot easily provide matching runtime libraries, and vice versa. If these functions need to change in some way that would normally require using a versioned symbol, the functions must instead be renamed. Therefore, I think we need to do two things: (1) Put the unversioned symbols back in libgcc, and or make libgcc depend on libunwind, thereby making sure that the symbols will be available. (2) Keep the versioned symbols that we have now because there might be (ABI-incompatible) code that depends upon them. -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-21 18:26 ` Mark Mitchell @ 2004-04-21 19:17 ` H. J. Lu 2004-04-21 19:20 ` Mark Mitchell 0 siblings, 1 reply; 69+ messages in thread From: H. J. Lu @ 2004-04-21 19:17 UTC (permalink / raw) To: Mark Mitchell Cc: Gabriel Dos Reis, Jim Wilson, Daniel Jacobowitz, David Mosberger, gcc On Wed, Apr 21, 2004 at 10:54:11AM -0700, Mark Mitchell wrote: > Gabriel Dos Reis wrote: > > >Jim Wilson <wilson@specifixinc.com> writes: > > > >| I fail to see any difference between what glibc does and what libgcc > >| does. > > > >I believe the main difference is that libgcc is tightly coupled with > >the compiler and glibc is more much decoupled. libgcc is fixed by the > >compiler. That makes its versioning more debatable. > >I'm not sure we can reason on what glibc does and transpose the > >outcome to libgcc. > > > > > I agree with David Mosberger. > > I think that it was a mistake to version the symbols. The C++ ABI is > designed so that compilers can interoperate; clearly, if GCC-compiled > objects contain references to versioned symbols, then other compilers > cannot easily provide matching runtime libraries, and vice versa. We have to be very careful this time. Otherwise, we may mix 2 unwind libraries by accident. The same gcc compiler source can be configured with or without libunwind. While we are on it, binaries compiled by gcc may reference gcc personality functions, which only come with gcc. That means when you mix them with other compilers, you have to do something like # icc .... find the right gcc personality functions How can we address this? > > If these functions need to change in some way that would normally > require using a versioned symbol, the functions must instead be renamed. Are you suggesting to change the C++ ABI in this case? If it is the case, shouldn't the C++ ABI be modified to reflect that? I guess those implementation who do it right will have to cope :-(. > > Therefore, I think we need to do two things: > > (1) Put the unversioned symbols back in libgcc, and or make libgcc > depend on libunwind, thereby making sure that the symbols will be available. > > (2) Keep the versioned symbols that we have now because there might be > (ABI-incompatible) code that depends upon them. > H.J. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-21 19:17 ` H. J. Lu @ 2004-04-21 19:20 ` Mark Mitchell 2004-04-21 19:34 ` Daniel Jacobowitz 2004-04-21 19:36 ` H. J. Lu 0 siblings, 2 replies; 69+ messages in thread From: Mark Mitchell @ 2004-04-21 19:20 UTC (permalink / raw) To: H. J. Lu Cc: Gabriel Dos Reis, Jim Wilson, Daniel Jacobowitz, David Mosberger, gcc >While we are on it, binaries compiled by gcc may reference gcc >personality functions, which only come with gcc. That means when you >mix them with other compilers, you have to do something like > ># icc .... find the right gcc personality functions > >How can we address this? > > The presonality routines should be either (a) included in the shared object or executable, or (b) the shared object or executable should have a dependency on a shared object providing that personality routine. >>If these functions need to change in some way that would normally >>require using a versioned symbol, the functions must instead be renamed. >> >> > >Are you suggesting to change the C++ ABI in this case? If it is the >case, shouldn't the C++ ABI be modified to reflect that? I guess >those implementation who do it right will have to cope :-(. > > If the C++ ABI needs to change, then it will change. In that case, new functions will be added to the ABI, and we will have to provide both the old and new functions. This is no different from versioning, except that it's an uglier way of doing it. -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-21 19:20 ` Mark Mitchell @ 2004-04-21 19:34 ` Daniel Jacobowitz 2004-04-21 20:05 ` Mark Mitchell 2004-04-21 19:36 ` H. J. Lu 1 sibling, 1 reply; 69+ messages in thread From: Daniel Jacobowitz @ 2004-04-21 19:34 UTC (permalink / raw) To: Mark Mitchell Cc: H. J. Lu, Gabriel Dos Reis, Jim Wilson, David Mosberger, gcc On Wed, Apr 21, 2004 at 12:15:16PM -0700, Mark Mitchell wrote: > > >While we are on it, binaries compiled by gcc may reference gcc > >personality functions, which only come with gcc. That means when you > >mix them with other compilers, you have to do something like > > > ># icc .... find the right gcc personality functions > > > >How can we address this? > > > > > The presonality routines should be either (a) included in the shared > object or executable, or (b) the shared object or executable should > have a dependency on a shared object providing that personality routine. It seems to me that we need to sit down and think about what kinds of "compatibility" are really guaranteed by the ABI before we make any changes in this area. For instance, we currently satisfy references to the unwind symbols (on ELF platforms, this is) by adding a DT_NEEDED referring to "libgcc_s.so.1". Does that violate the ABI? If not, perhaps versioning the symbols doesn't either. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-21 19:34 ` Daniel Jacobowitz @ 2004-04-21 20:05 ` Mark Mitchell 2004-04-21 20:18 ` H. J. Lu 0 siblings, 1 reply; 69+ messages in thread From: Mark Mitchell @ 2004-04-21 20:05 UTC (permalink / raw) To: Daniel Jacobowitz Cc: H. J. Lu, Gabriel Dos Reis, Jim Wilson, David Mosberger, gcc Daniel Jacobowitz wrote: >On Wed, Apr 21, 2004 at 12:15:16PM -0700, Mark Mitchell wrote: > > >>>While we are on it, binaries compiled by gcc may reference gcc >>>personality functions, which only come with gcc. That means when you >>>mix them with other compilers, you have to do something like >>> >>># icc .... find the right gcc personality functions >>> >>>How can we address this? >>> >>> >>> >>> >>The presonality routines should be either (a) included in the shared >>object or executable, or (b) the shared object or executable should >>have a dependency on a shared object providing that personality routine. >> >> > >It seems to me that we need to sit down and think about what kinds of >"compatibility" are really guaranteed by the ABI before we make any >changes in this area. For instance, we currently satisfy references to >the unwind symbols (on ELF platforms, this is) by adding a DT_NEEDED >referring to "libgcc_s.so.1". Does that violate the ABI? If not, >perhaps versioning the symbols doesn't either. > No, that doesn't violate the ABI. The is built atop whatever other ABIs are on the platform. On IA32 GNU/Linux (say), ELF with DT_NEEDED is part of the system ABI, so using it is just fine. Your program can depend on whatever shared objects it wants to, including libgcc. The C++ runtime support library (containing __cxa_* and _Unwind_*) is special; the ABI specifically is designed to allow any compiler to generate code that will work with any support library. I don't think the use of versioned symbols allows that; it means, concretely, that Intel would have to emit references to versioned symbols in the code that icc generates. That didn't use to be the case, and it shouldn't be the case now. -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-21 20:05 ` Mark Mitchell @ 2004-04-21 20:18 ` H. J. Lu 2004-04-21 21:13 ` Mark Mitchell 0 siblings, 1 reply; 69+ messages in thread From: H. J. Lu @ 2004-04-21 20:18 UTC (permalink / raw) To: Mark Mitchell Cc: Daniel Jacobowitz, Gabriel Dos Reis, Jim Wilson, David Mosberger, gcc On Wed, Apr 21, 2004 at 12:34:30PM -0700, Mark Mitchell wrote: > Daniel Jacobowitz wrote: > > >On Wed, Apr 21, 2004 at 12:15:16PM -0700, Mark Mitchell wrote: > > > > > >>>While we are on it, binaries compiled by gcc may reference gcc > >>>personality functions, which only come with gcc. That means when you > >>>mix them with other compilers, you have to do something like > >>> > >>># icc .... find the right gcc personality functions > >>> > >>>How can we address this? > >>> > >>> > >>> > >>> > >>The presonality routines should be either (a) included in the shared > >>object or executable, or (b) the shared object or executable should > >>have a dependency on a shared object providing that personality routine. > >> > >> > > > >It seems to me that we need to sit down and think about what kinds of > >"compatibility" are really guaranteed by the ABI before we make any > >changes in this area. For instance, we currently satisfy references to > >the unwind symbols (on ELF platforms, this is) by adding a DT_NEEDED > >referring to "libgcc_s.so.1". Does that violate the ABI? If not, > >perhaps versioning the symbols doesn't either. > > > No, that doesn't violate the ABI. The is built atop whatever other ABIs > are on the platform. On IA32 GNU/Linux (say), ELF with DT_NEEDED is > part of the system ABI, so using it is just fine. Your program can > depend on whatever shared objects it wants to, including libgcc. > > The C++ runtime support library (containing __cxa_* and _Unwind_*) is > special; the ABI specifically is designed to allow any compiler to > generate code that will work with any support library. I don't think > the use of versioned symbols allows that; it means, concretely, that > Intel would have to emit references to versioned symbols in the code > that icc generates. That didn't use to be the case, and it shouldn't be > the case now. > If we are building a shared library with DT_NEEDED pointed to the unwind library called "libgcc_s.so.1", how can another compiler use their unwind library, saying libmyunwind, with this DSO? If the C++ ABI covers unwind with shared library and executable, it should also specify how the unwind library should be handled at link time as well as at run time. H.J. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-21 20:18 ` H. J. Lu @ 2004-04-21 21:13 ` Mark Mitchell 2004-04-21 21:13 ` H. J. Lu 0 siblings, 1 reply; 69+ messages in thread From: Mark Mitchell @ 2004-04-21 21:13 UTC (permalink / raw) To: H. J. Lu Cc: Daniel Jacobowitz, Gabriel Dos Reis, Jim Wilson, David Mosberger, gcc H. J. Lu wrote: >On Wed, Apr 21, 2004 at 12:34:30PM -0700, Mark Mitchell wrote: > > >>Daniel Jacobowitz wrote: >> >> >> >>>On Wed, Apr 21, 2004 at 12:15:16PM -0700, Mark Mitchell wrote: >>> >>> >>> >>> >>>>>While we are on it, binaries compiled by gcc may reference gcc >>>>>personality functions, which only come with gcc. That means when you >>>>>mix them with other compilers, you have to do something like >>>>> >>>>># icc .... find the right gcc personality functions >>>>> >>>>>How can we address this? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>The presonality routines should be either (a) included in the shared >>>>object or executable, or (b) the shared object or executable should >>>>have a dependency on a shared object providing that personality routine. >>>> >>>> >>>> >>>> >>>It seems to me that we need to sit down and think about what kinds of >>>"compatibility" are really guaranteed by the ABI before we make any >>>changes in this area. For instance, we currently satisfy references to >>>the unwind symbols (on ELF platforms, this is) by adding a DT_NEEDED >>>referring to "libgcc_s.so.1". Does that violate the ABI? If not, >>>perhaps versioning the symbols doesn't either. >>> >>> >>> >>No, that doesn't violate the ABI. The is built atop whatever other ABIs >>are on the platform. On IA32 GNU/Linux (say), ELF with DT_NEEDED is >>part of the system ABI, so using it is just fine. Your program can >>depend on whatever shared objects it wants to, including libgcc. >> >>The C++ runtime support library (containing __cxa_* and _Unwind_*) is >>special; the ABI specifically is designed to allow any compiler to >>generate code that will work with any support library. I don't think >>the use of versioned symbols allows that; it means, concretely, that >>Intel would have to emit references to versioned symbols in the code >>that icc generates. That didn't use to be the case, and it shouldn't be >>the case now. >> >> >> > >If we are building a shared library with DT_NEEDED pointed to the >unwind library called "libgcc_s.so.1", how can another compiler use >their unwind library, saying libmyunwind, with this DSO? If the C++ >ABI covers unwind with shared library and executable, it should also >specify how the unwind library should be handled at link time as well >as at run time. > > The ABI says: An implementation shall place its standard support library in a DSO named |libcxa.so| on Itanium systems, or in auxiliary DSOs automatically loaded by it. It shall place implicit compiler support in a library separate from the standard support library, with any external names chosen to avoid conflicts between vendors (e.g. by including a vendor identifier as part of the names). The reference to "Itanium" is accidental. GCC, for whatever reason, has never provided libcxa.so. That library should contain all of the C++ ABI stuff, and should be *completely interchangeable* between vendor implementations. The complete set of interfaces and the behavior of those interfaces is specified by the C++ ABI. It should not matter whose libcxa.so you get; if it does matter either your program or the libcxa.so implementation you're using has a bug. Since GCC has never provided this library, there are going to be challenges here. The first step is to undo the versioning mistake. That's a sine qua non for anything else. After that, someone should implement libcxa.so. Probably, libgcc will need to depend on it, since existing programs expect libgcc to provide these interfaces. -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-21 21:13 ` Mark Mitchell @ 2004-04-21 21:13 ` H. J. Lu 2004-04-21 21:22 ` Mark Mitchell 0 siblings, 1 reply; 69+ messages in thread From: H. J. Lu @ 2004-04-21 21:13 UTC (permalink / raw) To: Mark Mitchell Cc: Daniel Jacobowitz, Gabriel Dos Reis, Jim Wilson, David Mosberger, gcc On Wed, Apr 21, 2004 at 01:52:07PM -0700, Mark Mitchell wrote: > > > >If we are building a shared library with DT_NEEDED pointed to the > >unwind library called "libgcc_s.so.1", how can another compiler use > >their unwind library, saying libmyunwind, with this DSO? If the C++ > >ABI covers unwind with shared library and executable, it should also > >specify how the unwind library should be handled at link time as well > >as at run time. > > > > > The ABI says: > > An implementation shall place its standard support library in a DSO > named |libcxa.so| on Itanium systems, or in auxiliary DSOs automatically > loaded by it. It shall place implicit compiler support in a library > separate from the standard support library, with any external names > chosen to avoid conflicts between vendors (e.g. by including a vendor > identifier as part of the names). > > The reference to "Itanium" is accidental. > > GCC, for whatever reason, has never provided libcxa.so. That library > should contain all of the C++ ABI stuff, and should be *completely > interchangeable* between vendor implementations. The complete set of > interfaces and the behavior of those interfaces is specified by the C++ > ABI. It should not matter whose libcxa.so you get; if it does matter > either your program or the libcxa.so implementation you're using has a bug. > So it is almost totally a run-time issue. You can link against a dummy libcxa.so if you want. It is the one picked up by the dynamic linker counts. > Since GCC has never provided this library, there are going to be > challenges here. > > The first step is to undo the versioning mistake. That's a sine qua non > for anything else. After that, someone should implement libcxa.so. > Probably, libgcc will need to depend on it, since existing programs > expect libgcc to provide these interfaces. Where do those versioned definitions for backward compatibilty come from? Should we consider libgcc_s.so.2? H.J. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-21 21:13 ` H. J. Lu @ 2004-04-21 21:22 ` Mark Mitchell 2004-04-21 21:43 ` H. J. Lu 2004-04-22 15:47 ` H. J. Lu 0 siblings, 2 replies; 69+ messages in thread From: Mark Mitchell @ 2004-04-21 21:22 UTC (permalink / raw) To: H. J. Lu Cc: Daniel Jacobowitz, Gabriel Dos Reis, Jim Wilson, David Mosberger, gcc H. J. Lu wrote: >>Since GCC has never provided this library, there are going to be >>challenges here. >> >>The first step is to undo the versioning mistake. That's a sine qua non >>for anything else. After that, someone should implement libcxa.so. >>Probably, libgcc will need to depend on it, since existing programs >>expect libgcc to provide these interfaces. >> >> > >Where do those versioned definitions for backward compatibilty come >from? Should we consider libgcc_s.so.2? > > Maybe. If we split out the C++ support into libcxa.so at that time we could perhaps clean up some of this mess. The way it should be is that libcxa.so should contain the C++ ABI stuff, and libgcc_s.so should contain stuff like math support functions and the exception personality routines. -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-21 21:22 ` Mark Mitchell @ 2004-04-21 21:43 ` H. J. Lu 2004-04-22 15:47 ` H. J. Lu 1 sibling, 0 replies; 69+ messages in thread From: H. J. Lu @ 2004-04-21 21:43 UTC (permalink / raw) To: Mark Mitchell Cc: Daniel Jacobowitz, Gabriel Dos Reis, Jim Wilson, David Mosberger, gcc On Wed, Apr 21, 2004 at 02:13:39PM -0700, Mark Mitchell wrote: > H. J. Lu wrote: > > >>Since GCC has never provided this library, there are going to be > >>challenges here. > >> > >>The first step is to undo the versioning mistake. That's a sine qua non > >>for anything else. After that, someone should implement libcxa.so. > >>Probably, libgcc will need to depend on it, since existing programs > >>expect libgcc to provide these interfaces. > >> > >> > > > >Where do those versioned definitions for backward compatibilty come > >from? Should we consider libgcc_s.so.2? > > > > > Maybe. If we split out the C++ support into libcxa.so at that time we > could perhaps clean up some of this mess. The way it should be is that > libcxa.so should contain the C++ ABI stuff, and libgcc_s.so should > contain stuff like math support functions and the exception personality > routines. > FYI, glibc does dlopen ("libgcc_s.so.1") to get unwind library. Also icc has a libcxa.so, but it is not the unwind library. We may need to take another look at C++ ABI to get it right this time for all compilers. H.J. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-21 21:22 ` Mark Mitchell 2004-04-21 21:43 ` H. J. Lu @ 2004-04-22 15:47 ` H. J. Lu 2004-04-22 17:07 ` Mark Mitchell 1 sibling, 1 reply; 69+ messages in thread From: H. J. Lu @ 2004-04-22 15:47 UTC (permalink / raw) To: Mark Mitchell Cc: Daniel Jacobowitz, Gabriel Dos Reis, Jim Wilson, David Mosberger, gcc On Wed, Apr 21, 2004 at 02:13:39PM -0700, Mark Mitchell wrote: > H. J. Lu wrote: > > >>Since GCC has never provided this library, there are going to be > >>challenges here. > >> > >>The first step is to undo the versioning mistake. That's a sine qua non > >>for anything else. After that, someone should implement libcxa.so. > >>Probably, libgcc will need to depend on it, since existing programs > >>expect libgcc to provide these interfaces. > >> > >> > > > >Where do those versioned definitions for backward compatibilty come > >from? Should we consider libgcc_s.so.2? > > > > > Maybe. If we split out the C++ support into libcxa.so at that time we > could perhaps clean up some of this mess. The way it should be is that > libcxa.so should contain the C++ ABI stuff, and libgcc_s.so should > contain stuff like math support functions and the exception personality > routines. > If C++ ABI only specifies the shared unwind library, compilers have less control over what unwind library will be used by executable. Also it is good for compiler vendors since they don't have to ship their own unwind libraries and use the standard one instead. So it is more an issue that different compilers don't have to use their own unwind libraries and use the standard one instead than different compilers can use their own unwind libraries. Basically, the unwind library can be treated as the C library. That is any C++ ABI compliant unwind library should work with any C++ ABI compliant compilers. There is no strong reason for a C++ ABI compliant compiler to ship their own unwind library if there is a C++ ABI compliant system unwind library. Assuming the unwind library will be a standard library like the C library, symbol versioning will be a good thing for the standard library. But it shouldn't use version name like GCC or GLIBC. H.J. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-22 15:47 ` H. J. Lu @ 2004-04-22 17:07 ` Mark Mitchell 2004-04-22 17:22 ` H. J. Lu 2004-04-22 19:22 ` David Mosberger 0 siblings, 2 replies; 69+ messages in thread From: Mark Mitchell @ 2004-04-22 17:07 UTC (permalink / raw) To: H. J. Lu Cc: Daniel Jacobowitz, Gabriel Dos Reis, Jim Wilson, David Mosberger, gcc H. J. Lu wrote: >There is no strong >reason for a C++ ABI compliant compiler to ship their own unwind >library if there is a C++ ABI compliant system unwind library. > > > I agree. However, we shouldn't call this the unwind library. In addition to unwinding routines, it contains things operator new/delete and __cxa_dynamic_cast. Let's call it the ABI library. There may be good reasons for having a compiler-specific personality routine, but that would not be part of the ABI library. It is possible that some ABI libraries will be more efficient than others, so a compiler might want to provide a version that is superior. But, if a user chooses to use the system one instead, their programs will still work. >Assuming the unwind library will be a standard library like the C >library, symbol versioning will be a good thing for the standard >library. But it shouldn't use version name like GCC or GLIBC. > > I don't agree with this statement. It means that users cannot replace the system ABI library with one provided by another compiler. The way that the ABI contemplates dealing with versioning is by creating new function names. That may be considered inferior and primitive, but it is the way that it is. Any problem that would require a new version number on GNU/Linux will require a new function name on other systems. So, using version numbers will just make things different across systems for no good reason. -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-22 17:07 ` Mark Mitchell @ 2004-04-22 17:22 ` H. J. Lu 2004-04-22 17:28 ` Mark Mitchell 2004-04-22 19:22 ` David Mosberger 1 sibling, 1 reply; 69+ messages in thread From: H. J. Lu @ 2004-04-22 17:22 UTC (permalink / raw) To: Mark Mitchell Cc: Daniel Jacobowitz, Gabriel Dos Reis, Jim Wilson, David Mosberger, gcc On Thu, Apr 22, 2004 at 09:36:36AM -0700, Mark Mitchell wrote: > > However, we shouldn't call this the unwind library. In addition to > unwinding routines, it contains things operator new/delete and > __cxa_dynamic_cast. Let's call it the ABI library. > > There may be good reasons for having a compiler-specific personality > routine, but that would not be part of the ABI library. It is possible > that some ABI libraries will be more efficient than others, so a > compiler might want to provide a version that is superior. But, if a > user chooses to use the system one instead, their programs will still work. > > >Assuming the unwind library will be a standard library like the C > >library, symbol versioning will be a good thing for the standard > >library. But it shouldn't use version name like GCC or GLIBC. > > > > > I don't agree with this statement. > > It means that users cannot replace the system ABI library with one > provided by another compiler. > > The way that the ABI contemplates dealing with versioning is by creating > new function names. That may be considered inferior and primitive, but > it is the way that it is. Any problem that would require a new version > number on GNU/Linux will require a new function name on other systems. > So, using version numbers will just make things different across systems > for no good reason. > Versioning can be used for 2 things: 1. Change ABI. 2. Fix implementation. We don't need versioning to change ABI here. But it is still useful to fix implementation. That is you have a broken implementation, but you can't change the implementation since some binaries depend on the old broken behavior. Symbol versioning allows you to fix the implementation without breaking those old binaries. H.J. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-22 17:22 ` H. J. Lu @ 2004-04-22 17:28 ` Mark Mitchell 2004-04-22 17:29 ` H. J. Lu 0 siblings, 1 reply; 69+ messages in thread From: Mark Mitchell @ 2004-04-22 17:28 UTC (permalink / raw) To: H. J. Lu Cc: Daniel Jacobowitz, Gabriel Dos Reis, Jim Wilson, David Mosberger, gcc H. J. Lu wrote: >We don't need versioning to change ABI here. But it is still useful to >fix implementation. That is you have a broken implementation, but you >can't change the implementation since some binaries depend on the old >broken behavior. Symbol versioning allows you to fix the implementation >without breaking those old binaries. > I don't necessarily see that as a good idea. If, for example, "operator new" were to be broken, then old binaries that use the broken version might crash sometimes. Providing a fixed version of "operator new" would help those binaries, not hurt them. There might be some other old binaries that would somehow now fail, but why should we expect there would be more binaries in the latter class thant he former? And, there remains the issue that using versioning means that other compilers cannot easily provide a drop-in replacement for libcxa.so, even if they have a good reason (performance, for example) for doing so. -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-22 17:28 ` Mark Mitchell @ 2004-04-22 17:29 ` H. J. Lu 2004-04-22 17:46 ` Mark Mitchell 0 siblings, 1 reply; 69+ messages in thread From: H. J. Lu @ 2004-04-22 17:29 UTC (permalink / raw) To: Mark Mitchell Cc: Daniel Jacobowitz, Gabriel Dos Reis, Jim Wilson, David Mosberger, gcc On Thu, Apr 22, 2004 at 10:07:36AM -0700, Mark Mitchell wrote: > H. J. Lu wrote: > > >We don't need versioning to change ABI here. But it is still useful to > >fix implementation. That is you have a broken implementation, but you > >can't change the implementation since some binaries depend on the old > >broken behavior. Symbol versioning allows you to fix the implementation > >without breaking those old binaries. > > > I don't necessarily see that as a good idea. If, for example, "operator > new" were to be broken, then old binaries that use the broken version > might crash sometimes. Providing a fixed version of "operator new" > would help those binaries, not hurt them. There might be some other old I was not talking about those binaries. > binaries that would somehow now fail, but why should we expect there > would be more binaries in the latter class thant he former? It is not about the numbers. It is binary compatibility. For every reported breakage, it may affect many people. > > And, there remains the issue that using versioning means that other > compilers cannot easily provide a drop-in replacement for libcxa.so, > even if they have a good reason (performance, for example) for doing so. It is very trivial to provide versioning. If they can build a shared library on Linux, they can add versioning in 2 minutes. I can provide assistance to any compiler vendor if needed. H.J. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-22 17:29 ` H. J. Lu @ 2004-04-22 17:46 ` Mark Mitchell 2004-04-22 17:59 ` H. J. Lu 0 siblings, 1 reply; 69+ messages in thread From: Mark Mitchell @ 2004-04-22 17:46 UTC (permalink / raw) To: H. J. Lu Cc: Daniel Jacobowitz, Gabriel Dos Reis, Jim Wilson, David Mosberger, gcc H. J. Lu wrote: >>> >>> >>I don't necessarily see that as a good idea. If, for example, "operator >>new" were to be broken, then old binaries that use the broken version >>might crash sometimes. Providing a fixed version of "operator new" >>would help those binaries, not hurt them. There might be some other old >> >> > >I was not talking about those binaries. > > You can't know which binaries you'd affect. If you fix an implementation bug in an existing function, without changing the version, you'll help some binaries and you may hurt others. In my opinion, it makes sense to have the change affect all binaries. These functions are very fundamental. They're like "strlen". If we found a bug in "strlen", would fixing it in libc result in changing the version number of that symbol? In fact, if you discover a bug in these ABI functions, you are likely to have uncovered a security bug. It's quite possible that a program which gets an incorrect answer from an ABI function will do something it should not. If you version the symbol, then fixing the bug will not fix the security bug. You will have to go recompile all the programs on the system that use the ABI function in order to get the fix. -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-22 17:46 ` Mark Mitchell @ 2004-04-22 17:59 ` H. J. Lu 2004-04-22 18:07 ` Mark Mitchell 0 siblings, 1 reply; 69+ messages in thread From: H. J. Lu @ 2004-04-22 17:59 UTC (permalink / raw) To: Mark Mitchell Cc: Daniel Jacobowitz, Gabriel Dos Reis, Jim Wilson, David Mosberger, gcc On Thu, Apr 22, 2004 at 10:38:35AM -0700, Mark Mitchell wrote: > H. J. Lu wrote: > > >>> > >>> > >>I don't necessarily see that as a good idea. If, for example, "operator > >>new" were to be broken, then old binaries that use the broken version > >>might crash sometimes. Providing a fixed version of "operator new" > >>would help those binaries, not hurt them. There might be some other old > >> > >> > > > >I was not talking about those binaries. > > > > > You can't know which binaries you'd affect. If you fix an > implementation bug in an existing function, without changing the > version, you'll help some binaries and you may hurt others. > > In my opinion, it makes sense to have the change affect all binaries. > > These functions are very fundamental. They're like "strlen". If we > found a bug in "strlen", would fixing it in libc result in changing the > version number of that symbol? > > In fact, if you discover a bug in these ABI functions, you are likely to > have uncovered a security bug. It's quite possible that a program which > gets an incorrect answer from an ABI function will do something it > should not. If you version the symbol, then fixing the bug will not fix > the security bug. You will have to go recompile all the programs on the > system that use the ABI function in order to get the fix. > Your example shows how versioning will help here. If the existing programs can't pass the security audit without recompiling after fixing the ABI implemenation, we can change the version without providing the old version for backward compatibilty, those programs won't post a security risk since they can't run. Or we can put a warning message in the old version if the risk is relatively low. Without versioning, it won't be easy to fix the security bug in the implemenation. H.J. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-22 17:59 ` H. J. Lu @ 2004-04-22 18:07 ` Mark Mitchell 2004-04-22 18:54 ` H. J. Lu 0 siblings, 1 reply; 69+ messages in thread From: Mark Mitchell @ 2004-04-22 18:07 UTC (permalink / raw) To: H. J. Lu Cc: Daniel Jacobowitz, Gabriel Dos Reis, Jim Wilson, David Mosberger, gcc H. J. Lu wrote: >Your example shows how versioning will help here. If the existing >programs can't pass the security audit without recompiling after >fixing the ABI implemenation, we can change the version without >providing the old version for backward compatibilty, those programs >won't post a security risk since they can't run. Or we can put >a warning message in the old version if the risk is relatively low. > >Without versioning, it won't be easy to fix the security bug in the >implemenation. > > I understand your argument, but I don't find it compelling. Doing what you suggest would cause a lot of programs that work just fine -- with or without the change -- to stop working. I think it's time for us to agree to disagree. In any case, this issue is in the noise. One key issue to solve is getting libcxa.so out of libgcc, and putting just the ABI-required symbols in that library. Once that gets done, we can figure out what to do next. A second key issue is fixing the backwards compatibility problem we already have due to the fact that the symbols in libgcc are now versioned. Let's work on those issues first. Then, we can decide whether or not to version the symbols in libcxa. -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-22 18:07 ` Mark Mitchell @ 2004-04-22 18:54 ` H. J. Lu 2004-04-22 21:48 ` Mark Mitchell 0 siblings, 1 reply; 69+ messages in thread From: H. J. Lu @ 2004-04-22 18:54 UTC (permalink / raw) To: Mark Mitchell Cc: Daniel Jacobowitz, Gabriel Dos Reis, Jim Wilson, David Mosberger, gcc On Thu, Apr 22, 2004 at 10:58:57AM -0700, Mark Mitchell wrote: > H. J. Lu wrote: > > >Your example shows how versioning will help here. If the existing > >programs can't pass the security audit without recompiling after > >fixing the ABI implemenation, we can change the version without > >providing the old version for backward compatibilty, those programs > >won't post a security risk since they can't run. Or we can put > >a warning message in the old version if the risk is relatively low. > > > >Without versioning, it won't be easy to fix the security bug in the > >implemenation. > > > > > I understand your argument, but I don't find it compelling. Doing what > you suggest would cause a lot of programs that work just fine -- with or > without the change -- to stop working. I think there is a misconception here. It won't happen if we do it right. We have lots of experiences on Linux. > > I think it's time for us to agree to disagree. > Agreed. > In any case, this issue is in the noise. One key issue to solve is > getting libcxa.so out of libgcc, and putting just the ABI-required > symbols in that library. Once that gets done, we can figure out what to > do next. A second key issue is fixing the backwards compatibility > problem we already have due to the fact that the symbols in libgcc are > now versioned. Let's work on those issues first. Then, we can decide > whether or not to version the symbols in libcxa. Those 2 issues are tied together. I think we may have to move to libgcc_s.so.2. If we have more control over the ABI library, we may be to able do something like: 1. The ABI library provides separate entries for those backward compatibility functions. 2. libgcc_s.so.1 defines those old backward compatibility functions as wrappers of the real ones in the ABI library. H.J. H.J. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-22 18:54 ` H. J. Lu @ 2004-04-22 21:48 ` Mark Mitchell 2004-04-22 23:03 ` H. J. Lu 0 siblings, 1 reply; 69+ messages in thread From: Mark Mitchell @ 2004-04-22 21:48 UTC (permalink / raw) To: H. J. Lu Cc: Daniel Jacobowitz, Gabriel Dos Reis, Jim Wilson, David Mosberger, gcc H. J. Lu wrote: >>In any case, this issue is in the noise. One key issue to solve is >>getting libcxa.so out of libgcc, and putting just the ABI-required >>symbols in that library. Once that gets done, we can figure out what to >>do next. A second key issue is fixing the backwards compatibility >>problem we already have due to the fact that the symbols in libgcc are >>now versioned. Let's work on those issues first. Then, we can decide >>whether or not to version the symbols in libcxa. >> >> > >Those 2 issues are tied together. I think we may have to move to >libgcc_s.so.2. If we have more control over the ABI library, we may be >to able do something like: > >1. The ABI library provides separate entries for those backward >compatibility functions. >2. libgcc_s.so.1 defines those old backward compatibility functions >as wrappers of the real ones in the ABI library. > > I'd rather see the ABI library contain just the functions the ABI requires it to contain. Put the backwards compatibility stuff in libgcc.so. I'm not sure about whether or not we need to bump the version number on libgcc.so -- but I could believe that we have to do so. -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-22 21:48 ` Mark Mitchell @ 2004-04-22 23:03 ` H. J. Lu 2004-04-22 23:15 ` David Mosberger 0 siblings, 1 reply; 69+ messages in thread From: H. J. Lu @ 2004-04-22 23:03 UTC (permalink / raw) To: Mark Mitchell Cc: Daniel Jacobowitz, Gabriel Dos Reis, Jim Wilson, David Mosberger, gcc On Thu, Apr 22, 2004 at 02:39:37PM -0700, Mark Mitchell wrote: > H. J. Lu wrote: > > >>In any case, this issue is in the noise. One key issue to solve is > >>getting libcxa.so out of libgcc, and putting just the ABI-required > >>symbols in that library. Once that gets done, we can figure out what to > >>do next. A second key issue is fixing the backwards compatibility > >>problem we already have due to the fact that the symbols in libgcc are > >>now versioned. Let's work on those issues first. Then, we can decide > >>whether or not to version the symbols in libcxa. > >> > >> > > > >Those 2 issues are tied together. I think we may have to move to > >libgcc_s.so.2. If we have more control over the ABI library, we may be > >to able do something like: > > > >1. The ABI library provides separate entries for those backward > >compatibility functions. > >2. libgcc_s.so.1 defines those old backward compatibility functions > >as wrappers of the real ones in the ABI library. > > > > > I'd rather see the ABI library contain just the functions the ABI > requires it to contain. Put the backwards compatibility stuff in > libgcc.so. I'm not sure about whether or not we need to bump the > version number on libgcc.so -- but I could believe that we have to do so. > Are you suggesting to have 2 unwind libraries at run-time, one for backwards compatibility in libgcc.so and the new one in the ABI library? BTW, since the ABI library is more than just unwind library. We can't use David's unwind library as is. Also his unwind library is a link-time replacement, not run-time replacement for existing unwind library in icc. H.J. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-22 23:03 ` H. J. Lu @ 2004-04-22 23:15 ` David Mosberger 2004-04-22 23:34 ` H. J. Lu 0 siblings, 1 reply; 69+ messages in thread From: David Mosberger @ 2004-04-22 23:15 UTC (permalink / raw) To: H. J. Lu Cc: Mark Mitchell, Daniel Jacobowitz, Gabriel Dos Reis, Jim Wilson, David Mosberger, gcc >>>>> On Thu, 22 Apr 2004 15:02:15 -0700, "H. J. Lu" <hjl@lucon.org> said: HJ> BTW, since the ABI library is more than just unwind library. We HJ> can't use David's unwind library as is. You can. Just list -lunwind as a dependency as is done now with libgcc_s. HJ> Also his unwind library is a link-time replacement, not run-time HJ> replacement for existing unwind library in icc. That's not true any longer: with the libunwind in the bk repository (due to be released as v0.97 any day now), my libunwind can serve as a direct replacement for Intel's libunwind. The only left-over wrinkle at the moment is that Intel's major version is 6 whereas mine has version 1. I'm not sure what to do about that. Perhaps we should all just use 6 since the actual version doesn't matter? --david ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-22 23:15 ` David Mosberger @ 2004-04-22 23:34 ` H. J. Lu 2004-04-22 23:36 ` David Mosberger 2004-04-22 23:50 ` Daniel Jacobowitz 0 siblings, 2 replies; 69+ messages in thread From: H. J. Lu @ 2004-04-22 23:34 UTC (permalink / raw) To: davidm Cc: Mark Mitchell, Daniel Jacobowitz, Gabriel Dos Reis, Jim Wilson, gcc On Thu, Apr 22, 2004 at 03:12:32PM -0700, David Mosberger wrote: > >>>>> On Thu, 22 Apr 2004 15:02:15 -0700, "H. J. Lu" <hjl@lucon.org> said: > > HJ> BTW, since the ABI library is more than just unwind library. We > HJ> can't use David's unwind library as is. > > You can. Just list -lunwind as a dependency as is done now with libgcc_s. I don't think it will work AS IS since linker may add libunwind.so to DT_NEEDED if it is used. A new linker option may be needed to work with it. > > HJ> Also his unwind library is a link-time replacement, not run-time > HJ> replacement for existing unwind library in icc. > > That's not true any longer: with the libunwind in the bk repository > (due to be released as v0.97 any day now), my libunwind can serve as a > direct replacement for Intel's libunwind. The only left-over wrinkle > at the moment is that Intel's major version is 6 whereas mine has > version 1. I'm not sure what to do about that. Perhaps we should all > just use 6 since the actual version doesn't matter? It may not matter if we can make sure DT_NEEDED entry in the ABI library never shows up in executable or shared library. H.J. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-22 23:34 ` H. J. Lu @ 2004-04-22 23:36 ` David Mosberger 2004-04-23 1:15 ` H. J. Lu 2004-04-22 23:50 ` Daniel Jacobowitz 1 sibling, 1 reply; 69+ messages in thread From: David Mosberger @ 2004-04-22 23:36 UTC (permalink / raw) To: H. J. Lu Cc: davidm, Mark Mitchell, Daniel Jacobowitz, Gabriel Dos Reis, Jim Wilson, gcc >>>>> On Thu, 22 Apr 2004 16:15:12 -0700, "H. J. Lu" <hjl@lucon.org> said: HJ> On Thu, Apr 22, 2004 at 03:12:32PM -0700, David Mosberger wrote: >> >>>>> On Thu, 22 Apr 2004 15:02:15 -0700, "H. J. Lu" <hjl@lucon.org> said: HJ> BTW, since the ABI library is more than just unwind library. We HJ> can't use David's unwind library as is. >> You can. Just list -lunwind as a dependency as is done now with libgcc_s. HJ> I don't think it will work AS IS since linker may add libunwind.so to HJ> DT_NEEDED if it is used. A new linker option may be needed to work HJ> with it. Ah, you're worried that linking against libcxa.so would cause a DT_NEEDED entry for libunwind.so in the _executable_? I agree that's not ideal, but it's already happening with the Intel compiler, so in that sense it's nothing new. If that could be avoided, I suppose it would be great. --david ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-22 23:36 ` David Mosberger @ 2004-04-23 1:15 ` H. J. Lu 0 siblings, 0 replies; 69+ messages in thread From: H. J. Lu @ 2004-04-23 1:15 UTC (permalink / raw) To: davidm Cc: Mark Mitchell, Daniel Jacobowitz, Gabriel Dos Reis, Jim Wilson, gcc On Thu, Apr 22, 2004 at 04:34:25PM -0700, David Mosberger wrote: > >>>>> On Thu, 22 Apr 2004 16:15:12 -0700, "H. J. Lu" <hjl@lucon.org> said: > > HJ> On Thu, Apr 22, 2004 at 03:12:32PM -0700, David Mosberger wrote: > >> >>>>> On Thu, 22 Apr 2004 15:02:15 -0700, "H. J. Lu" <hjl@lucon.org> said: > > HJ> BTW, since the ABI library is more than just unwind library. We > HJ> can't use David's unwind library as is. > > >> You can. Just list -lunwind as a dependency as is done now with libgcc_s. > > HJ> I don't think it will work AS IS since linker may add libunwind.so to > HJ> DT_NEEDED if it is used. A new linker option may be needed to work > HJ> with it. > > Ah, you're worried that linking against libcxa.so would cause a > DT_NEEDED entry for libunwind.so in the _executable_? I agree that's It means you can't use a different ABI library which doesn't depend on a separate unwind library. > not ideal, but it's already happening with the Intel compiler, so in > that sense it's nothing new. If that could be avoided, I suppose it > would be great. H.J. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-22 23:34 ` H. J. Lu 2004-04-22 23:36 ` David Mosberger @ 2004-04-22 23:50 ` Daniel Jacobowitz 2004-04-22 23:59 ` David Mosberger 1 sibling, 1 reply; 69+ messages in thread From: Daniel Jacobowitz @ 2004-04-22 23:50 UTC (permalink / raw) To: H. J. Lu; +Cc: davidm, Mark Mitchell, Gabriel Dos Reis, Jim Wilson, gcc On Thu, Apr 22, 2004 at 04:15:12PM -0700, H. J. Lu wrote: > On Thu, Apr 22, 2004 at 03:12:32PM -0700, David Mosberger wrote: > > >>>>> On Thu, 22 Apr 2004 15:02:15 -0700, "H. J. Lu" <hjl@lucon.org> said: > > > > HJ> BTW, since the ABI library is more than just unwind library. We > > HJ> can't use David's unwind library as is. > > > > You can. Just list -lunwind as a dependency as is done now with libgcc_s. > > I don't think it will work AS IS since linker may add libunwind.so to > DT_NEEDED if it is used. A new linker option may be needed to work > with it. Are you sure that that will happen? I don't think so. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-22 23:50 ` Daniel Jacobowitz @ 2004-04-22 23:59 ` David Mosberger 2004-04-23 1:37 ` H. J. Lu 0 siblings, 1 reply; 69+ messages in thread From: David Mosberger @ 2004-04-22 23:59 UTC (permalink / raw) To: Daniel Jacobowitz Cc: H. J. Lu, davidm, Mark Mitchell, Gabriel Dos Reis, Jim Wilson, gcc >>>>> On Thu, 22 Apr 2004 19:34:26 -0400, Daniel Jacobowitz <drow@false.org> said: Daniel> On Thu, Apr 22, 2004 at 04:15:12PM -0700, H. J. Lu wrote: >> On Thu, Apr 22, 2004 at 03:12:32PM -0700, David Mosberger wrote: >> > >>>>> On Thu, 22 Apr 2004 15:02:15 -0700, "H. J. Lu" <hjl@lucon.org> said: >> > HJ> BTW, since the ABI library is more than just unwind library. We >> > HJ> can't use David's unwind library as is. >> > You can. Just list -lunwind as a dependency as is done now with libgcc_s. >> I don't think it will work AS IS since linker may add libunwind.so to >> DT_NEEDED if it is used. A new linker option may be needed to work >> with it. Daniel> Are you sure that that will happen? I don't think so. I think HJ is right. I did try with an older GCC release that was built with libunwind enabled. The unwind library showed up as a dependency of the executable even though the linker command line did not specify -lunwind explicitly. Perhaps it's a linker bug? --david ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-22 23:59 ` David Mosberger @ 2004-04-23 1:37 ` H. J. Lu 2004-04-23 2:30 ` David Mosberger 0 siblings, 1 reply; 69+ messages in thread From: H. J. Lu @ 2004-04-23 1:37 UTC (permalink / raw) To: davidm Cc: Daniel Jacobowitz, Mark Mitchell, Gabriel Dos Reis, Jim Wilson, gcc On Thu, Apr 22, 2004 at 04:50:43PM -0700, David Mosberger wrote: > >>>>> On Thu, 22 Apr 2004 19:34:26 -0400, Daniel Jacobowitz <drow@false.org> said: > > Daniel> On Thu, Apr 22, 2004 at 04:15:12PM -0700, H. J. Lu wrote: > >> On Thu, Apr 22, 2004 at 03:12:32PM -0700, David Mosberger wrote: > >> > >>>>> On Thu, 22 Apr 2004 15:02:15 -0700, "H. J. Lu" <hjl@lucon.org> said: > > >> > HJ> BTW, since the ABI library is more than just unwind library. We > >> > HJ> can't use David's unwind library as is. > > >> > You can. Just list -lunwind as a dependency as is done now with libgcc_s. > >> I don't think it will work AS IS since linker may add libunwind.so to > >> DT_NEEDED if it is used. A new linker option may be needed to work > >> with it. > > Daniel> Are you sure that that will happen? I don't think so. > > I think HJ is right. I did try with an older GCC release that was > built with libunwind enabled. The unwind library showed up as a > dependency of the executable even though the linker command line did > not specify -lunwind explicitly. Perhaps it's a linker bug? > The linker behavior is intentional. We can always add a new linker switch to turn it off for the ABI library with something like -Wl,--no-add-needed -lABI -Wl,--add-needed H.J. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-23 1:37 ` H. J. Lu @ 2004-04-23 2:30 ` David Mosberger 0 siblings, 0 replies; 69+ messages in thread From: David Mosberger @ 2004-04-23 2:30 UTC (permalink / raw) To: H. J. Lu Cc: davidm, Daniel Jacobowitz, Mark Mitchell, Gabriel Dos Reis, Jim Wilson, gcc >>>>> On Thu, 22 Apr 2004 18:04:41 -0700, "H. J. Lu" <hjl@lucon.org> said: >> I think HJ is right. I did try with an older GCC release that >> was built with libunwind enabled. The unwind library showed up >> as a dependency of the executable even though the linker command >> line did not specify -lunwind explicitly. Perhaps it's a linker >> bug? HJ> The linker behavior is intentional. What's the advantage of that behavior? HJ> We can always add a new linker switch to turn it off for the ABI HJ> library with something like HJ> -Wl,--no-add-needed -lABI -Wl,--add-needed That seems fine to me. --david ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-22 17:07 ` Mark Mitchell 2004-04-22 17:22 ` H. J. Lu @ 2004-04-22 19:22 ` David Mosberger 2004-04-22 21:39 ` Mark Mitchell 1 sibling, 1 reply; 69+ messages in thread From: David Mosberger @ 2004-04-22 19:22 UTC (permalink / raw) To: Mark Mitchell Cc: H. J. Lu, Daniel Jacobowitz, Gabriel Dos Reis, Jim Wilson, David Mosberger, gcc >>>>> On Thu, 22 Apr 2004 09:36:36 -0700, Mark Mitchell <mark@codesourcery.com> said: Mark> However, we shouldn't call this the unwind library. In addition to Mark> unwinding routines, it contains things operator new/delete and Mark> __cxa_dynamic_cast. Let's call it the ABI library. As long as the "ABI library" may consist of a separate unwind-library, I'm OK with that. Note that both HP-UX and the Intel compiler on Linux use a separate libunwind.so to provide the actual unwinder. My unwind library also provides (a plugin-compatible) libunwind.so and it cannot & should not implement C++ specific runtime support, so it seems to me that it makes tons of sense to split up the cxa_*() and _Unwind*() routines. Of course, libcxa.so can (must?) have a dependency on libunwind.so, so that if you load libcxa.so, you'll get _Unwind*() along with it. Mark> There may be good reasons for having a compiler-specific Mark> personality routine, but that would not be part of the ABI Mark> library. It is possible that some ABI libraries will be more Mark> efficient than others, so a compiler might want to provide a Mark> version that is superior. But, if a user chooses to use the Mark> system one instead, their programs will still work. Note that the Intel compiler provides __gxx_personality_v0() in its own library. I suspect that's not right, but probably it is/was the only way for the Intel compiler to be interoperable with GCC-compiled C++ code. >> Assuming the unwind library will be a standard library like the C >> library, symbol versioning will be a good thing for the standard >> library. But it shouldn't use version name like GCC or GLIBC. Mark> I don't agree with this statement. Mark> It means that users cannot replace the system ABI library with Mark> one provided by another compiler. Mark> The way that the ABI contemplates dealing with versioning is Mark> by creating new function names. That may be considered Mark> inferior and primitive, but it is the way that it is. Any Mark> problem that would require a new version number on GNU/Linux Mark> will require a new function name on other systems. So, using Mark> version numbers will just make things different across systems Mark> for no good reason. I very much agree with Mark here. Especially considering that versioned symbols have some "interesting" problems, as pointed out by HJ's bug report here: http://sources.redhat.com/ml/libc-alpha/2003-09/msg00154.html The followup by Uli Drepper seems to indicate that the glibc developers have no interest in fixing this issue. In other words: even _if_ the ABI-committee agreed to allow for versioned symbols, there would still be potential problems in using them on glibc-based systems. Usage scenarios that would work with unversioned symbols might not work with versioned symbols. --david ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-22 19:22 ` David Mosberger @ 2004-04-22 21:39 ` Mark Mitchell 0 siblings, 0 replies; 69+ messages in thread From: Mark Mitchell @ 2004-04-22 21:39 UTC (permalink / raw) To: davidm; +Cc: H. J. Lu, Daniel Jacobowitz, Gabriel Dos Reis, Jim Wilson, gcc David Mosberger wrote: >>>>>>On Thu, 22 Apr 2004 09:36:36 -0700, Mark Mitchell <mark@codesourcery.com> said: >>>>>> >>>>>> > > Mark> However, we shouldn't call this the unwind library. In addition to > Mark> unwinding routines, it contains things operator new/delete and > Mark> __cxa_dynamic_cast. Let's call it the ABI library. > >As long as the "ABI library" may consist of a separate unwind-library, >I'm OK with that. > Yes, I think that's OK. The ABI library should be called "libcxa.so", and linking against it must satisfy requests for unwind symbols, but if that's because libcxa.so pulls in other libraries, that's OK. -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-21 19:20 ` Mark Mitchell 2004-04-21 19:34 ` Daniel Jacobowitz @ 2004-04-21 19:36 ` H. J. Lu 2004-04-21 20:18 ` Mark Mitchell 1 sibling, 1 reply; 69+ messages in thread From: H. J. Lu @ 2004-04-21 19:36 UTC (permalink / raw) To: Mark Mitchell Cc: Gabriel Dos Reis, Jim Wilson, Daniel Jacobowitz, David Mosberger, gcc On Wed, Apr 21, 2004 at 12:15:16PM -0700, Mark Mitchell wrote: > > >While we are on it, binaries compiled by gcc may reference gcc > >personality functions, which only come with gcc. That means when you > >mix them with other compilers, you have to do something like > > > ># icc .... find the right gcc personality functions > > > >How can we address this? > > > > > The presonality routines should be either (a) included in the shared > object or executable, or (b) the shared object or executable should > have a dependency on a shared object providing that personality routine. It doesn't help when I want to use relocatable object files generated by gcc with icc. H.J. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-21 19:36 ` H. J. Lu @ 2004-04-21 20:18 ` Mark Mitchell 0 siblings, 0 replies; 69+ messages in thread From: Mark Mitchell @ 2004-04-21 20:18 UTC (permalink / raw) To: H. J. Lu Cc: Gabriel Dos Reis, Jim Wilson, Daniel Jacobowitz, David Mosberger, gcc H. J. Lu wrote: >On Wed, Apr 21, 2004 at 12:15:16PM -0700, Mark Mitchell wrote: > > >>>While we are on it, binaries compiled by gcc may reference gcc >>>personality functions, which only come with gcc. That means when you >>>mix them with other compilers, you have to do something like >>> >>># icc .... find the right gcc personality functions >>> >>>How can we address this? >>> >>> >>> >>> >>The presonality routines should be either (a) included in the shared >>object or executable, or (b) the shared object or executable should >>have a dependency on a shared object providing that personality routine. >> >> > >It doesn't help when I want to use relocatable object files generated >by gcc with icc. > > The ABI does not cover that case. If you look at the beginning of the ABI document, you'll see that it is designed only to deal with shared objects and executables. There's no guarantee that you can intermix ".o" files, although that may work in some cases. -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: versioning of _Unwind_*() symbols 2004-04-21 0:44 ` Jim Wilson 2004-04-21 1:24 ` Daniel Jacobowitz @ 2004-04-21 1:39 ` H. J. Lu 2004-04-21 6:09 ` PATCH: Put libunwind.a in libgcc_s.so: " H. J. Lu 2 siblings, 0 replies; 69+ messages in thread From: H. J. Lu @ 2004-04-21 1:39 UTC (permalink / raw) To: Jim Wilson; +Cc: David Mosberger, gcc On Tue, Apr 20, 2004 at 05:26:02PM -0700, Jim Wilson wrote: > > What is wrong with putting the symbols back in libgcc_s.so? If you link > with libunwind before libgcc, programs will use the libunwind versions > won't they? > The old binaries don't know about libunwind.so. You can't load it before libgcc_s.so transparently. > Maybe the issue is that system libraries that were linked again libgcc > will still use the libgcc version? That gets us back to the issue I > mentioned before, which is that this is really a system packaging issue, > not a libgcc vesioning issue. If a linux distro ships with libunwind as > a standard package, then everything is OK. If libunwind is an add on > package, then we can't replace the versioned libgcc functions, we can > only replace the internal unversioned functions. It is more complicated than that. The end result is the new libgcc_s.so is not 100% binary compatible with the old libgcc_s.so. There is no easy way to fix it. H.J. ^ permalink raw reply [flat|nested] 69+ messages in thread
* PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols 2004-04-21 0:44 ` Jim Wilson 2004-04-21 1:24 ` Daniel Jacobowitz 2004-04-21 1:39 ` H. J. Lu @ 2004-04-21 6:09 ` H. J. Lu 2004-04-21 6:53 ` David Mosberger ` (2 more replies) 2 siblings, 3 replies; 69+ messages in thread From: H. J. Lu @ 2004-04-21 6:09 UTC (permalink / raw) To: Jim Wilson, gcc-patches; +Cc: David Mosberger, gcc [-- Attachment #1: Type: text/plain, Size: 417 bytes --] On Tue, Apr 20, 2004 at 05:26:02PM -0700, Jim Wilson wrote: > > What is wrong with putting the symbols back in libgcc_s.so? If you link > with libunwind before libgcc, programs will use the libunwind versions > won't they? > This patch puts libunwind.a in libgcc_s.so.1. The test result is at http://gcc.gnu.org/ml/gcc-testresults/2004-04/msg00974.html We can do it on ia64 since PIC is default on ia64. H.J. [-- Attachment #2: gcc-libunwind-3.patch --] [-- Type: text/plain, Size: 1716 bytes --] 2004-04-20 H.J. Lu <hongjiu.lu@intel.com> * config.gcc (ia64*-*-linux*): Use ia64/t-libunwind instead of t-libunwind. * config/ia64/t-libunwind: New file. * config/t-libunwind (LIB2ADDEH): Add $(srcdir)/gthr-gnat.c. --- gcc/config.gcc.libunwind 2004-04-20 20:00:40.000000000 -0700 +++ gcc/config.gcc 2004-04-20 21:26:04.000000000 -0700 @@ -1264,7 +1264,7 @@ ia64*-*-linux*) target_cpu_default="MASK_GNU_AS|MASK_GNU_LD" extra_parts="crtbegin.o crtend.o crtbeginS.o crtendS.o crtfastmath.o" if test x"$use_libunwind_exceptions" = xyes; then - tmake_file="$tmake_file t-libunwind" + tmake_file="$tmake_file ia64/t-libunwind" fi ;; ia64*-*-hpux*) --- gcc/config/ia64/t-libunwind.libunwind 2004-04-20 21:27:56.000000000 -0700 +++ gcc/config/ia64/t-libunwind 2004-04-20 21:32:43.000000000 -0700 @@ -0,0 +1,13 @@ +# Override the default value from t-slibgcc-elf-ver to include +# libunwind.a so that the resulting libgcc_s.so is 100% backward +# compatible. +# FIXME: libunwind.o is a kludge. +LIB2ADDEH = $(srcdir)/unwind-sjlj.c $(srcdir)/unwind-c.c \ + $(srcdir)/gthr-gnat.c libunwind.o + +libunwind.o: $(GCC_PASSES) + $(GCC_FOR_TARGET) -nostdlib -nostartfiles -r -o $@ \ + -Wl,--whole-archive \ + `$(GCC_FOR_TARGET) --print-file-name=libunwind.a` + mkdir -p libgcc + cp $@ libgcc --- gcc/config/t-libunwind.libunwind 2003-12-23 10:02:54.000000000 -0800 +++ gcc/config/t-libunwind 2004-04-20 21:25:51.000000000 -0700 @@ -2,4 +2,5 @@ # so that the resulting libgcc_s.so has the necessary DT_NEEDED entry for # libunwind. SHLIB_LC = -lunwind -lc -LIB2ADDEH = $(srcdir)/unwind-sjlj.c $(srcdir)/unwind-c.c +LIB2ADDEH = $(srcdir)/unwind-sjlj.c $(srcdir)/unwind-c.c \ + $(srcdir)/gthr-gnat.c ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols 2004-04-21 6:09 ` PATCH: Put libunwind.a in libgcc_s.so: " H. J. Lu @ 2004-04-21 6:53 ` David Mosberger 2004-04-21 7:04 ` Jim Wilson 2004-04-21 9:36 ` Arnaud Charlet 2 siblings, 0 replies; 69+ messages in thread From: David Mosberger @ 2004-04-21 6:53 UTC (permalink / raw) To: H. J. Lu; +Cc: Jim Wilson, gcc-patches, David Mosberger, gcc >>>>> On Tue, 20 Apr 2004 22:57:29 -0700, "H. J. Lu" <hjl@lucon.org> said: H> This patch puts libunwind.a in libgcc_s.so.1. The test result is at H> http://gcc.gnu.org/ml/gcc-testresults/2004-04/msg00974.html H> We can do it on ia64 since PIC is default on ia64. I suppose that's progress, but I still think it's wrong for GCC to version symbols that are defined by the C++ ABI. To witness: $ cat t.cxx #include <stdio.h> void foo (void) { char myarray[10]; try { for (int n=0; n<=10; n++) { if (n>9) throw "Out of range"; myarray[n]='z'; } } catch (const char * str) { printf ("Exception: %s\n", str); } } $ cat main.cxx extern void foo (void); int main (int argc, char **argv) { foo (); } $ g++-3.4 -shared -export-dynamic -o t.so t.cxx $ icc main.cxx t.so t.so: undefined reference to `__cxa_begin_catch@CXXABI_1.3' t.so: undefined reference to `__cxa_allocate_exception@CXXABI_1.3' t.so: undefined reference to `_ZTIPKc@CXXABI_1.3' t.so: undefined reference to `__gxx_personality_v0@CXXABI_1.3' t.so: undefined reference to `__cxa_end_catch@CXXABI_1.3' t.so: undefined reference to `__cxa_throw@CXXABI_1.3' Here, icc is the Intel compiler (v8.0). Unless the C++ ABI defines symbols to be versioned with CXXABI_1.3, this just seems wrong to me. BTW: the above compiles and links just fine with g++ v3.3. --david ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols 2004-04-21 6:09 ` PATCH: Put libunwind.a in libgcc_s.so: " H. J. Lu 2004-04-21 6:53 ` David Mosberger @ 2004-04-21 7:04 ` Jim Wilson 2004-04-21 15:10 ` H. J. Lu 2004-04-21 9:36 ` Arnaud Charlet 2 siblings, 1 reply; 69+ messages in thread From: Jim Wilson @ 2004-04-21 7:04 UTC (permalink / raw) To: H. J. Lu; +Cc: gcc-patches, David Mosberger, gcc On Tue, 2004-04-20 at 22:57, H. J. Lu wrote: > This patch puts libunwind.a in libgcc_s.so.1. The test result is at > We can do it on ia64 since PIC is default on ia64. IA-64 code is PIC by default. However, it is not true that static library code and shared library code are the same. There are differences because of the IA-64 ABI, for instance, the rules that say "own" data can be put in the small data section, but what qualifies as "own" data is different for shared libraries and static libraries. This stuff is controlled by the -fpic option. You must use -fpic for all code that goes into a shared library. Note: -fpic has always meant compile this code for shared libraries, this is even true on systems like IA-64 where code is PIC by default. There is no guarantee that code in libunwind.a was compiled with -fpic. I don't see how this can work. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols 2004-04-21 7:04 ` Jim Wilson @ 2004-04-21 15:10 ` H. J. Lu 2004-04-21 16:12 ` David Mosberger 0 siblings, 1 reply; 69+ messages in thread From: H. J. Lu @ 2004-04-21 15:10 UTC (permalink / raw) To: Jim Wilson; +Cc: gcc-patches, David Mosberger, gcc On Tue, Apr 20, 2004 at 11:38:36PM -0700, Jim Wilson wrote: > On Tue, 2004-04-20 at 22:57, H. J. Lu wrote: > > This patch puts libunwind.a in libgcc_s.so.1. The test result is at > > We can do it on ia64 since PIC is default on ia64. > > IA-64 code is PIC by default. However, it is not true that static > library code and shared library code are the same. There are > differences because of the IA-64 ABI, for instance, the rules that say > "own" data can be put in the small data section, but what qualifies as > "own" data is different for shared libraries and static libraries. This > stuff is controlled by the -fpic option. You must use -fpic for all > code that goes into a shared library. Note: -fpic has always meant > compile this code for shared libraries, this is even true on systems > like IA-64 where code is PIC by default. There is no guarantee that > code in libunwind.a was compiled with -fpic. I don't see how this can > work. We can always require to compile the static libunwind library with -fpic. H.J. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols 2004-04-21 15:10 ` H. J. Lu @ 2004-04-21 16:12 ` David Mosberger 2004-04-21 16:44 ` H. J. Lu 0 siblings, 1 reply; 69+ messages in thread From: David Mosberger @ 2004-04-21 16:12 UTC (permalink / raw) To: H. J. Lu; +Cc: Jim Wilson, gcc-patches, David Mosberger, gcc >>>>> On Wed, 21 Apr 2004 07:35:54 -0700, "H. J. Lu" <hjl@lucon.org> said: HJ> On Tue, Apr 20, 2004 at 11:38:36PM -0700, Jim Wilson wrote: >> On Tue, 2004-04-20 at 22:57, H. J. Lu wrote: > This patch puts >> libunwind.a in libgcc_s.so.1. The test result is at > We can do >> it on ia64 since PIC is default on ia64. >> IA-64 code is PIC by default. However, it is not true that >> static library code and shared library code are the same. There >> are differences because of the IA-64 ABI, for instance, the rules >> that say "own" data can be put in the small data section, but >> what qualifies as "own" data is different for shared libraries >> and static libraries. This stuff is controlled by the -fpic >> option. You must use -fpic for all code that goes into a shared >> library. Note: -fpic has always meant compile this code for >> shared libraries, this is even true on systems like IA-64 where >> code is PIC by default. There is no guarantee that code in >> libunwind.a was compiled with -fpic. I don't see how this can >> work. HJ> We can always require to compile the static libunwind library HJ> with -fpic. I really do not think this is the right approach. --david ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols 2004-04-21 16:12 ` David Mosberger @ 2004-04-21 16:44 ` H. J. Lu 2004-04-21 16:49 ` David Mosberger 2004-04-21 20:52 ` Jim Wilson 0 siblings, 2 replies; 69+ messages in thread From: H. J. Lu @ 2004-04-21 16:44 UTC (permalink / raw) To: davidm; +Cc: Jim Wilson, gcc-patches, gcc On Wed, Apr 21, 2004 at 08:22:41AM -0700, David Mosberger wrote: > >>>>> On Wed, 21 Apr 2004 07:35:54 -0700, "H. J. Lu" <hjl@lucon.org> said: > > HJ> On Tue, Apr 20, 2004 at 11:38:36PM -0700, Jim Wilson wrote: > >> On Tue, 2004-04-20 at 22:57, H. J. Lu wrote: > This patch puts > >> libunwind.a in libgcc_s.so.1. The test result is at > We can do > >> it on ia64 since PIC is default on ia64. > > >> IA-64 code is PIC by default. However, it is not true that > >> static library code and shared library code are the same. There > >> are differences because of the IA-64 ABI, for instance, the rules > >> that say "own" data can be put in the small data section, but > >> what qualifies as "own" data is different for shared libraries > >> and static libraries. This stuff is controlled by the -fpic If the small data section is the only difference, we may get lucky with libunwind. > >> option. You must use -fpic for all code that goes into a shared > >> library. Note: -fpic has always meant compile this code for > >> shared libraries, this is even true on systems like IA-64 where > >> code is PIC by default. There is no guarantee that code in > >> libunwind.a was compiled with -fpic. I don't see how this can > >> work. > > HJ> We can always require to compile the static libunwind library > HJ> with -fpic. > > I really do not think this is the right approach. > The ideal solution is to do what Solaris does. That is linker and dynamic linker work together to support moving a definition from one DSO to another, transparently. But it is not an option today. Given that we should provide 100% backward binary compatibility, which was the problem to begin with, our choices are very limited. H.J. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols 2004-04-21 16:44 ` H. J. Lu @ 2004-04-21 16:49 ` David Mosberger 2004-04-21 17:54 ` H. J. Lu 2004-04-21 20:52 ` Jim Wilson 1 sibling, 1 reply; 69+ messages in thread From: David Mosberger @ 2004-04-21 16:49 UTC (permalink / raw) To: H. J. Lu; +Cc: davidm, Jim Wilson, gcc-patches, gcc >>>>> On Wed, 21 Apr 2004 09:34:17 -0700, "H. J. Lu" <hjl@lucon.org> said: HJ> The ideal solution is to do what Solaris does. That is linker HJ> and dynamic linker work together to support moving a definition HJ> from one DSO to another, transparently. But it is not an option HJ> today. HJ> Given that we should provide 100% backward binary compatibility, HJ> which was the problem to begin with, our choices are very HJ> limited. No, the ideal solution is for GCC to be C++ ABI-compliant. --david ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols 2004-04-21 16:49 ` David Mosberger @ 2004-04-21 17:54 ` H. J. Lu 2004-04-21 18:16 ` David Mosberger 0 siblings, 1 reply; 69+ messages in thread From: H. J. Lu @ 2004-04-21 17:54 UTC (permalink / raw) To: davidm; +Cc: Jim Wilson, gcc-patches, gcc On Wed, Apr 21, 2004 at 09:43:55AM -0700, David Mosberger wrote: > >>>>> On Wed, 21 Apr 2004 09:34:17 -0700, "H. J. Lu" <hjl@lucon.org> said: > > HJ> The ideal solution is to do what Solaris does. That is linker > HJ> and dynamic linker work together to support moving a definition > HJ> from one DSO to another, transparently. But it is not an option > HJ> today. > > HJ> Given that we should provide 100% backward binary compatibility, > HJ> which was the problem to begin with, our choices are very > HJ> limited. > > No, the ideal solution is for GCC to be C++ ABI-compliant. > The unwinder in gcc is C++ ABI-compliant. But it doesn't mean you can mix 2 unwind libraries together. As soon as you did # g++ -shared ... you may already have linked part of whatever unwind library gcc is using into the resulting shared library. It won't be easy to use another unwind library after that. The whole problem started many years ago that we wanted to make sure only one unwinder and one copy of its internal data structure are used across executable and shared libraries it uses. The current scheme is mostly OK on other platforms. But ia64 is an exception. Maybe we should take another look at the problem. H.J. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols 2004-04-21 17:54 ` H. J. Lu @ 2004-04-21 18:16 ` David Mosberger 0 siblings, 0 replies; 69+ messages in thread From: David Mosberger @ 2004-04-21 18:16 UTC (permalink / raw) To: H. J. Lu; +Cc: davidm, Jim Wilson, gcc-patches, gcc >>>>> On Wed, 21 Apr 2004 10:13:06 -0700, "H. J. Lu" <hjl@lucon.org> said: HJ> The unwinder in gcc is C++ ABI-compliant. No, it isn't. Not as long as it defines ABI-defined symbols as versioned symbols. That means anything that got linked against libgcc_s will never be able to use the ABI-defined symbols from another library (such as libunwind). >>>>> On Wed, 21 Apr 2004 10:13:06 -0700, "H. J. Lu" <hjl@lucon.org> said: HJ> The unwinder in gcc is C++ ABI-compliant. But it doesn't mean HJ> you can mix 2 unwind libraries together. As soon as you did HJ> # g++ -shared ... HJ> you may already have linked part of whatever unwind library gcc HJ> is using into the resulting shared library. It won't be easy to HJ> use another unwind library after that. Nonsense. LD_PRELOAD=/usr/lib/libunwind.so would do just fine. The problem isn't even libunwind-specific, as my example from yesterday evening showed. --david ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols 2004-04-21 16:44 ` H. J. Lu 2004-04-21 16:49 ` David Mosberger @ 2004-04-21 20:52 ` Jim Wilson 1 sibling, 0 replies; 69+ messages in thread From: Jim Wilson @ 2004-04-21 20:52 UTC (permalink / raw) To: H. J. Lu; +Cc: David Mosberger, gcc-patches, gcc On Wed, 2004-04-21 at 09:34, H. J. Lu wrote: > If the small data section is the only difference, we may get lucky > with libunwind. It isn't the only difference, but it is probably the only one we have to worry about. I am pretty sure that thread local storage (TLS) works differently in a shared library too, but I doubt that affects libunwind. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols 2004-04-21 6:09 ` PATCH: Put libunwind.a in libgcc_s.so: " H. J. Lu 2004-04-21 6:53 ` David Mosberger 2004-04-21 7:04 ` Jim Wilson @ 2004-04-21 9:36 ` Arnaud Charlet 2004-04-21 14:43 ` H. J. Lu 2 siblings, 1 reply; 69+ messages in thread From: Arnaud Charlet @ 2004-04-21 9:36 UTC (permalink / raw) To: H. J. Lu; +Cc: Jim Wilson, gcc-patches, David Mosberger, gcc > * config/t-libunwind (LIB2ADDEH): Add $(srcdir)/gthr-gnat.c. gthr-gnat.c is no longer needed on most platforms, and should be removed rather than added (the only platform where it's still needed is OpenVMS). Arno ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols 2004-04-21 9:36 ` Arnaud Charlet @ 2004-04-21 14:43 ` H. J. Lu 2004-04-21 15:22 ` Arnaud Charlet 2004-04-23 2:46 ` PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols Jim Wilson 0 siblings, 2 replies; 69+ messages in thread From: H. J. Lu @ 2004-04-21 14:43 UTC (permalink / raw) To: Arnaud Charlet; +Cc: Jim Wilson, gcc-patches, David Mosberger, gcc On Wed, Apr 21, 2004 at 09:04:00AM +0200, Arnaud Charlet wrote: > > * config/t-libunwind (LIB2ADDEH): Add $(srcdir)/gthr-gnat.c. > > gthr-gnat.c is no longer needed on most platforms, and should be removed > rather than added (the only platform where it's still needed is OpenVMS). Adding $(srcdir)/gthr-gnat.c seems to fix the Ada test hanging problems. If it isn't needed, you can remove it for ia64 to see if it introduces any problems for ia64. H.J. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols 2004-04-21 14:43 ` H. J. Lu @ 2004-04-21 15:22 ` Arnaud Charlet 2004-04-21 17:11 ` Removing gthr-gnat.c? H. J. Lu 2004-04-23 2:46 ` PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols Jim Wilson 1 sibling, 1 reply; 69+ messages in thread From: Arnaud Charlet @ 2004-04-21 15:22 UTC (permalink / raw) To: H. J. Lu; +Cc: Arnaud Charlet, Jim Wilson, gcc-patches, David Mosberger, gcc > Adding $(srcdir)/gthr-gnat.c seems to fix the Ada test hanging > problems. If it isn't needed, you can remove it for ia64 to see if it I suspect a set up problem on your side. > introduces any problems for ia64. Sure, I simply don't have authority to remove these files without going through a formal patch submission/approval, which is why I've never bothered (up to now) doing it. It's somewhere on my todo list, but very far away... Arno ^ permalink raw reply [flat|nested] 69+ messages in thread
* Removing gthr-gnat.c? 2004-04-21 15:22 ` Arnaud Charlet @ 2004-04-21 17:11 ` H. J. Lu 2004-04-22 8:18 ` Arnaud Charlet 0 siblings, 1 reply; 69+ messages in thread From: H. J. Lu @ 2004-04-21 17:11 UTC (permalink / raw) To: Arnaud Charlet; +Cc: gcc, celier, kenner On Wed, Apr 21, 2004 at 04:43:23PM +0200, Arnaud Charlet wrote: > > Adding $(srcdir)/gthr-gnat.c seems to fix the Ada test hanging > > problems. If it isn't needed, you can remove it for ia64 to see if it > > I suspect a set up problem on your side. > > > introduces any problems for ia64. > > Sure, I simply don't have authority to remove these files without going > through a formal patch submission/approval, which is why I've never > bothered (up to now) doing it. It's somewhere on my todo list, but very > far away... > That is very odd. gthr-gnat.c was added for Linux: http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01720.html Now, you are saying it is not needed. H.J. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Removing gthr-gnat.c? 2004-04-21 17:11 ` Removing gthr-gnat.c? H. J. Lu @ 2004-04-22 8:18 ` Arnaud Charlet 0 siblings, 0 replies; 69+ messages in thread From: Arnaud Charlet @ 2004-04-22 8:18 UTC (permalink / raw) To: H. J. Lu; +Cc: Arnaud Charlet, gcc, celier, kenner > That is very odd. gthr-gnat.c was added for Linux: > > http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01720.html > > Now, you are saying it is not needed. Nothing odd. I am saying that it is *no longer* needed. Arno ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols 2004-04-21 14:43 ` H. J. Lu 2004-04-21 15:22 ` Arnaud Charlet @ 2004-04-23 2:46 ` Jim Wilson 2004-04-23 7:42 ` Arnaud Charlet 1 sibling, 1 reply; 69+ messages in thread From: Jim Wilson @ 2004-04-23 2:46 UTC (permalink / raw) To: H. J. Lu; +Cc: Arnaud Charlet, gcc-patches, David Mosberger, gcc On Wed, 2004-04-21 at 07:33, H. J. Lu wrote: > Adding $(srcdir)/gthr-gnat.c seems to fix the Ada test hanging > problems. If it isn't needed, you can remove it for ia64 to see if it > introduces any problems for ia64. Looking at gthr-gnat.c, I see that it defines a __gnat_install_locks function, and the only use is in gcc/ada/adaint.c inside VMS ifdefs. So apparently this file is not doing anything important for ia64-linux. The question then is what does it do. Well, it defines gthread_mutex_{,un}lock functions that do nothing. If you link with these instead of the pthread versions, then obviously, you will never run into pthread bugs because you aren't calling pthread locking routines. Also, just as obviously, multi-threaded programs that require locking won't work anymore. This seems like a potential problem to me. There is another question of why we don't get link errors when we aren't using gthr-gnat.c. Where do the __gthread_mutex* functions come from in that case? I am puzzled. I haven't tried doing builds and looking at them to see what is going on. On the other hand, gnat-gthr.c is there for apparently all other targets, so it probably should be there, even if it seems to be flawed. At least it means ia64-linux has the same flaw as every other target instead of having a different set of flaws. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols 2004-04-23 2:46 ` PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols Jim Wilson @ 2004-04-23 7:42 ` Arnaud Charlet 2004-04-24 0:41 ` Jim Wilson 0 siblings, 1 reply; 69+ messages in thread From: Arnaud Charlet @ 2004-04-23 7:42 UTC (permalink / raw) To: Jim Wilson; +Cc: H. J. Lu, Arnaud Charlet, gcc-patches, David Mosberger, gcc > Looking at gthr-gnat.c, I see that it defines a __gnat_install_locks > function, and the only use is in gcc/ada/adaint.c inside VMS ifdefs. So > apparently this file is not doing anything important for ia64-linux. gthr-gnat.c is no longer needed at all, except on VMS. > The question then is what does it do. Well, it defines > gthread_mutex_{,un}lock functions that do nothing. If you link with > these instead of the pthread versions, then obviously, you will never > run into pthread bugs because you aren't calling pthread locking > routines. Also, just as obviously, multi-threaded programs that require > locking won't work anymore. This seems like a potential problem to me. No, you missed the fact that gthr-gnat.c is using pointers to functions, and provides a gnat_install_locks, which is called with appropriate locking routines by the GNAT tasking run time when tasking is used. > There is another question of why we don't get link errors when we aren't > using gthr-gnat.c. Where do the __gthread_mutex* functions come from in > that case? I am puzzled. I haven't tried doing builds and looking at > them to see what is going on. Because no file is referencing these symbols. > On the other hand, gnat-gthr.c is there for apparently all other > targets, so it probably should be there, even if it seems to be flawed. No, gthr-gnat.c should only be there at this point for VMS. It would be removed for all other targets, not added. Arno ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols 2004-04-23 7:42 ` Arnaud Charlet @ 2004-04-24 0:41 ` Jim Wilson 2004-04-24 12:12 ` Arnaud Charlet 0 siblings, 1 reply; 69+ messages in thread From: Jim Wilson @ 2004-04-24 0:41 UTC (permalink / raw) To: Arnaud Charlet; +Cc: H. J. Lu, gcc-patches, David Mosberger, gcc I find this message to be very puzzling. The only way I can interpret it is as an insult. However, I am trying to help you by investigating and solving an Ada related problem. You should not be insulting someone who is trying to help you. Maybe there is a language related issue here, or maybe you are venting general frustrations or something, or maybe you don't understand what I am trying to accomplish here. By the way, what I am trying to do here is reconcile differing statements made by you and HJ. Your statements conflict. Repeating the conflicting statements does not solve anything. What we need is to investigate the issues without preconceptions, and without taking sides. That is what I am trying to do. Since, I have mostly confirmed that your statements are correct, I can't understand why you are responding to me this way. On Fri, 2004-04-23 at 00:07, Arnaud Charlet wrote: > gthr-gnat.c is no longer needed at all, except on VMS. I know. You said that in an earlier message, and I agreed with you. So why are restating the obvious? That could be misconstrued as an insult. > No, you missed the fact that gthr-gnat.c is using pointers to functions, You are mistaken. I did not miss this fact. The only way I could have missed this fact is if I was incompetent, and I am not incompetent. If you had asked if maybe possibly I had accidentally missed something obvious, then that would have been OK. I am human, and I do make mistakes. But to state as a fact that I missed something obvious is to make a strong implication that I am incompetent, and hence the only way I can interpret the above statement is as an insult. I am offended by it, and hope that you do not make this mistake again. > Because no file is referencing these symbols. Do you know this for a fact? Or are you making an logical assumption? If you are making a logical assumption, then I would agree with you. However, statements from HJ contradict this. It is possible that there is some obscure subtle interaction that is IA-64 specific and which has gone unnoticed so far. Since I am trying to keep an open mind, I must admit that this is a possibility however remote. It is also possible that HJ made a mistake. The only way to be sure if to perform an experiment. That is what I am doing. Performing an experiment to verify the facts. It is the right thing to do in this case. > No, gthr-gnat.c should only be there at this point for VMS. It would be > removed for all other targets, not added. You are confusing issues here. That gthr-gnat.c should only be there for VMS is true. However, if you look at the sources, you can clearly see that it is there for all targets except ia64-linux. Therefore, we have an obvious problem, because ia64-linux is different from other targets when it should not be. This needs to be investigated. That is what I am doing. Even if it is wrong for ia64-linux to use gthr-gnat.c, it might be necessary to add it to resolve this inconsistency. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols 2004-04-24 0:41 ` Jim Wilson @ 2004-04-24 12:12 ` Arnaud Charlet 2004-04-27 6:31 ` Jim Wilson 0 siblings, 1 reply; 69+ messages in thread From: Arnaud Charlet @ 2004-04-24 12:12 UTC (permalink / raw) To: Jim Wilson; +Cc: Arnaud Charlet, H. J. Lu, gcc-patches, David Mosberger, gcc OK, let's all be constructive as you were in your last message. First of all, I deeply apologize if you felt I was insulting you: I was not and never intended to. Now for some of the details: > > gthr-gnat.c is no longer needed at all, except on VMS. > > I know. You said that in an earlier message, and I agreed with you. So > why are restating the obvious? That could be misconstrued as an insult. It certainly is not. I have no way of knowing whether you indeed saw my earlier message, whether this message was phrased in a way that could be understood as intended by others, etc... You know that you understood my message, I didn't, so I had to assume the default, which is that it doesn't hurt to repeat an information twice (this is what all teachers do btw, and students do not find that their teachers insult them when teachers repeat things twice). > > No, you missed the fact that gthr-gnat.c is using pointers to functions, > > You are mistaken. I did not miss this fact. The only way I could have > missed this fact is if I was incompetent, and I am not incompetent. I certainly did not want to imply that you are incompetent. It's a communication problem: your message as I read it seemed to imply that you had not seen the whole usage of this feature, which even if true would not mean you are incompetent. It would simply mean that you missed it because e.g. you were looking at a part of the code that you are not familiar with (the Ada front-end), and that the code is mixed/used between Ada and C in various places. And also, I was more responding for others than you, since your message itself was a response, and since I understood it differently than you phrased it, other people may have done exactly the same thing. So I believe my clarification and additional information on your statement was helpful to others. I'm sure you can understand that and would agree with that. > I can interpret the above statement is as an insult. I am offended by > it, and hope that you do not make this mistake again. With all your respect, I believe that if you interpret the above statement as an insult, it could be because indeed you know too well that you are competent, and cannot accept remarks/suggestions/help from others as openly as someone less competent (or simply someone not as focused on the fact that he is competent). You also seemed to miss the fact that not everyone knows you personally and not everyone knows your level of knowledge and knows that you read all messages on this list and always interpret them as initially intended. On my side, I agree that I should not have assumed anything, and phrase my answer differently. This would probably have avoided this whole discussion. I'll try to remember that in the future and be more careful in my answers. Now, starting to know better your personality, there are some chances (and hopefully I will be proven wrong) that you take the above paragraphs as an insult: it's not, I'm trying to be helpful and help you realize that there are many ways to communicate and state things, and that on a public list with people coming from different background, it's impossible to know everyone and to respond to everyone with exactly the phrasing that will make them understand what you meant to say. And even if it were possible, other people may still misinterpret some statements. This thread is a very good example: you did not use the right phrasing to allow me to understand what you were saying (although your phrasing was certainly obvious to you), and I did not use the right phrasing to answer to you either. > > Because no file is referencing these symbols. > Do you know this for a fact? Or are you making an logical assumption? > If you are making a logical assumption, then I would agree with you. > However, statements from HJ contradict this. It is possible that there It's more than a logical assumption. If the code were indeed referenced, we would get undefined references when linking. > is some obscure subtle interaction that is IA-64 specific and which has > gone unnoticed so far. Since I am trying to keep an open mind, I must > admit that this is a possibility however remote. It is also possible Right, it could be. So I'd suggest the following experiment: remove all traces of gthr-gnat.c in the GCC sources in a local copy and see whether you get some undefined references and some changes in behavior. If removing all traces still allows you to link, then it indeed proves that this file is not needed. BTW, the above suggestion was 'obvious' to me after my previous messages, and I assumed that others (e.g. you) would do/understand it without having to explicitely state it. Clearly, that was either a mistake on my part (assuming other people would have the same way of reasoning than myself), or indeed you understood that from my previous messages as I assumed it, and since you didn't state it explicitely, I decided to make it explicit. Following your reasoning, if indeed you already understood and maybe made the above experiment, you might also find 'insulting' that I made this suggestion explicit, since it was 'obvious' to you what I had in mind, because you are <choose your word here: competent, etc...>. All right, back to technical matters, and waiting to see the result of the above experiment if anyone finds it's a helpful suggestion and has the time to do it. Arno ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols 2004-04-24 12:12 ` Arnaud Charlet @ 2004-04-27 6:31 ` Jim Wilson 2004-04-27 10:24 ` Arnaud Charlet 0 siblings, 1 reply; 69+ messages in thread From: Jim Wilson @ 2004-04-27 6:31 UTC (permalink / raw) To: Arnaud Charlet; +Cc: H. J. Lu, gcc-patches, David Mosberger, gcc On Sat, 2004-04-24 at 04:24, Arnaud Charlet wrote: > Now for some of the details: Thanks for the info. It was helpful. I misunderstood the intent of your earlier message. I did a build over the weekend to try to reproduce HJ's result and came up empty. Adding gthr-gnat.c to LIB2ADDEH had no effect on the ia64-linux Ada testsuite results, which is what I expected from my analysis and from your analysis. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols 2004-04-27 6:31 ` Jim Wilson @ 2004-04-27 10:24 ` Arnaud Charlet 0 siblings, 0 replies; 69+ messages in thread From: Arnaud Charlet @ 2004-04-27 10:24 UTC (permalink / raw) To: Jim Wilson; +Cc: Arnaud Charlet, H. J. Lu, gcc-patches, David Mosberger, gcc > Thanks for the info. It was helpful. I misunderstood the intent of > your earlier message. No problem. I know my messages are usually a little bit too much 'to the point' and sometimes lack additional info/context. I'll try to improve that in the future. > I did a build over the weekend to try to reproduce HJ's result and came > up empty. Adding gthr-gnat.c to LIB2ADDEH had no effect on the > ia64-linux Ada testsuite results, which is what I expected from my > analysis and from your analysis. OK, that confirms indeed the analysis made so far. Now, we would need to find what in HJ's set up is different. Like, what configure options are used, what bootstrap options are used, what sources, and whether there are local changes in his tree. Arno ^ permalink raw reply [flat|nested] 69+ messages in thread
end of thread, other threads:[~2004-04-27 8:36 UTC | newest] Thread overview: 69+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-04-19 18:48 versioning of _Unwind_*() symbols David Mosberger 2004-04-20 23:21 ` Jim Wilson 2004-04-20 23:28 ` David Mosberger 2004-04-21 0:25 ` Jim Wilson 2004-04-20 23:41 ` H. J. Lu 2004-04-20 23:51 ` David Mosberger 2004-04-20 23:52 ` H. J. Lu 2004-04-21 0:19 ` David Mosberger 2004-04-21 0:44 ` Jim Wilson 2004-04-21 1:24 ` Daniel Jacobowitz 2004-04-21 1:46 ` Jim Wilson 2004-04-21 2:09 ` David Mosberger 2004-04-21 4:44 ` Daniel Jacobowitz 2004-04-21 2:21 ` Gabriel Dos Reis 2004-04-21 18:26 ` Mark Mitchell 2004-04-21 19:17 ` H. J. Lu 2004-04-21 19:20 ` Mark Mitchell 2004-04-21 19:34 ` Daniel Jacobowitz 2004-04-21 20:05 ` Mark Mitchell 2004-04-21 20:18 ` H. J. Lu 2004-04-21 21:13 ` Mark Mitchell 2004-04-21 21:13 ` H. J. Lu 2004-04-21 21:22 ` Mark Mitchell 2004-04-21 21:43 ` H. J. Lu 2004-04-22 15:47 ` H. J. Lu 2004-04-22 17:07 ` Mark Mitchell 2004-04-22 17:22 ` H. J. Lu 2004-04-22 17:28 ` Mark Mitchell 2004-04-22 17:29 ` H. J. Lu 2004-04-22 17:46 ` Mark Mitchell 2004-04-22 17:59 ` H. J. Lu 2004-04-22 18:07 ` Mark Mitchell 2004-04-22 18:54 ` H. J. Lu 2004-04-22 21:48 ` Mark Mitchell 2004-04-22 23:03 ` H. J. Lu 2004-04-22 23:15 ` David Mosberger 2004-04-22 23:34 ` H. J. Lu 2004-04-22 23:36 ` David Mosberger 2004-04-23 1:15 ` H. J. Lu 2004-04-22 23:50 ` Daniel Jacobowitz 2004-04-22 23:59 ` David Mosberger 2004-04-23 1:37 ` H. J. Lu 2004-04-23 2:30 ` David Mosberger 2004-04-22 19:22 ` David Mosberger 2004-04-22 21:39 ` Mark Mitchell 2004-04-21 19:36 ` H. J. Lu 2004-04-21 20:18 ` Mark Mitchell 2004-04-21 1:39 ` H. J. Lu 2004-04-21 6:09 ` PATCH: Put libunwind.a in libgcc_s.so: " H. J. Lu 2004-04-21 6:53 ` David Mosberger 2004-04-21 7:04 ` Jim Wilson 2004-04-21 15:10 ` H. J. Lu 2004-04-21 16:12 ` David Mosberger 2004-04-21 16:44 ` H. J. Lu 2004-04-21 16:49 ` David Mosberger 2004-04-21 17:54 ` H. J. Lu 2004-04-21 18:16 ` David Mosberger 2004-04-21 20:52 ` Jim Wilson 2004-04-21 9:36 ` Arnaud Charlet 2004-04-21 14:43 ` H. J. Lu 2004-04-21 15:22 ` Arnaud Charlet 2004-04-21 17:11 ` Removing gthr-gnat.c? H. J. Lu 2004-04-22 8:18 ` Arnaud Charlet 2004-04-23 2:46 ` PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols Jim Wilson 2004-04-23 7:42 ` Arnaud Charlet 2004-04-24 0:41 ` Jim Wilson 2004-04-24 12:12 ` Arnaud Charlet 2004-04-27 6:31 ` Jim Wilson 2004-04-27 10:24 ` Arnaud Charlet
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).