FYI: A new C++ demangler

FYI: A new C++ demangler

[H. J. Lu]

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

I will put a new C++ demangler in Linux binutils, which should fix all
known bugs in the old demangler. It is written in C++. It will be
enabled only if there is a working C++ compiler. Otherwise, the old
demangler will be used.

I am enclosing the patch here in case someone is interested.


H.J.

[-- Attachment #2: demangler-11.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 26123 bytes --]

Re: FYI: A new C++ demangler

[Ian Lance Taylor]

"H. J. Lu" <hjl@lucon.org> writes:

> I will put a new C++ demangler in Linux binutils, which should fix all
> known bugs in the old demangler. It is written in C++. It will be
> enabled only if there is a working C++ compiler. Otherwise, the old
> demangler will be used.

Are you coordinating with the g++ developers?

If not, this seems like a pointless exercise.

Ian

Re: FYI: A new C++ demangler

[H. J. Lu]

On Thu, Jul 10, 2003 at 07:39:53AM -0700, Ian Lance Taylor wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
> 
> > I will put a new C++ demangler in Linux binutils, which should fix all
> > known bugs in the old demangler. It is written in C++. It will be
> > enabled only if there is a working C++ compiler. Otherwise, the old
> > demangler will be used.
> 
> Are you coordinating with the g++ developers?
> 

I guess you didn't follow the gcc mailing list very much. The short
story is I can't get it into libiberty. I tried several months without
much success. Libiberty doesn't want a C++ demangler written in C++
and I have no interest in fixing the old one.

BTW, the new C++ demangler is 100% compatible with the old one. I have
been using it for months.


H.J.

Re: FYI: A new C++ demangler

[David Carlton]

On Thu, 10 Jul 2003 07:35:57 -0700, "H. J. Lu" <hjl@lucon.org> said:

> I will put a new C++ demangler in Linux binutils, which should fix all
> known bugs in the old demangler.

Just to clarify: is the output of the new demangler exactly the same
as the output of the old demangler in all cases where the old
demangler is correct?  Because if the new demangler does go into the
mainline libiberty, GDB will care about the details of its output.

David Carlton
carlton@kealia.com

Re: FYI: A new C++ demangler

[H. J. Lu]

On Thu, Jul 10, 2003 at 08:28:30AM -0700, David Carlton wrote:
> On Thu, 10 Jul 2003 07:35:57 -0700, "H. J. Lu" <hjl@lucon.org> said:
> 
> > I will put a new C++ demangler in Linux binutils, which should fix all
> > known bugs in the old demangler.
> 
> Just to clarify: is the output of the new demangler exactly the same
> as the output of the old demangler in all cases where the old
> demangler is correct?  Because if the new demangler does go into the
> mainline libiberty, GDB will care about the details of its output.

There is a demangler testsuite in libiberty and I added a few new
tests which are failed with the old demangler. The new demangler
passed all of them. I assume the outputs must be the same.

BTW, I am not sure when/if the new demangler will show up in mainline
libiberty. That is why I am putting it in my Linux binutils. People
can also apply it to their own gdb source to get a better demangler.


H.J.

Re: FYI: A new C++ demangler

[David Carlton]

On Thu, 10 Jul 2003 08:36:09 -0700, "H. J. Lu" <hjl@lucon.org> said:
> On Thu, Jul 10, 2003 at 08:28:30AM -0700, David Carlton wrote:

>> Just to clarify: is the output of the new demangler exactly the same
>> as the output of the old demangler in all cases where the old
>> demangler is correct?  Because if the new demangler does go into the
>> mainline libiberty, GDB will care about the details of its output.

> There is a demangler testsuite in libiberty and I added a few new
> tests which are failed with the old demangler. The new demangler
> passed all of them. I assume the outputs must be the same.

Fair enough; those tests look reasonable to me.

> BTW, I am not sure when/if the new demangler will show up in
> mainline libiberty.

Yeah, I've been following that thread.  Sigh.

David Carlton
carlton@kealia.com

Re: FYI: A new C++ demangler

[Mark Kettenis]

"H. J. Lu" <hjl@lucon.org> writes:

> I will put a new C++ demangler in Linux binutils, which should fix all
> known bugs in the old demangler. It is written in C++. It will be
> enabled only if there is a working C++ compiler. Otherwise, the old
> demangler will be used.

Having read the discussion on the GCC mailing list, I am convinced it
is undesirable to have two demanglers that have overlapping
functionaility for GDB, especially if the demangler is selected based
on the build environment as you propose.

GDB should be buildable by a ISO C90 compiler, so we can't use C++ for
any of its "standard" parts.

I could live with making the demangler "optional", and removing the
old demangler completely.  But only if the new demangler is a major
improvement over the old one (which I can't judge).

Could someone fix the old demangler, or write a new one in
plain C (or re-write the C++ one in C)?  Pretty please?

Mark

Re: FYI: A new C++ demangler

[Andrew Cagney]

> "H. J. Lu" <hjl@lucon.org> writes:
> 
> 
>> I will put a new C++ demangler in Linux binutils, which should fix all
>> known bugs in the old demangler. It is written in C++. It will be
>> enabled only if there is a working C++ compiler. Otherwise, the old
>> demangler will be used.
> 
> 
> Having read the discussion on the GCC mailing list, I am convinced it
> is undesirable to have two demanglers that have overlapping
> functionaility for GDB, especially if the demangler is selected based
> on the build environment as you propose.
> 
> GDB should be buildable by a ISO C90 compiler, so we can't use C++ for
> any of its "standard" parts.
> 
> I could live with making the demangler "optional", and removing the
> old demangler completely.  But only if the new demangler is a major
> improvement over the old one (which I can't judge).

GDB can't :-(

> Could someone fix the old demangler, or write a new one in
> plain C (or re-write the C++ one in C)?  Pretty please?

Yes.   There's no reason for the underlying demangler algorithm to be 
implemented in vanila ISO C 90, and then wrap it for the C++ side.

HJ, as a start why not separate out and submit these new tests you 
refered to?  Knowing what's broken is a good starting point.

Andrew

Re: FYI: A new C++ demangler

[DJ Delorie]

> Could someone fix the old demangler, or write a new one in
> plain C (or re-write the C++ one in C)?  Pretty please?

I'm working on fixing the old one at the moment.

Re: FYI: A new C++ demangler

[H. J. Lu]

On Thu, Jul 10, 2003 at 05:17:54PM -0400, Andrew Cagney wrote:
> 
> HJ, as a start why not separate out and submit these new tests you 
> refered to?  Knowing what's broken is a good starting point.
> 

http://sources.redhat.com/ml/binutils/2003-06/msg00804.html


H.J.

Re: FYI: A new C++ demangler

[Frank Ch. Eigler]

cagney wrote:

> [...]
> > Could someone fix the old demangler, or write a new one in
> > plain C (or re-write the C++ one in C)?  Pretty please?
> 
> Yes.  There's no reason for the underlying demangler algorithm to be
> implemented in vanila ISO C 90, and then wrap it for the C++ side.
> [...]

You might be accused of dogmatic monolingualism if you don't accept
the notion that some such code may be more naturally expressed in a
higher level language -- that could be one such reason.  Another
reason of course is the fact that it is already done and working:
rewriting costs new effort.

(Note that I'm not asserting that the former reason applies strongly
here; libstdc++-v3/include/bits/demangle.h for example doesn't seem to
rely much on the C++ language's extra capabilities.)

- FChE

Re: FYI: A new C++ demangler

[Andrew Cagney]

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

> cagney wrote:
> 
> 
>> [...]
> 
>> > Could someone fix the old demangler, or write a new one in
>> > plain C (or re-write the C++ one in C)?  Pretty please?
> 
>> 
>> Yes.  There's no reason for the underlying demangler algorithm to be
>> implemented in vanila ISO C 90, and then wrap it for the C++ side.
>> [...]
> 
> 
> You might be accused of dogmatic monolingualism if you don't accept
> the notion that some such code may be more naturally expressed in a
> higher level language -- that could be one such reason.  Another
> reason of course is the fact that it is already done and working:
> rewriting costs new effort.

High level language?  I guess that rules out C++ then :-)

> (Note that I'm not asserting that the former reason applies strongly
> here; libstdc++-v3/include/bits/demangle.h for example doesn't seem to
> rely much on the C++ language's extra capabilities.)

That was my, and I'm guessing Marks, point.

Andrew


[-- Attachment #2: mailbox-message://ac131313@movemail/fsf/gdb/misc#1138377 --]
[-- Type: message/rfc822, Size: 2991 bytes --]

From: fche@redhat.com (Frank Ch. Eigler)
To: Andrew Cagney <cagney@redhat.com>
Cc: Mark Kettenis <kettenis@chello.nl>, "H. J. Lu" <hjl@lucon.org>, binutils@sources.redhat.com, GDB <gdb@sources.redhat.com>
Subject: Re: FYI: A new C++ demangler
Date: 10 Jul 2003 18:58:28 -0400
Message-ID: <o5znjmhtuz.fsf@toenail.toronto.redhat.com>


cagney wrote:

> [...]
> > Could someone fix the old demangler, or write a new one in
> > plain C (or re-write the C++ one in C)?  Pretty please?
> 
> Yes.  There's no reason for the underlying demangler algorithm to be
> implemented in vanila ISO C 90, and then wrap it for the C++ side.
> [...]

You might be accused of dogmatic monolingualism if you don't accept
the notion that some such code may be more naturally expressed in a
higher level language -- that could be one such reason.  Another
reason of course is the fact that it is already done and working:
rewriting costs new effort.

(Note that I'm not asserting that the former reason applies strongly
here; libstdc++-v3/include/bits/demangle.h for example doesn't seem to
rely much on the C++ language's extra capabilities.)

- FChE

Re: FYI: A new C++ demangler

[Nathanael Nerode]

Alexandre Oliva wrote:
> On Jul 15, 2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
>>Yes.  Apparently Nathanael doesn't seem to understand that C++
>>can be used productively for system programming.
No, I understand that.  Why do people keep missing the point?  Let me 
try again.

Adding the C++ demangler to libiberty adds a new build requirement, C++, 
to anything which uses libiberty.  DJ, the libiberty maintainer, has 
said that this is not OK with him because it does not satisfy the goals 
of libiberty.

HJ's plan of having two versions of libiberty, one with the 'new' 
demangler and one with the 'old' demangler, selected magically at 
build-time, is a very, very bad idea because it's confusing.  I don't 
care whether they're link-compatible; it still means two versions of 
libiberty pretending to be the same version.  It's designed to cause 
confusion and untraceable bug reports.

Or if the demangler is outside libiberty, it means GDB (and anything 
else using the new demangler) requires C++ to build, which is again 
*fine with me*.  But apparently it's *not* acceptable to the GDB people. 
  Go talk to them about whether "C++ can be used productively for system 
programming", if you like.

> I don't think the issue is about using C++ for system programming.
> The issue is about having to force every user of libiberty to start
> linking programs that link with libiberty using $(CXX) instead of just
> $(CC).  This would be a very incompatible and, IMHO, undesirable
> change.
It's not just linking, it's building as well.  See above.

If adding C++ as a build requirement is considered acceptable by all the 
projects using libiberty (which includes stuff outside gcc/src), then 
the C++ demangler can be put in libiberty.

If adding C++ as a build requirement is considered acceptable by all the 
projects in gcc/src which want the new demangler, then the C++ demangler 
can be put in as a separate directory.

If adding C++ as a build requirement is *not* considered acceptable by 
any *one* of them, we can't.  It's as simple as that, and it's nothing 
to do with me.  Feel free to convince the projects in GCC and SRC that 
they want to add C++ as a build requirement.

The only thing I am *personally* strongly against is the stupid scheme 
for silently building different versions of libiberty (or, indeed, GDB 
or binutils) under the same name depending on the build environment.  I 
even said that multiple versions would be fine by me if they were 
controlled by an explicit option, rather than implicit characteristics 
of the build environment.

--Nathanael

Re: FYI: A new C++ demangler

[Ian Lance Taylor]

"H. J. Lu" <hjl@lucon.org> writes:

> The demangler configure makes sure the resulting .o is 100% binary
> compatible with $(CC) before enabling the new demangler. You have
> nothing to lose if you don't have a "working" C++ compiler.

Except, of course, a fully functional demangler.

Ian

Re: FYI: A new C++ demangler

[Alexandre Oliva]

On Jul 15, 2003, "H. J. Lu" <hjl@lucon.org> wrote:

> The demangler configure makes sure the resulting .o is 100% binary
> compatible with $(CC) before enabling the new demangler. You have
> nothing to lose if you don't have a "working" C++ compiler.

I see.  This sounds much better.  Thanks for the explanation.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: FYI: A new C++ demangler

[H. J. Lu]

On Tue, Jul 15, 2003 at 07:29:54PM -0300, Alexandre Oliva wrote:
> On Jul 15, 2003, "H. J. Lu" <hjl@lucon.org> wrote:
> 
> > The demangler configure tests if $(CC) can be used for linking.
> 
> For linking the demangler code into an application?

Yes.

> 
> > I hope when the new features are added to gcc, there is an option to
> > disable it if needed.
> 
> What part of `other C++ compilers' do I need to explain further? :-)
> 

The demangler configure makes sure the resulting .o is 100% binary
compatible with $(CC) before enabling the new demangler. You have
nothing to lose if you don't have a "working" C++ compiler.


H.J.

Re: FYI: A new C++ demangler

[Alexandre Oliva]

On Jul 15, 2003, "H. J. Lu" <hjl@lucon.org> wrote:

> The demangler configure tests if $(CC) can be used for linking.

For linking the demangler code into an application?

> I hope when the new features are added to gcc, there is an option to
> disable it if needed.

What part of `other C++ compilers' do I need to explain further? :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: FYI: A new C++ demangler

[DJ Delorie]

> Also, who exactly is demanding to continue a broken implementation?

It's not that we're demanding that we use a broken implementation.
It's just that, so far, HJ's "new" implementation hasn't been
acceptable to replace libiberty's current one, and nobody has fixed
libiberty's implementation.

> It really can not be all that difficult to fix the current demangler.

Actually, the bug is a bit more fundamental that you'd think - it has
to do with qualifiers on class method pointers, at least.  But as I
mentioned before, I'm working on it.

Re: FYI: A new C++ demangler

[H. J. Lu]

On Tue, Jul 15, 2003 at 04:49:07PM -0300, Alexandre Oliva wrote:
> On Jul 15, 2003, "H. J. Lu" <hjl@lucon.org> wrote:
> 
> > FWIW, my C++ demangler patch needs $(CXX) to compile, only $(CC) to
> > link.
> 
> This may be the case with the current GCC, but other C++ compilers,
> and future versions of GCC (especially after we introduce support for
> `export'ed templates) may very well introduce dependencies on their
> run-time libraries, requiring linking with them and possibly even
> using their C++ compiler driver to link.

The demangler configure tests if $(CC) can be used for linking. If not,
the new C++ demangler won't be used. The new C++ demangler is compiled
with -fno-rtti -fno-exceptions for libiberty. I hope when the new
features are added to gcc, there is an option to disable it if needed.


H.J.

Re: FYI: A new C++ demangler

[Alexandre Oliva]

On Jul 15, 2003, "H. J. Lu" <hjl@lucon.org> wrote:

> FWIW, my C++ demangler patch needs $(CXX) to compile, only $(CC) to
> link.

This may be the case with the current GCC, but other C++ compilers,
and future versions of GCC (especially after we introduce support for
`export'ed templates) may very well introduce dependencies on their
run-time libraries, requiring linking with them and possibly even
using their C++ compiler driver to link.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: FYI: A new C++ demangler

[H. J. Lu]

On Tue, Jul 15, 2003 at 12:16:07PM -0700, Ian Lance Taylor wrote:
> It really can not be all that difficult to fix the current demangler.
> 

No one has fixd it yet. All I want is a working C++ demangler. I don't
care if it is written in Fortran.


H.J.

Re: FYI: A new C++ demangler

[Ian Lance Taylor]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> Nathanael Nerode <neroden@twcny.rr.com> wrote
> | > We *don't* want to add such a build requirement for GCC or binutils,
> | > for very good reasons (a lot of systems don't ship with a C++
> | > compiler).  HJ keeps proposing a *completely* demented idea, which
> | > is that the new demangler will be used if a C++ compiler happens to
> | > be lying around during build, and otherwise the broken demangler
> | > will be used.  I wish he'd see what's wrong with that picture.
> 
> I think the completely  demented idea is insisting that "lot of
> systems don't ship with a C++ compiler" and continuing to demande to
> continue a broken implementation. 

But the GNU binutils are intended to be widely portable, and on some
systems the GNU binutils are required in order to build g++, and some
systems really don't ship with a C++ compiler.

If we want to rewrite the GNU binutils in C++, that would be a
reasonable discussion, and in fact C++ would bring a number of
advantages.  But it makes no sense to try to sneak a C++ requirement
in by the back door.

Also, who exactly is demanding to continue a broken implementation?
It really can not be all that difficult to fix the current demangler.

Ian

Re: FYI: A new C++ demangler

[H. J. Lu]

On Tue, Jul 15, 2003 at 04:03:39PM -0300, Alexandre Oliva wrote:
> On Jul 15, 2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> 
> > I think the completely  demented idea is insisting that "lot of
> > systems don't ship with a C++ compiler" and continuing to demande to
> > continue a broken implementation. 
> 
> > Andrew Cagney <ac131313@redhat.com> wrote:
> > | However, there is the SIM directory .....
> 
> > Yes.  Apparently Nathanael doesn't seem to understand that C++
> > can be used productively for system programming.
> 
> I don't think the issue is about using C++ for system programming.
> The issue is about having to force every user of libiberty to start
> linking programs that link with libiberty using $(CXX) instead of just
> $(CC).  This would be a very incompatible and, IMHO, undesirable
> change.

FWIW, my C++ demangler patch needs $(CXX) to compile, only $(CC) to
link. As far as the libiberty user is concerned, the only difference
is the working C++ demangler.


H.J.

Re: FYI: A new C++ demangler

[Alexandre Oliva]

On Jul 15, 2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:

> I think the completely  demented idea is insisting that "lot of
> systems don't ship with a C++ compiler" and continuing to demande to
> continue a broken implementation. 

> Andrew Cagney <ac131313@redhat.com> wrote:
> | However, there is the SIM directory .....

> Yes.  Apparently Nathanael doesn't seem to understand that C++
> can be used productively for system programming.

I don't think the issue is about using C++ for system programming.
The issue is about having to force every user of libiberty to start
linking programs that link with libiberty using $(CXX) instead of just
$(CC).  This would be a very incompatible and, IMHO, undesirable
change.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: FYI: A new C++ demangler

[Gabriel Dos Reis]

Nathanael Nerode <neroden@twcny.rr.com> wrote
| > We *don't* want to add such a build requirement for GCC or binutils,
| > for very good reasons (a lot of systems don't ship with a C++
| > compiler).  HJ keeps proposing a *completely* demented idea, which
| > is that the new demangler will be used if a C++ compiler happens to
| > be lying around during build, and otherwise the broken demangler
| > will be used.  I wish he'd see what's wrong with that picture.

I think the completely  demented idea is insisting that "lot of
systems don't ship with a C++ compiler" and continuing to demande to
continue a broken implementation. 

Andrew Cagney <ac131313@redhat.com> wrote:
| However, there is the SIM directory .....

Yes.  Apparently Nathanael doesn't seem to understand that C++
can be used productively for system programming.

-- Gaby

Re: FYI: A new C++ demangler

[Andrew Cagney]

> Frank Eigler said:
> 
>>You might be accused of dogmatic monolingualism if you don't accept
>>the notion that some such code may be more naturally expressed in a
>>higher level language -- that could be one such reason.  Another
>>reason of course is the fact that it is already done and working:
>>rewriting costs new effort.
> 
> 
> Look, if you want to *add a build requirement* to GDB, so that it 
> *requires* a C++ compiler to build, then then new C++ demangler will
> be fine for GDB.

Fortunatly, that won't happen :-)

> We *don't* want to add such a build requirement for GCC or binutils, for 
> very good reasons (a lot of systems don't ship with a C++ compiler).  HJ 
> keeps proposing a *completely* demented idea, which is that 
> the new demangler will be used if a C++ compiler happens to be lying 
> around during build, and otherwise the broken demangler will be used.  I 
> wish he'd see what's wrong with that picture.

However, there is the SIM directory .....

Andrew

Re: FYI: A new C++ demangler

[Nathanael Nerode]

Frank Eigler said:
>You might be accused of dogmatic monolingualism if you don't accept
>the notion that some such code may be more naturally expressed in a
>higher level language -- that could be one such reason.  Another
>reason of course is the fact that it is already done and working:
>rewriting costs new effort.

Look, if you want to *add a build requirement* to GDB, so that it 
*requires* a C++ compiler to build, then then new C++ demangler will
be fine for GDB.

We *don't* want to add such a build requirement for GCC or binutils, for 
very good reasons (a lot of systems don't ship with a C++ compiler).  HJ 
keeps proposing a *completely* demented idea, which is that 
the new demangler will be used if a C++ compiler happens to be lying 
around during build, and otherwise the broken demangler will be used.  I 
wish he'd see what's wrong with that picture.

-- 
Nathanael Nerode  <neroden at gcc.gnu.org>
http://home.twcny.rr.com/nerode/neroden/fdl.html

Re: FYI: A new C++ demangler

[Michael Elizabeth Chastain]

Summary: no regressions in the gdb test suite.  One change detected
that's a slight improvement.

I know this is moot because gdb can't use code implemented in C++,
but I thought it would be interesting to run the test anyways.

I tested this with the usual:

  target     => native
  host       => i686-pc-linux-gnu
  osversion  => red-hat-8.0
  gdb        => HEAD%20030708
  gcc        => 2.95.3, 3.2-7-rh, 3.3, gcc-3_3-branch%20030707, HEAD%20030707
  binutils   => 2.13.90.0.2-rh, 2.14, binutils-2_14-branch%20030707, HEAD%20030707
  glibc      => 2.2.93-5-rh
  gformat    => dwarf-2, stabs+
  glevel     => 2

All the gcc v2 results were unchanged (obviously, since gdb still uses the
same v2 demangler).

The gcc v3 results were the same for all versions of gcc v3,
binutils, and gformat.  There were three places where something like
this happened:

  # old
  print &'dm_type_unsigned_int'
  $6 = (int (*)(unsigned int)) 0x8048940 <dm_type_unsigned_int(unsigned)>
  (gdb) PASS: gdb.c++/cplusfuncs.exp: detect dm_type_unsigned_int

  # new
  print &'dm_type_unsigned_int'
  $6 = (int (*)(unsigned int)) 0x8048940 <dm_type_unsigned_int(unsigned int)>
  (gdb) PASS: gdb.c++/cplusfuncs.exp: detect dm_type_unsigned_int

That is, the old demangler prints 'unsigned' in some places, and the new
demangler prints 'unsigned int'.  This happened once in
gdb.c++/cplusfuncs.exp and twice in gdb.c++/templates.exp.

Michael C

Re: FYI: A new C++ demangler

[Michael Elizabeth Chastain]

Andrew C writes:
> HJ, as a start why not separate out and submit these new tests you 
> refered to?  Knowing what's broken is a good starting point.

That part is already committed.  The libiberty test suite has 64 new
tests.  The current demangler fails 31 of the new tests.  I saw this in
my test bed and wrote it up.  Check out the "Libiberty Testing" section
near the top of:

  http://sources.redhat.com/ml/gdb-testers/2003-q3/msg00003.html

To me, the issue of what languages are acceptable for implementing the
demangler is separate from the issue of how the new demangler behaves
versus the old demangler.  I can say something about the second issue.
I see that the new demangler does perfectly on all the new tests in
libiberty, and I'm running gdb tests now.  I'll have more info to report
in a couple of hours.

Michael C

Re: FYI: A new C++ demangler

[Ian Lance Taylor]

Michael Elizabeth Chastain <mec@shout.net> writes:

> I have kind of a silly question.  Do I need to rebuild binutils and/or gcc
> with the new demangler, or can I just rebuild gdb?  That is, do gcc or
> binutils ever need to run the demangler while compiling?

Some of the binutils are linked against the demangler.  This doesn't
matter for compilation, only for error reporting and for the output of
objdump and nm.  I don't know whether this matters for your test bed.

Ian

Re: FYI: A new C++ demangler

[H. J. Lu]

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

On Thu, Jul 10, 2003 at 11:42:55AM -0400, Michael Elizabeth Chastain wrote:
> I will throw the new demangler on my gdb test bed and look for regressions.
> I'm sure H. J. has the demangler test suite covered and I can do the
> gdb test suite.
> 
> I have kind of a silly question.  Do I need to rebuild binutils and/or gcc
> with the new demangler, or can I just rebuild gdb?  That is, do gcc or
> binutils ever need to run the demangler while compiling?

You only need to rebuild gdb with it unless you need to use c++filt,
which is the part of binutils.

I am enclosing 2 files. README is used to apply my patch and recreate
those generated files. I also included a correct patch for binutils/gdb
since now the toplevel directories are different between binutils/gdb
and gcc.


H.J.

[-- Attachment #2: README --]
[-- Type: text/plain, Size: 349 bytes --]

#! /bin/sh

dir=`dirname $0`

patch -p1 -b --suffix .demangler < $dir/src-demangler-11.patch && \
true
[ $? = 0 ] || exit 1
(cd demangler && sh ./bootstrap)
[ $? = 0 ] || exit 1
(cd libiberty && rm -f configure && autoconf-2.13)
[ $? = 0 ] || exit 1
rm -f configure && autoconf-2.13 && rm -f Makefile.in && autogen Makefile.def
[ $? = 0 ] || exit 1

[-- Attachment #3: src-demangler-11.patch.gz.bz2 --]
[-- Type: application/x-bzip2, Size: 29324 bytes --]

Re: FYI: A new C++ demangler

[Michael Elizabeth Chastain]

I will throw the new demangler on my gdb test bed and look for regressions.
I'm sure H. J. has the demangler test suite covered and I can do the
gdb test suite.

I have kind of a silly question.  Do I need to rebuild binutils and/or gcc
with the new demangler, or can I just rebuild gdb?  That is, do gcc or
binutils ever need to run the demangler while compiling?

Regarding the controversy about adding a demangler written in C++,
I am neutral about that.  I'll just provide gdb test results.

Michael C