* Demangler update? @ 2000-04-13 17:38 Ken Block USG 2000-04-13 18:09 ` Ian Lance Taylor 0 siblings, 1 reply; 22+ messages in thread From: Ken Block USG @ 2000-04-13 17:38 UTC (permalink / raw) To: gcc, binutils H.J. submitted this patch for the demangler a while back and it has not been checked in. The patch provides: 1) support for GNAT ada compiler. 2) adds a --style switch to a number of tools to allow them to specify which demangler to be used. 3) It adds the ability to dynamic load a demangler that is shipped independently. Compaq C++ depends on this patch. What needs to be done to get this demangler patch checked in? If I redid this patch against the latest snapshot and broke it down into smaller pieces, would somebody be willing to check it in? http://gcc.gnu.org/ml/gcc-patches/1999-10n/msg00258.html ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Demangler update? 2000-04-13 17:38 Demangler update? Ken Block USG @ 2000-04-13 18:09 ` Ian Lance Taylor 2000-04-13 23:32 ` Martin v. Loewis 2000-04-14 9:09 ` Ken Block USG 0 siblings, 2 replies; 22+ messages in thread From: Ian Lance Taylor @ 2000-04-13 18:09 UTC (permalink / raw) To: block; +Cc: gcc, binutils Date: Thu, 13 Apr 2000 20:37:22 -0400 From: Ken Block USG <block@zk3.dec.com> H.J. submitted this patch for the demangler a while back and it has not been checked in. The patch provides: 1) support for GNAT ada compiler. 2) adds a --style switch to a number of tools to allow them to specify which demangler to be used. 3) It adds the ability to dynamic load a demangler that is shipped independently. Compaq C++ depends on this patch. What needs to be done to get this demangler patch checked in? If I redid this patch against the latest snapshot and broke it down into smaller pieces, would somebody be willing to check it in? http://gcc.gnu.org/ml/gcc-patches/1999-10n/msg00258.html First let me say that I think that the gcc/g++ maintainers are responsible for the changes to libiberty. I encourage them to evaluate this patch and work to get some version of it checked in. I am not a gcc/g++ maintainer myself. For myself, I think this patch definitely needs work. I also think it would help a lot to break it down, since there are several things mixed into it. The most problematical aspect to it is the dynamic loading support, which is probably what you care about. I'm personally not convinced that dynamic loading support is necessary at all. It seems like the wrong approach. Rather than requiring dynamic loading, we should follow the Unix way: use a small program. It should be possible to write any demangler to filter the input stream, as c++filt does. Then demangling symbols is simply a matter of running them through a program. pipe/fork/exec is a standard fully portable Unix paradigm. Dynamic loading adds no special capabilities here. If we are going to add dynamic loading, then it must be documented. It must not be specific to GNU/Linux. Special cases for compaq should not be required, and should be completely eliminated from the code. It makes no sense to introduce a brand new interface which permits more flexibility in demangling and then make it inflexible. The style name should somehow automatically translate into the shared library to use. Other than the dynamic linking, I think it should be possible to get most of this patch checked in. Ian ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Demangler update? 2000-04-13 18:09 ` Ian Lance Taylor @ 2000-04-13 23:32 ` Martin v. Loewis 2000-04-14 9:45 ` Ken Block USG 2000-04-14 9:52 ` Ian Lance Taylor 2000-04-14 9:09 ` Ken Block USG 1 sibling, 2 replies; 22+ messages in thread From: Martin v. Loewis @ 2000-04-13 23:32 UTC (permalink / raw) To: ian; +Cc: block, gcc, binutils > I'm personally not convinced that dynamic loading support is necessary > at all. It seems like the wrong approach. Rather than requiring > dynamic loading, we should follow the Unix way: use a small program. > It should be possible to write any demangler to filter the input > stream, as c++filt does. Then demangling symbols is simply a matter > of running them through a program. pipe/fork/exec is a standard fully > portable Unix paradigm. Dynamic loading adds no special capabilities > here. I'd take that a step further: Why is it that external extensibility is needed at all? AFAICT, the rationale is to allow binutils, in particular GNU ld, to demangle Compaq C++ symbols. At least, that's how I understood >> Compaq C++ depends on this patch. Putting my Free Software hat on, I think this is not a good idea at all. Why couldn't binutils support the Compaq C++ mangling directly, just as it understands the HP aCC mangling? To me, this sounds like Compaq does not want to share the algorithm for demangling. Why should binutils support their C++ compiler, then? Having a better selection of the demangling algorithm to chose, and perhaps allowing simpler integration of other algorithms (on a source code) level is a different matter - I'm all for it. Regards, Martin ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Demangler update? 2000-04-13 23:32 ` Martin v. Loewis @ 2000-04-14 9:45 ` Ken Block USG 2000-04-14 14:11 ` Martin v. Loewis 2000-04-14 9:52 ` Ian Lance Taylor 1 sibling, 1 reply; 22+ messages in thread From: Ken Block USG @ 2000-04-14 9:45 UTC (permalink / raw) To: Martin v. Loewis; +Cc: ian, gcc, binutils "Martin v. Loewis" wrote: > >> Compaq C++ depends on this patch. > > Putting my Free Software hat on, I think this is not a good idea at > all. Why couldn't binutils support the Compaq C++ mangling directly, > just as it understands the HP aCC mangling? > > To me, this sounds like Compaq does not want to share the algorithm > for demangling. Why should binutils support their C++ compiler, then? > > Having a better selection of the demangling algorithm to chose, and > perhaps allowing simpler integration of other algorithms (on a source > code) level is a different matter - I'm all for it. > > Regards, > Martin Compaq is more than happy to share our demangler algorithms. It is my belief that the code is very complicated and not particularly well written or robust and it would not serve anybody's interest to have it added to libibierty. I suspect that even if we did open source it, the maintainers would reject it. Furthermore, there is a work in progress to try and develop an object model that will allow Compaq C++ and G++ to be link compatible. When this is achieved, our demangler goes into the garbage. I've talked to my manangement and they have agreed to let me publish our sources under the understanding that we still are retaining the copyright and they cannot be redistributed. Look at the code, if the maintainers of libiberty like the code and want to incorrporate it into libiberty, then I will begin the process to get the sources released. This process will require getting a VP, the legal department, and twhichever is harder Griffen in accounting or the mythical beast to sign off, but I will do it, if that is what it will take to get support for Compaq C++ in binutils. The sources are now available and for the next 48 hours at: ftp://xfer.americas.digital.com/to_customer/demangler.tar.gz After 48 hours, it will be available at http://gnv.sourceforge.net/downloads/demangler.tar.gz . We can address the architectual/implement objections seperately from the philosophical ones. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Demangler update? 2000-04-14 9:45 ` Ken Block USG @ 2000-04-14 14:11 ` Martin v. Loewis 0 siblings, 0 replies; 22+ messages in thread From: Martin v. Loewis @ 2000-04-14 14:11 UTC (permalink / raw) To: block; +Cc: ian, gcc, binutils > It is my belief that the code is very complicated and not > particularly well written or robust and it would not serve anybody's > interest to have it added to libibierty. Code in -liberty is of varying quality, usefulness, and authorship. So I guess your code would fit in very well :-) > I suspect that even if we did open source it, the maintainers would > reject it. I took a glance at the code. It is quite a lot of code, but it appears to be self-contained. I'm not in charge of binutils, but I could not see technical obstacles with integrating it into binutils. If it is useful to users of the GNU binutils, and does not harm if not used, what could be the problem - apart from licensing? As more mangling schemes are supported, maybe liberty is the wrong place for collecting them. Perhaps it is time for a GNU demangler library? Regards, Martin ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Demangler update? 2000-04-13 23:32 ` Martin v. Loewis 2000-04-14 9:45 ` Ken Block USG @ 2000-04-14 9:52 ` Ian Lance Taylor 2000-04-14 10:00 ` H . J . Lu 1 sibling, 1 reply; 22+ messages in thread From: Ian Lance Taylor @ 2000-04-14 9:52 UTC (permalink / raw) To: martin; +Cc: block, gcc, binutils Date: Fri, 14 Apr 2000 08:24:39 +0200 From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de> > I'm personally not convinced that dynamic loading support is necessary > at all. It seems like the wrong approach. Rather than requiring > dynamic loading, we should follow the Unix way: use a small program. > It should be possible to write any demangler to filter the input > stream, as c++filt does. Then demangling symbols is simply a matter > of running them through a program. pipe/fork/exec is a standard fully > portable Unix paradigm. Dynamic loading adds no special capabilities > here. I'd take that a step further: Why is it that external extensibility is needed at all? There is a reasonable argument for external extensibility. The mangling scheme does change over time, and it can change with each release of the compiler. In practice new manglings seem to get added pretty often. The binutils and gcc are not released in synch. If you have a new compiler, an older binutils may well be unable to demangle the names generated by the new compiler. The fix is to have the compiler provide a demangling program (it already does, in fact) and to have the binutils simply use it. >> Compaq C++ depends on this patch. Putting my Free Software hat on, I think this is not a good idea at all. Why couldn't binutils support the Compaq C++ mangling directly, just as it understands the HP aCC mangling? To me, this sounds like Compaq does not want to share the algorithm for demangling. Why should binutils support their C++ compiler, then? I agree. This is an issue which Compaq ought to address somehow. Having a better selection of the demangling algorithm to chose, and perhaps allowing simpler integration of other algorithms (on a source code) level is a different matter - I'm all for it. I agree. Ian ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Demangler update? 2000-04-14 9:52 ` Ian Lance Taylor @ 2000-04-14 10:00 ` H . J . Lu 2000-04-14 10:05 ` Ian Lance Taylor 2000-04-14 13:47 ` Martin v. Loewis 0 siblings, 2 replies; 22+ messages in thread From: H . J . Lu @ 2000-04-14 10:00 UTC (permalink / raw) To: block, gcc, binutils, martin On Fri, Apr 14, 2000 at 09:07:38AM -0700, Ian Lance Taylor wrote: > > The mangling scheme does change over time, and it can change with each > release of the compiler. In practice new manglings seem to get added > pretty often. > > The binutils and gcc are not released in synch. If you have a new > compiler, an older binutils may well be unable to demangle the names > generated by the new compiler. > > The fix is to have the compiler provide a demangling program (it > already does, in fact) and to have the binutils simply use it. > As I have pointed out before, it may not work every well with more than one version/release of C++ compilers, depending on how c++filt is installed. When you type "c++filt", you may not get the "c++filt" you want. c++filt should be installed just like cc1plus and invoked by g++/c++ only. However, it still doesn't solve the problem for gdb and binutils. H.J. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Demangler update? 2000-04-14 10:00 ` H . J . Lu @ 2000-04-14 10:05 ` Ian Lance Taylor 2000-04-14 10:20 ` H . J . Lu 2000-04-14 13:47 ` Martin v. Loewis 1 sibling, 1 reply; 22+ messages in thread From: Ian Lance Taylor @ 2000-04-14 10:05 UTC (permalink / raw) To: hjl; +Cc: block, gcc, binutils, martin Date: Fri, 14 Apr 2000 10:00:35 -0700 From: "H . J . Lu" <hjl@lucon.org> On Fri, Apr 14, 2000 at 09:07:38AM -0700, Ian Lance Taylor wrote: > The mangling scheme does change over time, and it can change with each > release of the compiler. In practice new manglings seem to get added > pretty often. > > The binutils and gcc are not released in synch. If you have a new > compiler, an older binutils may well be unable to demangle the names > generated by the new compiler. > > The fix is to have the compiler provide a demangling program (it > already does, in fact) and to have the binutils simply use it. As I have pointed out before, it may not work every well with more than one version/release of C++ compilers, depending on how c++filt is installed. When you type "c++filt", you may not get the "c++filt" you want. c++filt should be installed just like cc1plus and invoked by g++/c++ only. However, it still doesn't solve the problem for gdb and binutils. We have to face that problem somehow. Dynamic loading doesn't solve it either. To put it another way, if we can solve the problem with dynamic loading, then we can solve it with an external program. In any case, we only need to fully solve the 90% case, in which there is only one compiler around, while retaining enough flexibility to handle unusual cases such as the one you describe. Ian ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Demangler update? 2000-04-14 10:05 ` Ian Lance Taylor @ 2000-04-14 10:20 ` H . J . Lu 2000-04-14 10:32 ` Ian Lance Taylor 0 siblings, 1 reply; 22+ messages in thread From: H . J . Lu @ 2000-04-14 10:20 UTC (permalink / raw) To: block, gcc, binutils, martin On Fri, Apr 14, 2000 at 10:04:31AM -0700, Ian Lance Taylor wrote: > Date: Fri, 14 Apr 2000 10:00:35 -0700 > From: "H . J . Lu" <hjl@lucon.org> > > On Fri, Apr 14, 2000 at 09:07:38AM -0700, Ian Lance Taylor wrote: > > > The mangling scheme does change over time, and it can change with each > > release of the compiler. In practice new manglings seem to get added > > pretty often. > > > > The binutils and gcc are not released in synch. If you have a new > > compiler, an older binutils may well be unable to demangle the names > > generated by the new compiler. > > > > The fix is to have the compiler provide a demangling program (it > > already does, in fact) and to have the binutils simply use it. > > As I have pointed out before, it may not work every well with > more than one version/release of C++ compilers, depending > on how c++filt is installed. When you type "c++filt", you may > not get the "c++filt" you want. c++filt should be installed just > like cc1plus and invoked by g++/c++ only. However, it still > doesn't solve the problem for gdb and binutils. > > We have to face that problem somehow. Dynamic loading doesn't solve > it either. > > To put it another way, if we can solve the problem with dynamic > loading, then we can solve it with an external program. > > In any case, we only need to fully solve the 90% case, in which there > is only one compiler around, while retaining enough flexibility to > handle unusual cases such as the one you describe. I don't think my case is that unusual. As of today, on my Linux box, there are C++ binaries linked with 4 different versions of libstdc++, compiled with 4 different versions of g++. I prefer DSO over external program because it is small and has much less overhead. It is just my personal opinion. H.J. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Demangler update? 2000-04-14 10:20 ` H . J . Lu @ 2000-04-14 10:32 ` Ian Lance Taylor 2000-04-14 10:46 ` David Starner ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Ian Lance Taylor @ 2000-04-14 10:32 UTC (permalink / raw) To: hjl; +Cc: block, gcc, binutils, martin Date: Fri, 14 Apr 2000 10:20:46 -0700 From: "H . J . Lu" <hjl@lucon.org> > In any case, we only need to fully solve the 90% case, in which there > is only one compiler around, while retaining enough flexibility to > handle unusual cases such as the one you describe. I don't think my case is that unusual. As of today, on my Linux box, there are C++ binaries linked with 4 different versions of libstdc++, compiled with 4 different versions of g++. I hope you aren't trying to argue that you are a typical user. I believe that most developers use one compiler which they rarely change. I prefer DSO over external program because it is small and has much less overhead. It is just my personal opinion. But we walk smack into portability issues. gcc and the binutils work on dozens of systems. What's the point of a solution which only works on some, or, the way you wrote it, exactly one? I know that you mainly, or perhaps exclusively, care about GNU/Linux, but you know that the GNU maintainers care about many more systems. Providing a solution which solves a general problem in a way which only works on GNU/Linux is not acceptable. You know that. I personally have no objection to dynamic loading being an option, provided that it is clearly documented, and that all it takes to add a new demangling option is to drop a new shared object into some directory. Ian ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Demangler update? 2000-04-14 10:32 ` Ian Lance Taylor @ 2000-04-14 10:46 ` David Starner 2000-04-14 10:49 ` Ken Block USG 2000-04-14 11:03 ` H . J . Lu 2 siblings, 0 replies; 22+ messages in thread From: David Starner @ 2000-04-14 10:46 UTC (permalink / raw) To: gcc, binutils, hjl On Fri, Apr 14, 2000 at 10:31:18AM -0700, Ian Lance Taylor wrote: > Date: Fri, 14 Apr 2000 10:20:46 -0700 > From: "H . J . Lu" <hjl@lucon.org> > > > In any case, we only need to fully solve the 90% case, in which there > > is only one compiler around, while retaining enough flexibility to > > handle unusual cases such as the one you describe. > > I don't think my case is that unusual. As of today, on my Linux > box, there are C++ binaries linked with 4 different versions > of libstdc++, compiled with 4 different versions of g++. > > I hope you aren't trying to argue that you are a typical user. I > believe that most developers use one compiler which they rarely > change. Debian Potato will ship with three versions of libstdc++ (libstdc++2.8, libstdc++2.9-glibc2.1, libstdc++2.10) and four versions of libg++ (libg++2.8, libg++27, libg++2.8.1.3, libg++2.8.2-glibc2.1). I have all three versions of libstdc++ around. -- David Starner - dstarner98@aasaa.ofe.org Only a nerd would worry about wrong parentheses with square brackets. But that's what mathematicians are. -- Dr. Burchard, math professor at OSU ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Demangler update? 2000-04-14 10:32 ` Ian Lance Taylor 2000-04-14 10:46 ` David Starner @ 2000-04-14 10:49 ` Ken Block USG 2000-04-14 10:56 ` Ian Lance Taylor 2000-04-14 11:03 ` H . J . Lu 2 siblings, 1 reply; 22+ messages in thread From: Ken Block USG @ 2000-04-14 10:49 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: hjl, gcc, binutils, martin Ian Lance Taylor wrote: > Date: Fri, 14 Apr 2000 10:20:46 -0700 > From: "H . J . Lu" <hjl@lucon.org> > > > In any case, we only need to fully solve the 90% case, in which there > > is only one compiler around, while retaining enough flexibility to > > handle unusual cases such as the one you describe. > > I don't think my case is that unusual. As of today, on my Linux > box, there are C++ binaries linked with 4 different versions > of libstdc++, compiled with 4 different versions of g++. > > I hope you aren't trying to argue that you are a typical user. I > believe that most developers use one compiler which they rarely > change. > > I prefer DSO over external program because it is small and > has much less overhead. It is just my personal opinion. > > But we walk smack into portability issues. gcc and the binutils work > on dozens of systems. What's the point of a solution which only works > on some, or, the way you wrote it, exactly one? > > I know that you mainly, or perhaps exclusively, care about GNU/Linux, > but you know that the GNU maintainers care about many more systems. > Providing a solution which solves a general problem in a way which > only works on GNU/Linux is not acceptable. You know that. > > I personally have no objection to dynamic loading being an option, > provided that it is clearly documented, and that all it takes to add a > new demangling option is to drop a new shared object into some > directory. > > Ian If you want to implement both, I can, but I'm not sure how well an external program will work inside of gdb or similar programs. So what do you do, open a pipe for the input and the output of the filter, write the symbol you want to demangle, and then read it back from the other end of the pipe. Do we run the program each time we want to demangle a symbol or do we leave a demangler process active for the duratation? If you run a new program for each symbol, I think you are going to definitely have efficiency problems. If you leave the program active for the duration, will you have a caching problem? If you write the symbol into the filter, when will it come out the other end? It will definitely come out the other end when you close the pipe and I'd assume it would come out the other end when you flush, but the standard c++filter would not do that. Once again efficiency seems questionable. Also, I don't see how using dlopen is specific to Linux. It will work on any platform that supports dlopen from within binaries that are dynamically linked. That would even include Tru64, Linux, and even VMS. What platforms would it not support and is it a requirement to support all platforms or just as many as we can? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Demangler update? 2000-04-14 10:49 ` Ken Block USG @ 2000-04-14 10:56 ` Ian Lance Taylor 2000-04-14 11:12 ` Ken Block USG 2000-04-14 11:22 ` Theodore Papadopoulo 0 siblings, 2 replies; 22+ messages in thread From: Ian Lance Taylor @ 2000-04-14 10:56 UTC (permalink / raw) To: block; +Cc: hjl, gcc, binutils, martin Date: Fri, 14 Apr 2000 13:48:29 -0400 From: Ken Block USG <block@zk3.dec.com> So what do you do, open a pipe for the input and the output of the filter, write the symbol you want to demangle, and then read it back from the other end of the pipe. That is what I would imagine. Do we run the program each time we want to demangle a symbol or do we leave a demangler process active for the duratation? I would think we would leave the process around. If you run a new program for each symbol, I think you are going to definitely have efficiency problems. If you leave the program active for the duration, will you have a caching problem? If you write the symbol into the filter, when will it come out the other end? It will definitely come out the other end when you close the pipe and I'd assume it would come out the other end when you flush, but the standard c++filter would not do that. Once again efficiency seems questionable. The standard filter in libiberty/cplus-dem.c already flushes its output after every symbol. The calling program would have to flush after each symbol it writes, which is easy. Also, I don't see how using dlopen is specific to Linux. It will work on any platform that supports dlopen from within binaries that are dynamically linked. That would even include Tru64, Linux, and even VMS. What platforms would it not support and is it a requirement to support all platforms or just as many as we can? Using dlopen is not specific to GNU/Linux. HJ's patch is specific to GNU/Linux, because it has #ifdef linux in it. Using dlopen is a portability hassle, because even on systems which support it you sometimes have to link against -ldl or perhaps other libraries. Not all systems have shared libraries, and of those not all support dlopen. gcc and the binutils work on a lot of systems. Ian ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Demangler update? 2000-04-14 10:56 ` Ian Lance Taylor @ 2000-04-14 11:12 ` Ken Block USG 2000-04-14 11:22 ` Theodore Papadopoulo 1 sibling, 0 replies; 22+ messages in thread From: Ken Block USG @ 2000-04-14 11:12 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: hjl, gcc, binutils, martin Ian Lance Taylor wrote: > Date: Fri, 14 Apr 2000 13:48:29 -0400 > From: Ken Block USG <block@zk3.dec.com> > > So what do you do, open a pipe for the input and the output of the > filter, write the symbol you want to demangle, and then read it back > from the other end of the pipe. > > That is what I would imagine. > > Do we run the program each time we want > to demangle a symbol or do we leave a demangler process active for > the duratation? > > I would think we would leave the process around. > > If you run a new program for each symbol, I think you are going to > definitely have efficiency problems. If you leave the program active > for the duration, will you have a caching problem? If you write the > symbol into the filter, when will it come out the other end? It will > definitely come out the other end when you close the pipe and I'd > assume it would come out the other end when you flush, but the > standard c++filter would not do that. Once again efficiency seems > questionable. > > The standard filter in libiberty/cplus-dem.c already flushes its > output after every symbol. The calling program would have to flush > after each symbol it writes, which is easy. > > Also, I don't see how using dlopen is specific to Linux. It will work > on any platform that supports dlopen from within binaries that are > dynamically linked. That would even include Tru64, Linux, and > even VMS. What platforms would it not support and is it a > requirement to support all platforms or just as many as we can? > > Using dlopen is not specific to GNU/Linux. HJ's patch is specific to > GNU/Linux, because it has #ifdef linux in it. > > Using dlopen is a portability hassle, because even on systems which > support it you sometimes have to link against -ldl or perhaps other > libraries. Not all systems have shared libraries, and of those not > all support dlopen. gcc and the binutils work on a lot of systems. > > Ian OK, I'll look into providing patches to implement it both ways and see which ones get accepted. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Demangler update? 2000-04-14 10:56 ` Ian Lance Taylor 2000-04-14 11:12 ` Ken Block USG @ 2000-04-14 11:22 ` Theodore Papadopoulo 2000-04-14 11:32 ` Ian Lance Taylor 1 sibling, 1 reply; 22+ messages in thread From: Theodore Papadopoulo @ 2000-04-14 11:22 UTC (permalink / raw) To: hjl, gcc, binutils, martin, block ian@zembu.com said: > Using dlopen is a portability hassle, because even on systems which > support it you sometimes have to link against -ldl or perhaps other > libraries. Not all systems have shared libraries, and of those not > all support dlopen. gcc and the binutils work on a lot of systems. Isn't libtool supposed do deal with this for us ??? Theo. -------------------------------------------------------------------- Theodore Papadopoulo Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01 -------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Demangler update? 2000-04-14 11:22 ` Theodore Papadopoulo @ 2000-04-14 11:32 ` Ian Lance Taylor 2000-04-14 11:48 ` Alexandre Oliva 0 siblings, 1 reply; 22+ messages in thread From: Ian Lance Taylor @ 2000-04-14 11:32 UTC (permalink / raw) To: Theodore.Papadopoulo; +Cc: hjl, gcc, binutils, martin, block Date: Fri, 14 Apr 2000 20:22:01 +0200 From: Theodore Papadopoulo <Theodore.Papadopoulo@sophia.inria.fr> ian@zembu.com said: > Using dlopen is a portability hassle, because even on systems which > support it you sometimes have to link against -ldl or perhaps other > libraries. Not all systems have shared libraries, and of those not > all support dlopen. gcc and the binutils work on a lot of systems. Isn't libtool supposed do deal with this for us ??? This might well be a solution. I don't know the details about the libtool dlopen support. I don't know whether it works on systems which do not support shared libraries at all. Note that libiberty does not currently use libtool, and that as far as I know the libtool dlopen support is not yet released. Also, libiberty is compiled in a limited cross configuration to provide supporting functions for libstdc++. Rather than cope with this, it might be easier to lift any dynamic loading support out of libiberty. Ian ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Demangler update? 2000-04-14 11:32 ` Ian Lance Taylor @ 2000-04-14 11:48 ` Alexandre Oliva 0 siblings, 0 replies; 22+ messages in thread From: Alexandre Oliva @ 2000-04-14 11:48 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Theodore.Papadopoulo, hjl, gcc, binutils, martin, block [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1070 bytes --] On Apr 14, 2000, Ian Lance Taylor <ian@zembu.com> wrote: > This might well be a solution. I don't know the details about the > libtool dlopen support. I don't know whether it works on systems > which do not support shared libraries at all. It does. But then, the benefit of simplifying upgrades H.J. wanted can't be accomplished. Using separate executables is the only way to accomplish that. At least, before libtool's libltdl (its portable dlopening library) gains a self-relinking&re-exec()ing mechanism that could be used to overcome the inability to dlopen() libraries. > Note that libiberty does not currently use libtool, and that as far as > I know the libtool dlopen support is not yet released. It has been available since release 1.3.0 (the latest is 1.3.4) -- Alexandre Oliva Enjoy Guaraná, see http://www.ic.unicamp.br/~oliva/ Cygnus Solutions, a Red Hat company aoliva@{redhat, cygnus}.com Free Software Developer and Evangelist CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Demangler update? 2000-04-14 10:32 ` Ian Lance Taylor 2000-04-14 10:46 ` David Starner 2000-04-14 10:49 ` Ken Block USG @ 2000-04-14 11:03 ` H . J . Lu 2000-04-14 11:13 ` Ian Lance Taylor 2000-04-14 13:48 ` Martin v. Loewis 2 siblings, 2 replies; 22+ messages in thread From: H . J . Lu @ 2000-04-14 11:03 UTC (permalink / raw) To: block, gcc, binutils, martin On Fri, Apr 14, 2000 at 10:31:18AM -0700, Ian Lance Taylor wrote: > Date: Fri, 14 Apr 2000 10:20:46 -0700 > From: "H . J . Lu" <hjl@lucon.org> > > > In any case, we only need to fully solve the 90% case, in which there > > is only one compiler around, while retaining enough flexibility to > > handle unusual cases such as the one you describe. > > I don't think my case is that unusual. As of today, on my Linux > box, there are C++ binaries linked with 4 different versions > of libstdc++, compiled with 4 different versions of g++. > > I hope you aren't trying to argue that you are a typical user. I > believe that most developers use one compiler which they rarely > change. > 3 out of 4 different versions of shared libstdc++ are provided by Red Hat 6.2. They are parts of the libstdc++ 2.9.0-30 rpm. You can say most if not all Red Hat users have similar installations like me. H.J. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Demangler update? 2000-04-14 11:03 ` H . J . Lu @ 2000-04-14 11:13 ` Ian Lance Taylor 2000-04-14 13:48 ` Martin v. Loewis 1 sibling, 0 replies; 22+ messages in thread From: Ian Lance Taylor @ 2000-04-14 11:13 UTC (permalink / raw) To: hjl; +Cc: block, gcc, binutils, martin Date: Fri, 14 Apr 2000 11:03:22 -0700 From: "H . J . Lu" <hjl@lucon.org> > > In any case, we only need to fully solve the 90% case, in which there > > is only one compiler around, while retaining enough flexibility to > > handle unusual cases such as the one you describe. > > I don't think my case is that unusual. As of today, on my Linux > box, there are C++ binaries linked with 4 different versions > of libstdc++, compiled with 4 different versions of g++. > > I hope you aren't trying to argue that you are a typical user. I > believe that most developers use one compiler which they rarely > change. 3 out of 4 different versions of shared libstdc++ are provided by Red Hat 6.2. They are parts of the libstdc++ 2.9.0-30 rpm. You can say most if not all Red Hat users have similar installations like me. Despite this, I believe my statement is correct as it stands. But this is completely irrelevant, and I'm not going to comment further on it. Obviously if somebody can solve the whole problem, then we should implement that. Arguing about whether we need to solve the whole problem is pointless. Since you think we do, go ahead and solve it. It remains the case that if we can solve the whole problem with shared libraries, then we can solve it with an external program. The suggested solutions are no different in this regard. Ian ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Demangler update? 2000-04-14 11:03 ` H . J . Lu 2000-04-14 11:13 ` Ian Lance Taylor @ 2000-04-14 13:48 ` Martin v. Loewis 1 sibling, 0 replies; 22+ messages in thread From: Martin v. Loewis @ 2000-04-14 13:48 UTC (permalink / raw) To: hjl; +Cc: block, gcc, binutils > 3 out of 4 different versions of shared libstdc++ are provided > by Red Hat 6.2. They are parts of the libstdc++ 2.9.0-30 rpm. You > can say most if not all Red Hat users have similar installations > like me. We are getting off-topic here, but I think a single demangler works for all those C++ compiler versions that you have installed. The only minor problem I'm aware of is that array bounds mangling may differ. Regards, Martin ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Demangler update? 2000-04-14 10:00 ` H . J . Lu 2000-04-14 10:05 ` Ian Lance Taylor @ 2000-04-14 13:47 ` Martin v. Loewis 1 sibling, 0 replies; 22+ messages in thread From: Martin v. Loewis @ 2000-04-14 13:47 UTC (permalink / raw) To: hjl; +Cc: block, gcc, binutils > As I have pointed out before, it may not work every well with > more than one version/release of C++ compilers, depending > on how c++filt is installed. When you type "c++filt", you may > not get the "c++filt" you want. c++filt should be installed just > like cc1plus and invoked by g++/c++ only. However, it still > doesn't solve the problem for gdb and binutils. I agree. If the solution is to invoke c++filt, that could be invoked just as well by the g++ driver, or collect2, or even by the user - there is no need for libiberty creating new processes. Adding new demanglers to -liberty is the right thing, IMO. However, I dislike dynamic loading of them - this is an additional step that can fail. You cannot easily move ld or gdb binaries around as you currently can. The political issues of such extensibility are also a strong reason for me to dislike it. Regards, Martin ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Demangler update? 2000-04-13 18:09 ` Ian Lance Taylor 2000-04-13 23:32 ` Martin v. Loewis @ 2000-04-14 9:09 ` Ken Block USG 1 sibling, 0 replies; 22+ messages in thread From: Ken Block USG @ 2000-04-14 9:09 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: gcc, binutils Ian Lance Taylor wrote: > For myself, I think this patch definitely needs work. I also think it > would help a lot to break it down, since there are several things > mixed into it. > > The most problematical aspect to it is the dynamic loading support, > which is probably what you care about. I will break the patch down and let people reject the dynamic loading piece since it seems to be raising the most red flags. Atleast we could minimize the divergance between the sourceware binutils and the linux binutils. I'll try to address the issues for the dynamic loading patch seperately. ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2000-04-14 14:11 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-04-13 17:38 Demangler update? Ken Block USG 2000-04-13 18:09 ` Ian Lance Taylor 2000-04-13 23:32 ` Martin v. Loewis 2000-04-14 9:45 ` Ken Block USG 2000-04-14 14:11 ` Martin v. Loewis 2000-04-14 9:52 ` Ian Lance Taylor 2000-04-14 10:00 ` H . J . Lu 2000-04-14 10:05 ` Ian Lance Taylor 2000-04-14 10:20 ` H . J . Lu 2000-04-14 10:32 ` Ian Lance Taylor 2000-04-14 10:46 ` David Starner 2000-04-14 10:49 ` Ken Block USG 2000-04-14 10:56 ` Ian Lance Taylor 2000-04-14 11:12 ` Ken Block USG 2000-04-14 11:22 ` Theodore Papadopoulo 2000-04-14 11:32 ` Ian Lance Taylor 2000-04-14 11:48 ` Alexandre Oliva 2000-04-14 11:03 ` H . J . Lu 2000-04-14 11:13 ` Ian Lance Taylor 2000-04-14 13:48 ` Martin v. Loewis 2000-04-14 13:47 ` Martin v. Loewis 2000-04-14 9:09 ` Ken Block USG
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).