This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: Demangler update?
- To: ian at zembu dot com
- Subject: Re: Demangler update?
- From: "Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>
- Date: Fri, 14 Apr 2000 08:24:39 +0200
- CC: block at zk3 dot dec dot com, gcc at gcc dot gnu dot org, binutils at sourceware dot cygnus dot com
- References: <38F66841.69D39C24@zk3.dec.com> <20000414005441.1096.qmail@daffy.airs.com>
> 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