Forgot to note

Forgot to note

[Daniel Berlin]

When the C++ abi moves to the new-abi, I can't fix stabs support
without either adding a whole bunch of cruft, or making it not support
the old ABI.

This is because things like gdb_mangle_name have to be changed to
handle the new mangling scheme.
So I have to either detect whether we have old-abi or new-abi
somewhere, and then add a whole bunch of "if gnu-new-abi" type
statements, or stop supporting the old abi for stabs/C++.

Currently, the consensus on gcc seems to be that linux should move to
dwarf2 before 3.0 releases, which would mean that stopping support for
new-abi/stabs would also be an option.

DWARF2 will work fine with either ABI automatically.

What should we do?
Not support new-abi/stabs?
Not support old-abi/stabs?
Support both? (this is a not insignificant amount of work).

--Dan

Re: Forgot to note

[Kevin Buettner]

[ gdb@sources.redhat.com added to the Cc list. ]

On Oct 10,  8:38pm, Daniel Berlin wrote:

> When the C++ abi moves to the new-abi, I can't fix stabs support
> without either adding a whole bunch of cruft, or making it not support
> the old ABI.
> 
> This is because things like gdb_mangle_name have to be changed to
> handle the new mangling scheme.
> So I have to either detect whether we have old-abi or new-abi
> somewhere, and then add a whole bunch of "if gnu-new-abi" type
> statements, or stop supporting the old abi for stabs/C++.
> 
> Currently, the consensus on gcc seems to be that linux should move to
> dwarf2 before 3.0 releases, which would mean that stopping support for
> new-abi/stabs would also be an option.
> 
> DWARF2 will work fine with either ABI automatically.
> 
> What should we do?
> Not support new-abi/stabs?
> Not support old-abi/stabs?
> Support both? (this is a not insignificant amount of work).

I think we'll need to support both for a period of time.

Here are the reasons:

 1) GDB is should be able to debug executables produced by compilers
    other than GCC.  Some of these may still use stabs with the old
    demangling format.

 2) GDB needs to work with old compilers as well as new ones.  I've
    worked in environments where we used GCC, but we would only switch
    to a new release after a lot of very careful testing.  (And
    sometimes not even then.)  Anyway, switching to a new version of
    GDB was not quite so onerous because it doesn't directly affect
    the quality or correctness of the code comprising an executable
    the way that a compiler or linker does.

    I think it would be unacceptable to force folks to upgrade to
    a particular version of GCC just because they've decided to install
    a new GDB release.

I do think there may come a time when we'll be able to drop support
for the old ABI, but I think that day is a ways off...

It'd be useful if someone could enumerate the compilers which still
produce stabs as the debug info.  For those that don't, but used to,
it'd also be good to know roughly when that support was dropped.

Assuming that we do need to support both, it'd be nice if the code
were arranged in such a way that it'd be easy to rip out the support
for the old ABI when the time comes.

Kevin
From meissner@cygnus.com Tue Oct 10 18:19:00 2000
From: Michael Meissner <meissner@cygnus.com>
To: Daniel Berlin <dberlin@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: Forgot to note
Date: Tue, 10 Oct 2000 18:19:00 -0000
Message-id: <20001010211904.49719@cse.cygnus.com>
References: <m33di46wkl.fsf@dan2.cygnus.com>
X-SW-Source: 2000-10/msg00054.html
Content-length: 1462

On Tue, Oct 10, 2000 at 08:38:50PM -0400, Daniel Berlin wrote:
> When the C++ abi moves to the new-abi, I can't fix stabs support
> without either adding a whole bunch of cruft, or making it not support
> the old ABI.
> 
> This is because things like gdb_mangle_name have to be changed to
> handle the new mangling scheme.
> So I have to either detect whether we have old-abi or new-abi
> somewhere, and then add a whole bunch of "if gnu-new-abi" type
> statements, or stop supporting the old abi for stabs/C++.
> 
> Currently, the consensus on gcc seems to be that linux should move to
> dwarf2 before 3.0 releases, which would mean that stopping support for
> new-abi/stabs would also be an option.
> 
> DWARF2 will work fine with either ABI automatically.
> 
> What should we do?
> Not support new-abi/stabs?
> Not support old-abi/stabs?
> Support both? (this is a not insignificant amount of work).

I think the only realistic solution is to support both.  Note, Linux is not the
only system out there that uses stabs (many of the embedded systems do to).
What are you going to do, compile some code with the new abi if no debugging
option were used and use the old abi if -g was used (on a system that supports
stabs as the native format).

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482
From dberlin@redhat.com Tue Oct 10 19:29:00 2000
From: Daniel Berlin <dberlin@redhat.com>
To: Michael Meissner <meissner@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: Forgot to note
Date: Tue, 10 Oct 2000 19:29:00 -0000
Message-id: <m3bswsds9s.fsf@dan2.cygnus.com>
References: <m33di46wkl.fsf@dan2.cygnus.com> <20001010211904.49719@cse.cygnus.com>
X-SW-Source: 2000-10/msg00056.html
Content-length: 1967

Michael Meissner <meissner@cygnus.com> writes:

> On Tue, Oct 10, 2000 at 08:38:50PM -0400, Daniel Berlin wrote:
> > When the C++ abi moves to the new-abi, I can't fix stabs support
> > without either adding a whole bunch of cruft, or making it not support
> > the old ABI.
> > 
> > This is because things like gdb_mangle_name have to be changed to
> > handle the new mangling scheme.
> > So I have to either detect whether we have old-abi or new-abi
> > somewhere, and then add a whole bunch of "if gnu-new-abi" type
> > statements, or stop supporting the old abi for stabs/C++.
> > 
> > Currently, the consensus on gcc seems to be that linux should move to
> > dwarf2 before 3.0 releases, which would mean that stopping support for
> > new-abi/stabs would also be an option.
> > 
> > DWARF2 will work fine with either ABI automatically.
> > 
> > What should we do?
> > Not support new-abi/stabs?
> > Not support old-abi/stabs?
> > Support both? (this is a not insignificant amount of work).
> 
> I think the only realistic solution is to support both.  Note, Linux is not the
> only system out there that uses stabs (many of the embedded systems do to).
> What are you going to do, compile some code with the new abi if no debugging
> option were used and use the old abi if -g was used (on a system that supports
> stabs as the native format).
>

It's arguably a *lot* simpler to change those platforms to dwarf2,
then to support new-abi/stabs *and* old-abi/stabs at the same time.

One is a case of changing a define in a gcc config file (correct me if
i'm incorrect here, I'm under the impression it should only really
require changing the DEFAULT_DEBUGGING_FORMAT, and possibly redefining
a few macros.), the other, writing a whole bunch of new code.


Remember, if we leave stabs support as is, it'll handle the old-abi
case fine. It's the new-abi that will kill it. So those platforms only
need to be using dwarf2 going forward, not going backwards.


--Dan

Re: Forgot to note

[Daniel Berlin]

Kevin Buettner <kevinb@cygnus.com> writes:

> [ gdb@sources.redhat.com added to the Cc list. ]
> 
> On Oct 10,  8:38pm, Daniel Berlin wrote:
> 
> > When the C++ abi moves to the new-abi, I can't fix stabs support
> > without either adding a whole bunch of cruft, or making it not support
> > the old ABI.
> > 
> > This is because things like gdb_mangle_name have to be changed to
> > handle the new mangling scheme.
> > So I have to either detect whether we have old-abi or new-abi
> > somewhere, and then add a whole bunch of "if gnu-new-abi" type
> > statements, or stop supporting the old abi for stabs/C++.
> > 
> > Currently, the consensus on gcc seems to be that linux should move to
> > dwarf2 before 3.0 releases, which would mean that stopping support for
> > new-abi/stabs would also be an option.
> > 
> > DWARF2 will work fine with either ABI automatically.
> > 
> > What should we do?
> > Not support new-abi/stabs?
> > Not support old-abi/stabs?
> > Support both? (this is a not insignificant amount of work).
> 
> I think we'll need to support both for a period of time.
> 
> Here are the reasons:
> 
>  1) GDB is should be able to debug executables produced by compilers
>     other than GCC.  Some of these may still use stabs with the old
>     demangling format.
I've yet to come across one that does, and I looked *very* hard.
They all use dwarf2.
I didn't look at older versions of compilers, just the current
versions.
Maybe they used to produce stabs?

Also, the new mangling/C++ abi is going to be supported and used by
Sun, HP, Intel, EDG, etc.

> 
>  2) GDB needs to work with old compilers as well as new ones.  I've
>     worked in environments where we used GCC, but we would only switch
>     to a new release after a lot of very careful testing.  (And
>     sometimes not even then.)  Anyway, switching to a new version of
>     GDB was not quite so onerous because it doesn't directly affect
>     the quality or correctness of the code comprising an executable
>     the way that a compiler or linker does.
> 
>     I think it would be unacceptable to force folks to upgrade to
>     a particular version of GCC just because they've decided to install
>     a new GDB release.
>

It's rather easy to keep old-abi/stabs working for C++ (requires just
about nothing) .
It's somewhat more difficult to do new-abi/stabs (requires coding
support for new abi stuff in the current stabs cruft).
It's a real PITA to do both (requires detecting our current ABI, then
supporting both).

So if we didn't support new-abi/stabs, we'd still support
old-abi/stabs just fine.

All we require is that going forward, gcc 3.0 produce dwarf2.
I think this was an eventual goal of the gcc guys anyway, to move all
the older ports to dwarf2 (IIRC, it's now part of the training
program to move a port to dwarf2).

> I do think there may come a time when we'll be able to drop support
> for the old ABI, but I think that day is a ways off...
> 
Hard to say.
That's why i want to bring it up now, to see if we can do it sooner
than a ways off.
> It'd be useful if someone could enumerate the compilers which still
> produce stabs as the debug info.  For those that don't, but used to,
> it'd also be good to know roughly when that support was dropped.

I'd really like this too.
> 
> Assuming that we do need to support both, it'd be nice if the code
> were arranged in such a way that it'd be easy to rip out the support
> for the old ABI when the time comes.

This would require significant rework of how things work right now. 
I'm willing to do it, but it's going to make things unstable for a
while, so it might be better to do it on a branch.
It's also a large amount of code, because it touches almost every
aspect of C++ in GDB, since all this crap is hardcoded in macros and
whatnot rightnow.

> Kevin

Re: Forgot to note

[Eli Zaretskii]

> From: Daniel Berlin <dberlin@redhat.com>
> Date: 10 Oct 2000 20:38:50 -0400
> 
> When the C++ abi moves to the new-abi, I can't fix stabs support
> without either adding a whole bunch of cruft, or making it not support
> the old ABI.
> 
> This is because things like gdb_mangle_name have to be changed to
> handle the new mangling scheme.
> So I have to either detect whether we have old-abi or new-abi
> somewhere, and then add a whole bunch of "if gnu-new-abi" type
> statements, or stop supporting the old abi for stabs/C++.
[snip]
> What should we do?
> Not support new-abi/stabs?
> Not support old-abi/stabs?
> Support both? (this is a not insignificant amount of work).

Sorry, I'm not privy enough to the C++ ABI issues, so I'm not sure I
understand the implications of the ABI change for the platforms I'm
interested in.  Could you say a few more words about this?

For instance, it is not clear to me whether the ABI change will affect
all platforms that use G++, or is this dependent on the executable
format which GCC/Binutils are congfigured to support.  Specifically,
what about non-dwarf platforms such as COFF and stabs?

Assuming that this affects all platforms, discontinuing the support
for the old ABI looks at first sight as a rather drastic and
user-unfriendly move.
From eliz@delorie.com Tue Oct 10 23:56:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: dberlin@redhat.com
Cc: meissner@cygnus.com, gdb-patches@sources.redhat.com
Subject: Re: Forgot to note
Date: Tue, 10 Oct 2000 23:56:00 -0000
Message-id: <200010110656.CAA06320@indy.delorie.com>
References: <m33di46wkl.fsf@dan2.cygnus.com> <20001010211904.49719@cse.cygnus.com> <m3bswsds9s.fsf@dan2.cygnus.com>
X-SW-Source: 2000-10/msg00062.html
Content-length: 659

> From: Daniel Berlin <dberlin@redhat.com>
> Date: 10 Oct 2000 22:29:51 -0400
> 
> It's arguably a *lot* simpler to change those platforms to dwarf2,
> then to support new-abi/stabs *and* old-abi/stabs at the same time.
> 
> One is a case of changing a define in a gcc config file (correct me if
> i'm incorrect here, I'm under the impression it should only really
> require changing the DEFAULT_DEBUGGING_FORMAT, and possibly redefining
> a few macros.)

Doesn't it require to configure Binutils differently as well?

I don't think the DJGPP port ever used dwarf2 code in Binutils, so
Someone (tm) will have to go through it carefully and see that it
works.
From eliz@delorie.com Tue Oct 10 23:56:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: kevinb@cygnus.com
Cc: gdb-patches@sources.redhat.com, gdb@sources.redhat.com
Subject: Re: Forgot to note
Date: Tue, 10 Oct 2000 23:56:00 -0000
Message-id: <200010110655.CAA06317@indy.delorie.com>
References: <m33di46wkl.fsf@dan2.cygnus.com> <1001011011645.ZM2970@ocotillo.lan>
X-SW-Source: 2000-10/msg00061.html
Content-length: 366

> Date: Tue, 10 Oct 2000 18:16:45 -0700
> From: Kevin Buettner <kevinb@cygnus.com>
> 
> It'd be useful if someone could enumerate the compilers which still
> produce stabs as the debug info.

The DJGPP port of GCC still uses stabs.  (It also supports COFF, but
that's almost useless for C++ debugging.)  I'm not aware of any work
being done to port dwarf2 to DJGPP.
From kevinb@cygnus.com Wed Oct 11 00:20:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Daniel Berlin <dberlin@redhat.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, cgf@cygnus.com, gdb-patches@sources.redhat.com
Subject: Re: [PATCH]: C++ mangling patch that is about to be committed
Date: Wed, 11 Oct 2000 00:20:00 -0000
Message-id: <1001011072037.ZM3267@ocotillo.lan>
References: <m38zrw4w2p.fsf@dan2.cygnus.com> <14819.13803.331153.108644@kwikemart.cygnus.com> <m3k8bgadxp.fsf@dan2.cygnus.com> <39E35F1D.6070@redhat.com> <m3zokc8p3c.fsf@dan2.cygnus.com> <14819.41553.706248.391933@kwikemart.cygnus.com> <m3bsws6wsv.fsf@dan2.cygnus.com> <dberlin@redhat.com>
X-SW-Source: 2000-10/msg00063.html
Content-length: 3875

On Oct 10,  8:33pm, Daniel Berlin wrote:

> gdb_mangle_name is a perfect example.
> It has nothing to do with symbols.
> All it does is take a type structure, a method id, and a signature,
> and build a new mangled name for it.
> It involves magical knowledge of how g++ mangles names.
> It doesn't even have a struct symbol in it, or anywhere near it.
> It isn't called except from a few C++ specific routines (cp-valprint
> or typeprint calls it, and one other place that escapes the mind).
> Of course, it's in symtab.c.
> 
> Are you starting to see my point?
> The people i have to get approval for are really not qualified to
> examine the patches.
> No offense, but taking you as an example, it took you a while to
> figure out what my changes were doing, and they aren't obsfuscated
> code.

Hmm... "really not qualified"...?

Daniel, I don't think that this choice of words is the way to win
friends and influence people.

If I read your implications correctly, then I am in complete
disagreement with you regarding Elena's qualifications.  Specifically,
when I've asked her for help in this area (gdb symbol tables), she's
always provided good and useful answers.

Prior to that though (in your message), I was starting to see your
point.  It's like this...  there are times when someone relatively
unfamiliar with a piece of code can go into it to fix a bug, or work
on an optimization, or add a new feature, or whatever.  At the end of
that time, whether it be a matter of hours or a number of days, I
think it is frequently the case that that person who was heretofore
unfamiliar with the code in question will have learned enough to rival
the maintainer's knowledge of the code, particularly if said
maintainer is also working on a bunch of other stuff at the same time.

But this is a temporary situation.  Or it should be at any rate
because when you provide a patch for someone to review, I've
always thought it best to:

 1) Describe the problem that your patch is trying to solve.

 2) Show (via a detailed analysis if necessary) why the current
    code is broken.

 3) Likewise, describe why your patch fixes the problem.

 4) Provide an analysis of the side effects (if any) of your
    patch, or other areas where it may be deficient.

In other words, you should attempt to pass along the knowledge that
you've gained while working on a certain piece of code.

You should also provide a summary of any domain specific knowledge
(e.g, g++ name mangling behavior) which you have that bears upon the
problem.  It's okay to provide a reference if it's incredibly
detailed.  (For example, see
http://sources.redhat.com/ml/gdb-patches/2000-08/msg00075.html in
which I provide a reference to a DWARF2 draft document.  Note,
however, that I summarize the salient points in the message proper.)

I know that this creates (substantially) more work for the patch
submitter.  But I also believe it creates higher quality patches.  I
do not always take the time to do everything that I described above,
but when I do, I'm forced to look more critically at my changes.  I
will frequently find problems with them in the process of writing my
analysis.  Even if I find no problems, the analysis will hopefully
give the maintainer the necessary background to see why the proposed
changes are necessary.  My motives are not completely altruistic; I've
discovered that providing a cogent analysis often means that my
patches are approved quicker which cuts down on the merge and retest
time.  (We all *do* test our changes again prior to committing them,
don't we?)  Also, I tend to forget these details relatively quickly,
so writing them down is a way of preserving this knowledge for myself
as well.

In my opinion, it is also useful for maintainers to go through this
exercise for patches in their own area since these patches are still
subject to peer review.

Kevin
From dberlin@redhat.com Wed Oct 11 04:50:00 2000
From: Daniel Berlin <dberlin@redhat.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, cgf@cygnus.com, gdb-patches@sources.redhat.com
Subject: Re: [PATCH]: C++ mangling patch that is about to be committed
Date: Wed, 11 Oct 2000 04:50:00 -0000
Message-id: <m366mzzjfa.fsf@dan2.cygnus.com>
References: <m38zrw4w2p.fsf@dan2.cygnus.com> <14819.13803.331153.108644@kwikemart.cygnus.com> <m3k8bgadxp.fsf@dan2.cygnus.com> <39E35F1D.6070@redhat.com> <m3zokc8p3c.fsf@dan2.cygnus.com> <14819.41553.706248.391933@kwikemart.cygnus.com> <m3bsws6wsv.fsf@dan2.cygnus.com> <1001011072037.ZM3267@ocotillo.lan>
X-SW-Source: 2000-10/msg00064.html
Content-length: 2555

Kevin Buettner <kevinb@cygnus.com> writes:

> On Oct 10,  8:33pm, Daniel Berlin wrote:
> 
> > gdb_mangle_name is a perfect example.
> > It has nothing to do with symbols.
> > All it does is take a type structure, a method id, and a signature,
> > and build a new mangled name for it.
> > It involves magical knowledge of how g++ mangles names.
> > It doesn't even have a struct symbol in it, or anywhere near it.
> > It isn't called except from a few C++ specific routines (cp-valprint
> > or typeprint calls it, and one other place that escapes the mind).
> > Of course, it's in symtab.c.
> > 
> > Are you starting to see my point?
> > The people i have to get approval for are really not qualified to
> > examine the patches.
> > No offense, but taking you as an example, it took you a while to
> > figure out what my changes were doing, and they aren't obsfuscated
> > code.
> 
> Hmm... "really not qualified"...?
> 
> Daniel, I don't think that this choice of words is the way to win
> friends and influence people.
> 
> If I read your implications correctly, then I am in complete
> disagreement with you regarding Elena's qualifications.  Specifically,
> when I've asked her for help in this area (gdb symbol tables), she's
> always provided good and useful answers.

No, i'm not implying what you think i'm implying.
I'm trying to say the area of expertise that gdb_mangle_name involves
isn't really "symbol tables", but "C++ mangling". It just happens to
be in symtab.c for no good reason.
AFAICT, it was originally in gdbtypes.c, where it doesn't belong
either.

It has nothing to do with Elena's qualifications, it has to do with
the area of maintainership this particular piece of code falls under.
It falls under the wrong area of maintainership, because of the file
it's in. Elena shouldn't have to waste her valueable time reviewing
patches like that, because trying to understand how to all of the C++
stuff fits together, and what a change to gdb_mangle_name will affect,
takes a *long time* for anyone to understand.  
 I was actually specifically referring to the fact that she mentioned it took
quite a bit of staring to figure out what the changes were doing. It
took me 3 weeks of staring to figure out that it was broken in the
first place. It's complex code, and it has nothing to do with symbol
tables. So why should Elena have to waste her time doing the staring?

Like I said, my point has nothing to do with Elena's qualifications.
She's quite qualified to review any piece of code.
That doesn't mean she should have to.
--Dan

Re: Forgot to note

[DJ Delorie]

> It's arguably a *lot* simpler to change those platforms to dwarf2,
> then to support new-abi/stabs *and* old-abi/stabs at the same time.

OK, I'll let you change DJGPP's built-in crash analyzer program, which
only understands stabs, and the mini-debuggers (edebug32, fsdb) and
IDE (rhide), which also only understand stabs.  No, they don't use
BFD.  No, gdb isn't an option to replace those.  Oh, and the different
parts of DJGPP are released asynchronously, so you'll have to fix
those long before you remove support in gcc, so we have a chance to
run through a release cycle (we release every few years) and get these
updates to users before the new gcc comes out.

Not that I object to moving djgpp to dwarf2 (people hate stabs/C++
debugging) but there's a lot of other things that have to change in
conjunction with changing the compiler.
From meissner@cygnus.com Wed Oct 11 10:06:00 2000
From: Michael Meissner <meissner@cygnus.com>
To: Daniel Berlin <dberlin@redhat.com>
Cc: Michael Meissner <meissner@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: Forgot to note
Date: Wed, 11 Oct 2000 10:06:00 -0000
Message-id: <20001011130611.11730@cse.cygnus.com>
References: <m33di46wkl.fsf@dan2.cygnus.com> <20001010211904.49719@cse.cygnus.com> <m3bswsds9s.fsf@dan2.cygnus.com>
X-SW-Source: 2000-10/msg00066.html
Content-length: 2976

On Tue, Oct 10, 2000 at 10:29:51PM -0400, Daniel Berlin wrote:
> Michael Meissner <meissner@cygnus.com> writes:
> 
> > On Tue, Oct 10, 2000 at 08:38:50PM -0400, Daniel Berlin wrote:
> > > When the C++ abi moves to the new-abi, I can't fix stabs support
> > > without either adding a whole bunch of cruft, or making it not support
> > > the old ABI.
> > > 
> > > This is because things like gdb_mangle_name have to be changed to
> > > handle the new mangling scheme.
> > > So I have to either detect whether we have old-abi or new-abi
> > > somewhere, and then add a whole bunch of "if gnu-new-abi" type
> > > statements, or stop supporting the old abi for stabs/C++.
> > > 
> > > Currently, the consensus on gcc seems to be that linux should move to
> > > dwarf2 before 3.0 releases, which would mean that stopping support for
> > > new-abi/stabs would also be an option.
> > > 
> > > DWARF2 will work fine with either ABI automatically.
> > > 
> > > What should we do?
> > > Not support new-abi/stabs?
> > > Not support old-abi/stabs?
> > > Support both? (this is a not insignificant amount of work).
> > 
> > I think the only realistic solution is to support both.  Note, Linux is not the
> > only system out there that uses stabs (many of the embedded systems do to).
> > What are you going to do, compile some code with the new abi if no debugging
> > option were used and use the old abi if -g was used (on a system that supports
> > stabs as the native format).
> >
> 
> It's arguably a *lot* simpler to change those platforms to dwarf2,
> then to support new-abi/stabs *and* old-abi/stabs at the same time.
>
> One is a case of changing a define in a gcc config file (correct me if
> i'm incorrect here, I'm under the impression it should only really
> require changing the DEFAULT_DEBUGGING_FORMAT, and possibly redefining
> a few macros.), the other, writing a whole bunch of new code.

What I'm worried about is all of the non-ELF ports, where you can't create
arbitrary sections and/or don't have a way to emit an address relocation to an
unaligned address (and hence can't do dwarf-2).  For example, in the past, MIPS
ECOFF used stabs and could not create arbitrary sections.  I know in the past,
there were cases where we used the host assembler and used stabs.  Until
somebody goes through and checks every single port on the FSF repository (and
somebody within Red Hat should check the various ports that are not yet donated
to the FSF), I believe you should plan to support new-abi via stabs.

> Remember, if we leave stabs support as is, it'll handle the old-abi
> case fine. It's the new-abi that will kill it. So those platforms only
> need to be using dwarf2 going forward, not going backwards.

I think this is too narrow of a viewpoint.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482
From shebs@apple.com Wed Oct 11 11:18:00 2000
From: Stan Shebs <shebs@apple.com>
To: Daniel Berlin <dberlin@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: Forgot to note
Date: Wed, 11 Oct 2000 11:18:00 -0000
Message-id: <39E4AEE2.2213F615@apple.com>
References: <m33di46wkl.fsf@dan2.cygnus.com>
X-SW-Source: 2000-10/msg00067.html
Content-length: 1325

Daniel Berlin wrote:
> 
> Currently, the consensus on gcc seems to be that linux should move to
> dwarf2 before 3.0 releases, which would mean that stopping support for
> new-abi/stabs would also be an option.

I Don't Think So...

> DWARF2 will work fine with either ABI automatically.
> 
> What should we do?
> Not support new-abi/stabs?
> Not support old-abi/stabs?
> Support both? (this is a not insignificant amount of work).

Guess what, you're going to have to work harder. :-)

The only valid rationale for skipping new-abi/stabs support was if
GCC itself was no longer going to support stabs with the new ABI.
I haven't heard that that was going to happen, and it seems
implausible anyway because of the magnitude of the disruption.

As a transition strategy it would be acceptable to work up
placeholders in stabs support so that we can add stuff incrementally.
For instance, Apple may or may not be moving off stabs in the
GCC 3.0 timeframe, so we may be motivated to do some of the actual
new-abi/stabs work.

Even under an optimistic dwarf2 adoption scenario (dwarf2 still
hasn't been standardized for one thing, although it's getting
close), the stabs format is going to be with us for at least another
five years, so you should plan your hacking so that you can live with
the stabs reader for that long.

Stan
From eager@eagercon.com Wed Oct 11 11:25:00 2000
From: Michael Eager <eager@eagercon.com>
To: Stan Shebs <shebs@apple.com>
Cc: Daniel Berlin <dberlin@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: Forgot to note
Date: Wed, 11 Oct 2000 11:25:00 -0000
Message-id: <39E4B09A.D096436F@eagercon.com>
References: <m33di46wkl.fsf@dan2.cygnus.com> <39E4AEE2.2213F615@apple.com>
X-SW-Source: 2000-10/msg00068.html
Content-length: 804

Stan Shebs wrote:
> 
> Even under an optimistic dwarf2 adoption scenario (dwarf2 still
> hasn't been standardized for one thing, although it's getting
> close), the stabs format is going to be with us for at least another
> five years, so you should plan your hacking so that you can live with
> the stabs reader for that long.

FYI, the current plan is to consider all of the proposals for 
changes to Dwarf 2 by the end of this year and release a version
of the revised standard for public review early in 2001.

My experience is the same as Stan's.  Old formats don't disappear,
and they certainly don't disappear because someone says that they
should.  Plan for a long End-Of-Life status.

-- 
Michael Eager	 Eager Consulting     eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077
From dberlin@redhat.com Wed Oct 11 12:46:00 2000
From: Daniel Berlin <dberlin@redhat.com>
To: Stan Shebs <shebs@apple.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: Forgot to note
Date: Wed, 11 Oct 2000 12:46:00 -0000
Message-id: <m3bswr88kg.fsf@dan2.cygnus.com>
References: <m33di46wkl.fsf@dan2.cygnus.com> <39E4AEE2.2213F615@apple.com>
X-SW-Source: 2000-10/msg00069.html
Content-length: 2220

Stan Shebs <shebs@apple.com> writes:

> Daniel Berlin wrote:
> > 
> > Currently, the consensus on gcc seems to be that linux should move to
> > dwarf2 before 3.0 releases, which would mean that stopping support for
> > new-abi/stabs would also be an option.
> 
> I Don't Think So...
> 
> > DWARF2 will work fine with either ABI automatically.
> > 
> > What should we do?
> > Not support new-abi/stabs?
> > Not support old-abi/stabs?
> > Support both? (this is a not insignificant amount of work).
> 
> Guess what, you're going to have to work harder. :-)


Not necessarily me, it depends on my schedule.
It may end up  that i won't have time to add support for new-abi/stabs
anytime soon.
> The only valid rationale for skipping new-abi/stabs support was if
> GCC itself was no longer going to support stabs with the new ABI.
> I haven't heard that that was going to happen, and it seems
> implausible anyway because of the magnitude of the disruption.
> 
Right.

> As a transition strategy it would be acceptable to work up
> placeholders in stabs support so that we can add stuff incrementally.
> For instance, Apple may or may not be moving off stabs in the
> GCC 3.0 timeframe, so we may be motivated to do some of the actual
> new-abi/stabs work.

Hey, that'd be nice.

> 
> Even under an optimistic dwarf2 adoption scenario (dwarf2 still
> hasn't been standardized for one thing, although it's getting
> close),

That's not really fair to say.
1. Dwarf2 *has* been adopted. Compilers either use it (most), or plan
on using it.
Nobody plans on using something else in the future, AFAIK.
2. It wasn't "officially" standardized because the sponsor went broke.
There is a draft standard, and this is what people use.
Mike eager also is driving the 2.1 standard.

< the stabs format is going to be with us for at least another
> five years, so you should plan your hacking so that you can live with
> the stabs reader for that long.
> 
It's not the stabs reader i'm worried about.
It's all the crufty stupidity specifically related to C++/stabs that
is going to break.

Just wanted to see if I could remove it yet, but apparently not.
I certainly don't want to add to it, but it appears i'm going to have
to.


> Stan

Re: Forgot to note

[Daniel Berlin]

DJ Delorie <dj@delorie.com> writes:

> > It's arguably a *lot* simpler to change those platforms to dwarf2,
> > then to support new-abi/stabs *and* old-abi/stabs at the same time.
> 
> OK, I'll let you change DJGPP's built-in crash analyzer program, which
> only understands stabs, and the mini-debuggers (edebug32, fsdb) and
> IDE (rhide), which also only understand stabs.  No, they don't use
> BFD. 

Do they have the cruft necessary to properly debug C++ stabs programs?
If not, then you could keep stabs for DJGPP without any problems.
Does C++ debugging with GDB work on djgpp (I've never seen test
results for the C++ tests)? If not, it's not an issue for djgpp.

> No, gdb isn't an option to replace those. 
 I wouldn't imply it is.  
> Oh, and the different
> parts of DJGPP are released asynchronously, so you'll have to fix
> those long before you remove support in gcc, so we have a chance to
> run through a release cycle (we release every few years) and get these
> updates to users before the new gcc comes out.
> 

> Not that I object to moving djgpp to dwarf2 (people hate stabs/C++
> debugging) but there's a lot of other things that have to change in
> conjunction with changing the compiler.

I realize this, but i'm trying to avoid adding a whole bunch of hair
to gdb, and at the same time, further a gcc goal.
It's apparent i won't be able to avoid adding that hair.
It's also unfortunate,  but necessary.
--Dan

Re: Forgot to note

[Daniel Berlin]

Michael Meissner <meissner@cygnus.com> writes:

> On Tue, Oct 10, 2000 at 10:29:51PM -0400, Daniel Berlin wrote:
> > Michael Meissner <meissner@cygnus.com> writes:
> > 
> > > On Tue, Oct 10, 2000 at 08:38:50PM -0400, Daniel Berlin wrote:
> > > > When the C++ abi moves to the new-abi, I can't fix stabs support
> > > > without either adding a whole bunch of cruft, or making it not support
> > > > the old ABI.
> > > > 
> > > > This is because things like gdb_mangle_name have to be changed to
> > > > handle the new mangling scheme.
> > > > So I have to either detect whether we have old-abi or new-abi
> > > > somewhere, and then add a whole bunch of "if gnu-new-abi" type
> > > > statements, or stop supporting the old abi for stabs/C++.
> > > > 
> > > > Currently, the consensus on gcc seems to be that linux should move to
> > > > dwarf2 before 3.0 releases, which would mean that stopping support for
> > > > new-abi/stabs would also be an option.
> > > > 
> > > > DWARF2 will work fine with either ABI automatically.
> > > > 
> > > > What should we do?
> > > > Not support new-abi/stabs?
> > > > Not support old-abi/stabs?
> > > > Support both? (this is a not insignificant amount of work).
> > > 
> > > I think the only realistic solution is to support both.  Note, Linux is not the
> > > only system out there that uses stabs (many of the embedded systems do to).
> > > What are you going to do, compile some code with the new abi if no debugging
> > > option were used and use the old abi if -g was used (on a system that supports
> > > stabs as the native format).
> > >
> > 
> > It's arguably a *lot* simpler to change those platforms to dwarf2,
> > then to support new-abi/stabs *and* old-abi/stabs at the same time.
> >
> > One is a case of changing a define in a gcc config file (correct me if
> > i'm incorrect here, I'm under the impression it should only really
> > require changing the DEFAULT_DEBUGGING_FORMAT, and possibly redefining
> > a few macros.), the other, writing a whole bunch of new code.
> 
> What I'm worried about is all of the non-ELF ports, where you can't create
> arbitrary sections and/or don't have a way to emit an address relocation to an
> unaligned address (and hence can't do dwarf-2).  For example, in the past, MIPS
> ECOFF used stabs and could not create arbitrary sections.  I know in the past,
> there were cases where we used the host assembler and used stabs.  Until
> somebody goes through and checks every single port on the FSF repository (and
> somebody within Red Hat should check the various ports that are not yet donated
> to the FSF), I believe you should plan to support new-abi via stabs.
Forgot about those.
I sincerely hope someone will help fund part of this work, because
it's going to be a lot for me to be the only one to handle.
It's also hard to motivate myself to do it, unless I become scheduled
to do it, mainly because I can envinsion just how hairy it's going to
become.

> 
> > Remember, if we leave stabs support as is, it'll handle the old-abi
> > case fine. It's the new-abi that will kill it. So those platforms only
> > need to be using dwarf2 going forward, not going backwards.
> 
> I think this is too narrow of a viewpoint.
Probably right, i'm just really trying to avoid the inveitable.
--Dan

Re: Forgot to note

[Daniel Berlin]

Michael Eager <eager@eagercon.com> writes:

> Stan Shebs wrote:
> > 
> > Even under an optimistic dwarf2 adoption scenario (dwarf2 still
> > hasn't been standardized for one thing, although it's getting
> > close), the stabs format is going to be with us for at least another
> > five years, so you should plan your hacking so that you can live with
> > the stabs reader for that long.
> 
> FYI, the current plan is to consider all of the proposals for 
> changes to Dwarf 2 by the end of this year and release a version
> of the revised standard for public review early in 2001.
> 
> My experience is the same as Stan's.  Old formats don't disappear,
> and they certainly don't disappear because someone says that they
> should.  Plan for a long End-Of-Life status.

Then, as i said, i'm really going to need some help doing this.
--Dan

Re: Forgot to note

[Michael Snyder]

Daniel Berlin wrote:
> 
> Michael Eager <eager@eagercon.com> writes:
> 
> > Stan Shebs wrote:
> > >
> > > Even under an optimistic dwarf2 adoption scenario (dwarf2 still
> > > hasn't been standardized for one thing, although it's getting
> > > close), the stabs format is going to be with us for at least another
> > > five years, so you should plan your hacking so that you can live with
> > > the stabs reader for that long.
> >
> > FYI, the current plan is to consider all of the proposals for
> > changes to Dwarf 2 by the end of this year and release a version
> > of the revised standard for public review early in 2001.
> >
> > My experience is the same as Stan's.  Old formats don't disappear,
> > and they certainly don't disappear because someone says that they
> > should.  Plan for a long End-Of-Life status.
> 
> Then, as i said, i'm really going to need some help doing this.

Hey, we all know the feeling.  ;-)
From eliz@delorie.com Thu Oct 12 00:54:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: dberlin@redhat.com
Cc: dj@delorie.com, meissner@cygnus.com, gdb-patches@sources.redhat.com
Subject: Re: Forgot to note
Date: Thu, 12 Oct 2000 00:54:00 -0000
Message-id: <200010120754.DAA07133@indy.delorie.com>
References: <m33di46wkl.fsf@dan2.cygnus.com> <20001010211904.49719@cse.cygnus.com> <m3bswsds9s.fsf@dan2.cygnus.com> <200010111652.MAA12141@envy.delorie.com> <m37l7f88cl.fsf@dan2.cygnus.com>
X-SW-Source: 2000-10/msg00074.html
Content-length: 678

> > > It's arguably a *lot* simpler to change those platforms to dwarf2,
> > > then to support new-abi/stabs *and* old-abi/stabs at the same time.
> > 
> > OK, I'll let you change DJGPP's built-in crash analyzer program, which
> > only understands stabs, and the mini-debuggers (edebug32, fsdb) and
> > IDE (rhide), which also only understand stabs.  No, they don't use
> > BFD. 
> 
> Do they have the cruft necessary to properly debug C++ stabs programs?

Yes.

> Does C++ debugging with GDB work on djgpp

Yes.

> (I've never seen test results for the C++ tests)?

The GDB test suite doesn't work for DJGPP, for reasons that have
nothing to do with GDB or C++ support per se.
From taylor@cygnus.com Thu Oct 12 07:07:00 2000
From: David Taylor <taylor@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [RFA] addresses/pointers vs numbers and expression evaluation
Date: Thu, 12 Oct 2000 07:07:00 -0000
Message-id: <200010121406.KAA21106@texas.cygnus.com>
X-SW-Source: 2000-10/msg00075.html
Content-length: 12482

The following patch concerns bugs brought to light during a port of
gdb to a target with separate instruction and data.

The bugs will potentially impact any port which defines
POINTER_TO_ADDRESS to have any value other than the default value.

There are undoubtably additional bugs still lurking in the expression
evaluation code.

Several places in gdb it calls

    parse_and_eval_address

when the expression is *NOT* an address, but rather is just a number!
For example, it calls parse_and_eval_address when you type:

    set height 24

For this processor, treating 24 as a pointer resulted in an address of
0x01000018 -- 16 meg plus 24!  Similarly, it does this for the count
given to the continue and step commands as well as a few other places.

To fix this, I have create a new function called parse_and_eval_long
and changed 17 of the calls to parse_and_eval_address.

I have tested this on solaris native and on solaris x d10v (using the
simulator).  There were no regressions.

Here's the ChangeLog entry and the patch:

	* parse.c (parse_and_eval_long): New function.
	(value.h): Declare it.
	
	* breakpoint.c (breakpoints_info, maintenance_info_breakpoints):
	Call parse_and_eval_long, not parse_and_eval_address.
	* command.c (do_setshow_command): Ditto.
	* infcmd.c (step_1, signal_command, continue_command): Ditto.
	* infrun.c (signals_info): Ditto.
	* stack.c (set_backtrace_limit_command, backtrace_command_1,
	up_silently_base, down_silently_base): Ditto.
	* tracepoints.c (tracepoints_info, trace_find_command,
 	trace_find_tracepoint_command): Ditto.
	* valprint.c (set_radix): Ditto.
	* values (show_values): Ditto.
	
Index: breakpoint.c
===================================================================
RCS file: /cvs/src/src/gdb/breakpoint.c,v
retrieving revision 1.17
diff -c -r1.17 breakpoint.c
*** breakpoint.c	2000/08/30 00:58:58	1.17
--- breakpoint.c	2000/10/12 13:57:06
***************
*** 3638,3644 ****
    int bnum = -1;
  
    if (bnum_exp)
!     bnum = parse_and_eval_address (bnum_exp);
  
    breakpoint_1 (bnum, 0);
  }
--- 3638,3644 ----
    int bnum = -1;
  
    if (bnum_exp)
!     bnum = parse_and_eval_long (bnum_exp);
  
    breakpoint_1 (bnum, 0);
  }
***************
*** 3650,3656 ****
    int bnum = -1;
  
    if (bnum_exp)
!     bnum = parse_and_eval_address (bnum_exp);
  
    breakpoint_1 (bnum, 1);
  }
--- 3650,3656 ----
    int bnum = -1;
  
    if (bnum_exp)
!     bnum = parse_and_eval_long (bnum_exp);
  
    breakpoint_1 (bnum, 1);
  }
Index: command.c
===================================================================
RCS file: /cvs/src/src/gdb/command.c,v
retrieving revision 1.17
diff -c -r1.17 command.c
*** command.c	2000/08/08 00:17:39	1.17
--- command.c	2000/10/12 13:57:08
***************
*** 1622,1628 ****
  	case var_uinteger:
  	  if (arg == NULL)
  	    error_no_arg ("integer to set it to.");
! 	  *(unsigned int *) c->var = parse_and_eval_address (arg);
  	  if (*(unsigned int *) c->var == 0)
  	    *(unsigned int *) c->var = UINT_MAX;
  	  break;
--- 1622,1628 ----
  	case var_uinteger:
  	  if (arg == NULL)
  	    error_no_arg ("integer to set it to.");
! 	  *(unsigned int *) c->var = parse_and_eval_long (arg);
  	  if (*(unsigned int *) c->var == 0)
  	    *(unsigned int *) c->var = UINT_MAX;
  	  break;
***************
*** 1631,1637 ****
  	    unsigned int val;
  	    if (arg == NULL)
  	      error_no_arg ("integer to set it to.");
! 	    val = parse_and_eval_address (arg);
  	    if (val == 0)
  	      *(int *) c->var = INT_MAX;
  	    else if (val >= INT_MAX)
--- 1631,1637 ----
  	    unsigned int val;
  	    if (arg == NULL)
  	      error_no_arg ("integer to set it to.");
! 	    val = parse_and_eval_long (arg);
  	    if (val == 0)
  	      *(int *) c->var = INT_MAX;
  	    else if (val >= INT_MAX)
***************
*** 1643,1649 ****
  	case var_zinteger:
  	  if (arg == NULL)
  	    error_no_arg ("integer to set it to.");
! 	  *(int *) c->var = parse_and_eval_address (arg);
  	  break;
  	case var_enum:
  	  {
--- 1643,1649 ----
  	case var_zinteger:
  	  if (arg == NULL)
  	    error_no_arg ("integer to set it to.");
! 	  *(int *) c->var = parse_and_eval_long (arg);
  	  break;
  	case var_enum:
  	  {
Index: eval.c
===================================================================
RCS file: /cvs/src/src/gdb/eval.c,v
retrieving revision 1.8
diff -c -r1.8 eval.c
*** eval.c	2000/09/01 23:50:17	1.8
--- eval.c	2000/10/12 13:57:09
***************
*** 103,108 ****
--- 103,123 ----
    return addr;
  }
  
+ /* Like parse_and_eval_address, but treats the value of the expression
+    as an integer, not an address, returns a LONGEST, not a CORE_ADDR */
+ LONGEST
+ parse_and_eval_long (char *exp)
+ {
+   struct expression *expr = parse_expression (exp);
+   register LONGEST retval;
+   register struct cleanup *old_chain =
+     make_cleanup (free_current_contents, &expr);
+ 
+   retval = value_as_long (evaluate_expression (expr));
+   do_cleanups (old_chain);
+   return (retval);
+ }
+ 
  value_ptr
  parse_and_eval (char *exp)
  {
Index: infcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/infcmd.c,v
retrieving revision 1.11
diff -c -r1.11 infcmd.c
*** infcmd.c	2000/09/02 00:07:13	1.11
--- infcmd.c	2000/10/12 13:57:11
***************
*** 381,387 ****
        while (num != 0)
  	{
  	  set_ignore_count (num,
! 			    parse_and_eval_address (proc_count_exp) - 1,
  			    from_tty);
  	  /* set_ignore_count prints a message ending with a period.
  	     So print two spaces before "Continuing.".  */
--- 381,387 ----
        while (num != 0)
  	{
  	  set_ignore_count (num,
! 			    parse_and_eval_long (proc_count_exp) - 1,
  			    from_tty);
  	  /* set_ignore_count prints a message ending with a period.
  	     So print two spaces before "Continuing.".  */
***************
*** 465,471 ****
        async_disable_stdin ();
      }
  
!   count = count_string ? parse_and_eval_address (count_string) : 1;
  
    if (!single_inst || skip_subroutines)		/* leave si command alone */
      {
--- 465,471 ----
        async_disable_stdin ();
      }
  
!   count = count_string ? parse_and_eval_long (count_string) : 1;
  
    if (!single_inst || skip_subroutines)		/* leave si command alone */
      {
***************
*** 777,783 ****
    if (oursig == TARGET_SIGNAL_UNKNOWN)
      {
        /* No, try numeric.  */
!       int num = parse_and_eval_address (signum_exp);
  
        if (num == 0)
  	oursig = TARGET_SIGNAL_0;
--- 777,783 ----
    if (oursig == TARGET_SIGNAL_UNKNOWN)
      {
        /* No, try numeric.  */
!       int num = parse_and_eval_long (signum_exp);
  
        if (num == 0)
  	oursig = TARGET_SIGNAL_0;
Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.18
diff -c -r1.18 infrun.c
*** infrun.c	2000/09/02 00:08:05	1.18
--- infrun.c	2000/10/12 13:57:15
***************
*** 3899,3905 ****
  	{
  	  /* No, try numeric.  */
  	  oursig =
! 	    target_signal_from_command (parse_and_eval_address (signum_exp));
  	}
        sig_print_info (oursig);
        return;
--- 3899,3905 ----
  	{
  	  /* No, try numeric.  */
  	  oursig =
! 	    target_signal_from_command (parse_and_eval_long (signum_exp));
  	}
        sig_print_info (oursig);
        return;
Index: stack.c
===================================================================
RCS file: /cvs/src/src/gdb/stack.c,v
retrieving revision 1.7
diff -c -r1.7 stack.c
*** stack.c	2000/07/30 01:48:27	1.7
--- stack.c	2000/10/12 13:57:17
***************
*** 1038,1044 ****
  static void
  set_backtrace_limit_command (char *count_exp, int from_tty)
  {
!   int count = parse_and_eval_address (count_exp);
  
    if (count < 0)
      error ("Negative argument not meaningful as backtrace limit.");
--- 1038,1044 ----
  static void
  set_backtrace_limit_command (char *count_exp, int from_tty)
  {
!   int count = parse_and_eval_long (count_exp);
  
    if (count < 0)
      error ("Negative argument not meaningful as backtrace limit.");
***************
*** 1086,1092 ****
    trailing_level = 0;
    if (count_exp)
      {
!       count = parse_and_eval_address (count_exp);
        if (count < 0)
  	{
  	  struct frame_info *current;
--- 1086,1092 ----
    trailing_level = 0;
    if (count_exp)
      {
!       count = parse_and_eval_long (count_exp);
        if (count < 0)
  	{
  	  struct frame_info *current;
***************
*** 1740,1746 ****
    register struct frame_info *fi;
    int count = 1, count1;
    if (count_exp)
!     count = parse_and_eval_address (count_exp);
    count1 = count;
  
    if (target_has_stack == 0 || selected_frame == 0)
--- 1740,1746 ----
    register struct frame_info *fi;
    int count = 1, count1;
    if (count_exp)
!     count = parse_and_eval_long (count_exp);
    count1 = count;
  
    if (target_has_stack == 0 || selected_frame == 0)
***************
*** 1777,1783 ****
    register struct frame_info *frame;
    int count = -1, count1;
    if (count_exp)
!     count = -parse_and_eval_address (count_exp);
    count1 = count;
  
    if (target_has_stack == 0 || selected_frame == 0)
--- 1777,1783 ----
    register struct frame_info *frame;
    int count = -1, count1;
    if (count_exp)
!     count = -parse_and_eval_long (count_exp);
    count1 = count;
  
    if (target_has_stack == 0 || selected_frame == 0)
Index: tracepoint.c
===================================================================
RCS file: /cvs/src/src/gdb/tracepoint.c,v
retrieving revision 1.10
diff -c -r1.10 tracepoint.c
*** tracepoint.c	2000/09/01 00:12:10	1.10
--- tracepoint.c	2000/10/12 13:57:19
***************
*** 465,471 ****
    int tpnum = -1;
  
    if (tpnum_exp)
!     tpnum = parse_and_eval_address (tpnum_exp);
  
    ALL_TRACEPOINTS (t)
      if (tpnum == -1 || tpnum == t->number)
--- 465,471 ----
    int tpnum = -1;
  
    if (tpnum_exp)
!     tpnum = parse_and_eval_long (tpnum_exp);
  
    ALL_TRACEPOINTS (t)
      if (tpnum == -1 || tpnum == t->number)
***************
*** 1986,1992 ****
  	  frameno = traceframe_number - 1;
  	}
        else
! 	frameno = parse_and_eval_address (args);
  
        if (frameno < -1)
  	error ("invalid input (%d is less than zero)", frameno);
--- 1986,1992 ----
  	  frameno = traceframe_number - 1;
  	}
        else
! 	frameno = parse_and_eval_long (args);
  
        if (frameno < -1)
  	error ("invalid input (%d is less than zero)", frameno);
Index: valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/valprint.c,v
retrieving revision 1.6
diff -c -r1.6 valprint.c
*** valprint.c	2000/07/30 01:48:27	1.6
--- valprint.c	2000/10/12 13:57:20
***************
*** 1416,1422 ****
  {
    unsigned radix;
  
!   radix = (arg == NULL) ? 10 : parse_and_eval_address (arg);
    set_output_radix_1 (0, radix);
    set_input_radix_1 (0, radix);
    if (from_tty)
--- 1416,1422 ----
  {
    unsigned radix;
  
!   radix = (arg == NULL) ? 10 : parse_and_eval_long (arg);
    set_output_radix_1 (0, radix);
    set_input_radix_1 (0, radix);
    if (from_tty)
Index: value.h
===================================================================
RCS file: /cvs/src/src/gdb/value.h,v
retrieving revision 1.10
diff -c -r1.10 value.h
*** value.h	2000/09/04 08:29:25	1.10
--- value.h	2000/10/12 13:57:21
***************
*** 410,415 ****
--- 410,417 ----
  
  extern CORE_ADDR parse_and_eval_address_1 (char **expptr);
  
+ extern LONGEST parse_and_eval_long (char *exp);
+ 
  extern value_ptr access_value_history (int num);
  
  extern value_ptr value_of_internalvar (struct internalvar *var);
Index: values.c
===================================================================
RCS file: /cvs/src/src/gdb/values.c,v
retrieving revision 1.9
diff -c -r1.9 values.c
*** values.c	2000/07/30 01:48:27	1.9
--- values.c	2000/10/12 13:57:22
***************
*** 351,357 ****
        /* "info history +" should print from the stored position.
           "info history <exp>" should print around value number <exp>.  */
        if (num_exp[0] != '+' || num_exp[1] != '\0')
! 	num = parse_and_eval_address (num_exp) - 5;
      }
    else
      {
--- 351,357 ----
        /* "info history +" should print from the stored position.
           "info history <exp>" should print around value number <exp>.  */
        if (num_exp[0] != '+' || num_exp[1] != '\0')
! 	num = parse_and_eval_long (num_exp) - 5;
      }
    else
      {
From ezannoni@cygnus.com Thu Oct 12 09:53:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Daniel Berlin <dberlin@redhat.com>
Cc: gdb-patches@sources.redhat.com, Elena Zannoni <ezannoni@cygnus.com>
Subject: Re: [RFA]: Remove linear search for C++
Date: Thu, 12 Oct 2000 09:53:00 -0000
Message-id: <14821.60528.681193.751884@kwikemart.cygnus.com>
References: <m3g0m4dnv1.fsf@dan2.cygnus.com>
X-SW-Source: 2000-10/msg00076.html
Content-length: 15780

OK, I committed the following:


2000-10-12  Elena Zannoni  <ezannoni@kwikemart.cygnus.com>

	From Daniel Berlin <dberlin@redhat.com> :

	* symtab.c (lookup_symbol_aux): New function. Renamed from
 	lookup_symbol. Move code to do demangling/case sensitivity to
 	lookup_symbol().
  	(lookup_symbol): Now wrapper for lookup_symbol_aux, so we can
 	perform case sensitivity/demangling without leaking memory.  Move
 	code to do demangling/case sensitivity from old_lookup_symbol to
 	here.
	(lookup_partial_symbol): Use SYMBOL_SOURCE_NAME instead of
 	SYMBOL_NAME.
	(lookup_block_symbol): Use SYMBOL_SOURCE_NAME instead of
 	SYMBOL_NAME. Don't do linear search in case of C++.

  	* symfile.c (compare_symbols): Use SYMBOL_SOURCE_NAME instead of
 	SYMBOL_NAME.
  	(compare_psymbols): Same here.

Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.18
diff -c -u -p -r1.18 symfile.c
--- symfile.c	2000/09/02 00:09:06	1.18
+++ symfile.c	2000/10/12 16:37:15
@@ -212,8 +212,7 @@ compare_symbols (const PTR s1p, const PT
 
   s1 = (struct symbol **) s1p;
   s2 = (struct symbol **) s2p;
-
-  return (STRCMP (SYMBOL_NAME (*s1), SYMBOL_NAME (*s2)));
+  return (STRCMP (SYMBOL_SOURCE_NAME (*s1), SYMBOL_SOURCE_NAME (*s2)));
 }
 
 /*
@@ -241,8 +240,14 @@ compare_symbols (const PTR s1p, const PT
 static int
 compare_psymbols (const PTR s1p, const PTR s2p)
 {
-  register char *st1 = SYMBOL_NAME (*(struct partial_symbol **) s1p);
-  register char *st2 = SYMBOL_NAME (*(struct partial_symbol **) s2p);
+  register struct partial_symbol **s1, **s2;
+  register char *st1, *st2;
+
+  s1 = (struct partial_symbol **) s1p;
+  s2 = (struct partial_symbol **) s2p;
+  st1 = SYMBOL_SOURCE_NAME (*s1);
+  st2 = SYMBOL_SOURCE_NAME (*s2);
+
 
   if ((st1[0] - st2[0]) || !st1[0])
     {
Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.15
diff -c -u -p -r1.15 symtab.c
--- symtab.c	2000/09/04 08:29:25	1.15
+++ symtab.c	2000/10/12 16:37:16
@@ -83,6 +83,13 @@ static struct partial_symbol *lookup_par
 
 static struct symtab *lookup_symtab_1 (char *);
 
+static struct symbol *lookup_symbol_aux (const char *name, const
+					 struct block *block, const
+					 namespace_enum namespace, int
+					 *is_a_field_of_this, struct
+					 symtab **symtab);
+
+
 static void cplusplus_hint (char *);
 
 static struct symbol *find_active_alias (struct symbol *sym, CORE_ADDR addr);
@@ -572,17 +579,14 @@ fixup_psymbol_section (struct partial_sy
    can probably assume it will never hit the C++ code).  */
 
 struct symbol *
-lookup_symbol (const char *name, register const struct block *block,
+lookup_symbol (const char *name, const struct block *block,
 	       const namespace_enum namespace, int *is_a_field_of_this,
 	       struct symtab **symtab)
 {
-  register struct symbol *sym;
-  register struct symtab *s = NULL;
-  register struct partial_symtab *ps;
-  struct blockvector *bv;
-  register struct objfile *objfile = NULL;
-  register struct block *b;
-  register struct minimal_symbol *msymbol;
+  char *modified_name = NULL;
+  char *modified_name2 = NULL;
+  int needtofreename = 0;
+  struct symbol *returnval;
 
   if (case_sensitivity == case_sensitive_off)
     {
@@ -594,9 +598,45 @@ lookup_symbol (const char *name, registe
       for (i= 0; i < len; i++)
         copy[i] = tolower (name[i]);
       copy[len] = 0;
-      name = copy;
+      modified_name = copy;
     }
+  else 
+      modified_name = (char *) name;
+
+  /* If we are using C++ language, demangle the name before doing a lookup, so
+     we can always binary search. */
+  if (current_language->la_language == language_cplus)
+    {
+      modified_name2 = cplus_demangle (modified_name, DMGL_ANSI | DMGL_PARAMS);
+      if (modified_name2)
+	{
+	  modified_name = modified_name2;
+	  needtofreename = 1;
+	}
+    }
+
+  returnval = lookup_symbol_aux (modified_name, block, namespace,
+				 is_a_field_of_this, symtab);
+  if (needtofreename)
+    free (modified_name2);
+
+  return returnval;	 
+}
+
+static struct symbol *
+lookup_symbol_aux (const char *name, const struct block *block,
+	       const namespace_enum namespace, int *is_a_field_of_this,
+	       struct symtab **symtab)
+{
+  register struct symbol *sym;
+  register struct symtab *s = NULL;
+  register struct partial_symtab *ps;
+  register struct blockvector *bv;
+  register struct objfile *objfile = NULL;
+  register struct block *b;
+  register struct minimal_symbol *msymbol;
 
+
   /* Search specified block and its superiors.  */
 
   while (block != 0)
@@ -987,7 +1027,7 @@ lookup_partial_symbol (struct partial_sy
 	    {
 	      do_linear_search = 1;
 	    }
-	  if (STRCMP (SYMBOL_NAME (*center), name) >= 0)
+	  if (STRCMP (SYMBOL_SOURCE_NAME (*center), name) >= 0)
 	    {
 	      top = center;
 	    }
@@ -1190,9 +1230,7 @@ lookup_block_symbol (register const stru
     {
       /* Reset the linear search flag so if the binary search fails, we
          won't do the linear search once unless we find some reason to
-         do so, such as finding a C++ symbol during the binary search.
-         Note that for C++ modules, ALL the symbols in a block should
-         end up marked as C++ symbols. */
+         do so */
 
       do_linear_search = 0;
       top = BLOCK_NSYMS (block);
@@ -1210,22 +1248,19 @@ lookup_block_symbol (register const stru
 	    }
 	  inc = (inc >> 1) + bot;
 	  sym = BLOCK_SYM (block, inc);
-	  if (!do_linear_search
-	      && (SYMBOL_LANGUAGE (sym) == language_cplus
-		  || SYMBOL_LANGUAGE (sym) == language_java
-	      ))
+	  if (!do_linear_search && (SYMBOL_LANGUAGE (sym) == language_java))
 	    {
 	      do_linear_search = 1;
 	    }
-	  if (SYMBOL_NAME (sym)[0] < name[0])
+	  if (SYMBOL_SOURCE_NAME (sym)[0] < name[0])
 	    {
 	      bot = inc;
 	    }
-	  else if (SYMBOL_NAME (sym)[0] > name[0])
+	  else if (SYMBOL_SOURCE_NAME (sym)[0] > name[0])
 	    {
 	      top = inc;
 	    }
-	  else if (STRCMP (SYMBOL_NAME (sym), name) < 0)
+	  else if (STRCMP (SYMBOL_SOURCE_NAME (sym), name) < 0)
 	    {
 	      bot = inc;
 	    }
@@ -1247,19 +1282,8 @@ lookup_block_symbol (register const stru
       while (bot < top)
 	{
 	  sym = BLOCK_SYM (block, bot);
-	  inc = SYMBOL_NAME (sym)[0] - name[0];
-	  if (inc == 0)
-	    {
-	      inc = STRCMP (SYMBOL_NAME (sym), name);
-	    }
-	  if (inc == 0 && SYMBOL_NAMESPACE (sym) == namespace)
-	    {
-	      return (sym);
-	    }
-	  if (inc > 0)
-	    {
-	      break;
-	    }
+	  if (SYMBOL_MATCHES_NAME (sym, name))
+	    return sym;
 	  bot++;
 	}
     }


Elena



Daniel Berlin writes:
 > 
 > Once again, I don't have a changelog handy to paste from.
 > It hasn't changed anyway, unless i'm misremembering.
 > I have an exam tomorrow, so it's quite possible i *am* misremembering,
 > and someone did request changelog modifications to the previous patch.
 > 
 > 
 > Elena, this includes the suggested modifications to lookup_symbol, so
 > that needstofreename gets initialized to 0, reducing the amount of
 > code. I have an odd feeling I missed something when changing that
 > code, so i'd appreciate it if you'd double check it for me.
 > It's probably just my stress level, but ....
 > 
 > Index: symfile.c
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/symfile.c,v
 > retrieving revision 1.18
 > diff -c -3 -p -r1.18 symfile.c
 > *** symfile.c	2000/09/02 00:09:06	1.18
 > --- symfile.c	2000/10/11 03:55:07
 > *************** compare_symbols (const PTR s1p, const PT
 > *** 212,219 ****
 >   
 >     s1 = (struct symbol **) s1p;
 >     s2 = (struct symbol **) s2p;
 > ! 
 > !   return (STRCMP (SYMBOL_NAME (*s1), SYMBOL_NAME (*s2)));
 >   }
 >   
 >   /*
 > --- 212,218 ----
 >   
 >     s1 = (struct symbol **) s1p;
 >     s2 = (struct symbol **) s2p;
 > !   return (STRCMP (SYMBOL_SOURCE_NAME (*s1), SYMBOL_SOURCE_NAME (*s2)));
 >   }
 >   
 >   /*
 > *************** compare_symbols (const PTR s1p, const PT
 > *** 241,248 ****
 >   static int
 >   compare_psymbols (const PTR s1p, const PTR s2p)
 >   {
 > !   register char *st1 = SYMBOL_NAME (*(struct partial_symbol **) s1p);
 > !   register char *st2 = SYMBOL_NAME (*(struct partial_symbol **) s2p);
 >   
 >     if ((st1[0] - st2[0]) || !st1[0])
 >       {
 > --- 240,253 ----
 >   static int
 >   compare_psymbols (const PTR s1p, const PTR s2p)
 >   {
 > !   register struct partial_symbol **s1, **s2;
 > !   register char *st1, *st2;
 > ! 
 > !   s1 = (struct partial_symbol **) s1p;
 > !   s2 = (struct partial_symbol **) s2p;
 > !   st1 = SYMBOL_SOURCE_NAME (*s1);
 > !   st2 = SYMBOL_SOURCE_NAME (*s2);
 > ! 
 >   
 >     if ((st1[0] - st2[0]) || !st1[0])
 >       {
 > Index: symtab.c
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/symtab.c,v
 > retrieving revision 1.15
 > diff -c -3 -p -r1.15 symtab.c
 > *** symtab.c	2000/09/04 08:29:25	1.15
 > --- symtab.c	2000/10/11 03:55:08
 > *************** static struct partial_symbol *lookup_par
 > *** 83,88 ****
 > --- 83,95 ----
 >   
 >   static struct symtab *lookup_symtab_1 (char *);
 >   
 > + static struct symbol *lookup_symbol_aux (const char *name, const
 > + 					 struct block *block, const
 > + 					 namespace_enum namespace, int
 > + 					 *is_a_field_of_this, struct
 > + 					 symtab **symtab);
 > + 
 > + 
 >   static void cplusplus_hint (char *);
 >   
 >   static struct symbol *find_active_alias (struct symbol *sym, CORE_ADDR addr);
 > *************** fixup_psymbol_section (struct partial_sy
 > *** 572,588 ****
 >      can probably assume it will never hit the C++ code).  */
 >   
 >   struct symbol *
 > ! lookup_symbol (const char *name, register const struct block *block,
 >   	       const namespace_enum namespace, int *is_a_field_of_this,
 >   	       struct symtab **symtab)
 >   {
 > !   register struct symbol *sym;
 > !   register struct symtab *s = NULL;
 > !   register struct partial_symtab *ps;
 > !   struct blockvector *bv;
 > !   register struct objfile *objfile = NULL;
 > !   register struct block *b;
 > !   register struct minimal_symbol *msymbol;
 >   
 >     if (case_sensitivity == case_sensitive_off)
 >       {
 > --- 565,578 ----
 >      can probably assume it will never hit the C++ code).  */
 >   
 >   struct symbol *
 > ! lookup_symbol (const char *name, const struct block *block,
 >   	       const namespace_enum namespace, int *is_a_field_of_this,
 >   	       struct symtab **symtab)
 >   {
 > !   char *modified_name = NULL;
 > !   char *modified_name2 = NULL;
 > !   int needtofreename=0;
 > !   struct symbol *returnval;
 >   
 >     if (case_sensitivity == case_sensitive_off)
 >       {
 > *************** lookup_symbol (const char *name, registe
 > *** 594,601 ****
 >         for (i= 0; i < len; i++)
 >           copy[i] = tolower (name[i]);
 >         copy[len] = 0;
 > !       name = copy;
 >       }
 >   
 >     /* Search specified block and its superiors.  */
 >   
 > --- 584,630 ----
 >         for (i= 0; i < len; i++)
 >           copy[i] = tolower (name[i]);
 >         copy[len] = 0;
 > !       modified_name = copy;
 >       }
 > +   else 
 > +     {    
 > +       modified_name = (char *)name;
 > +     }
 > +   modified_name2 = modified_name; 
 > +   /* If we are using C++ language, demangle the name before doing a lookup, so
 > +      we can always binary search. */
 > +   if (current_language->la_language == language_cplus)
 > +     {
 > +       modified_name2 = cplus_demangle (modified_name, DMGL_ANSI |
 > + 				       DMGL_PARAMS);
 > +       needtofreename=1;
 > +     }
 > +   
 > +   if (!modified_name2)
 > +     {
 > +       modified_name2 = modified_name;
 > +     }
 > +   returnval = lookup_symbol_aux (modified_name2, block, namespace,
 > + 				 is_a_field_of_this, symtab);
 > +   if (needtofreename)
 > +     free(modified_name2);
 > + 
 > +   return returnval;	 
 > + }
 > + 
 > + static struct symbol *
 > + lookup_symbol_aux (const char *name, const struct block *block,
 > + 	       const namespace_enum namespace, int *is_a_field_of_this,
 > + 	       struct symtab **symtab)
 > + {
 > +   register struct symbol *sym;
 > +   register struct symtab *s = NULL;
 > +   register struct partial_symtab *ps;
 > +   register struct blockvector *bv;
 > +   register struct objfile *objfile = NULL;
 > +   register struct block *b;
 > +   register struct minimal_symbol *msymbol;
 > + 
 >   
 >     /* Search specified block and its superiors.  */
 >   
 > *************** lookup_partial_symbol (struct partial_sy
 > *** 987,993 ****
 >   	    {
 >   	      do_linear_search = 1;
 >   	    }
 > ! 	  if (STRCMP (SYMBOL_NAME (*center), name) >= 0)
 >   	    {
 >   	      top = center;
 >   	    }
 > --- 1017,1023 ----
 >   	    {
 >   	      do_linear_search = 1;
 >   	    }
 > ! 	  if (STRCMP (SYMBOL_SOURCE_NAME (*center), name) >= 0)
 >   	    {
 >   	      top = center;
 >   	    }
 > *************** lookup_block_symbol (register const stru
 > *** 1190,1198 ****
 >       {
 >         /* Reset the linear search flag so if the binary search fails, we
 >            won't do the linear search once unless we find some reason to
 > !          do so, such as finding a C++ symbol during the binary search.
 > !          Note that for C++ modules, ALL the symbols in a block should
 > !          end up marked as C++ symbols. */
 >   
 >         do_linear_search = 0;
 >         top = BLOCK_NSYMS (block);
 > --- 1220,1226 ----
 >       {
 >         /* Reset the linear search flag so if the binary search fails, we
 >            won't do the linear search once unless we find some reason to
 > !          do so */
 >   
 >         do_linear_search = 0;
 >         top = BLOCK_NSYMS (block);
 > *************** lookup_block_symbol (register const stru
 > *** 1210,1231 ****
 >   	    }
 >   	  inc = (inc >> 1) + bot;
 >   	  sym = BLOCK_SYM (block, inc);
 > ! 	  if (!do_linear_search
 > ! 	      && (SYMBOL_LANGUAGE (sym) == language_cplus
 > ! 		  || SYMBOL_LANGUAGE (sym) == language_java
 > ! 	      ))
 >   	    {
 >   	      do_linear_search = 1;
 >   	    }
 > ! 	  if (SYMBOL_NAME (sym)[0] < name[0])
 >   	    {
 >   	      bot = inc;
 >   	    }
 > ! 	  else if (SYMBOL_NAME (sym)[0] > name[0])
 >   	    {
 >   	      top = inc;
 >   	    }
 > ! 	  else if (STRCMP (SYMBOL_NAME (sym), name) < 0)
 >   	    {
 >   	      bot = inc;
 >   	    }
 > --- 1238,1256 ----
 >   	    }
 >   	  inc = (inc >> 1) + bot;
 >   	  sym = BLOCK_SYM (block, inc);
 > ! 	  if (!do_linear_search && (SYMBOL_LANGUAGE (sym) == language_java))
 >   	    {
 >   	      do_linear_search = 1;
 >   	    }
 > ! 	  if (SYMBOL_SOURCE_NAME (sym)[0] < name[0])
 >   	    {
 >   	      bot = inc;
 >   	    }
 > ! 	  else if (SYMBOL_SOURCE_NAME (sym)[0] > name[0])
 >   	    {
 >   	      top = inc;
 >   	    }
 > ! 	  else if (STRCMP (SYMBOL_SOURCE_NAME (sym), name) < 0)
 >   	    {
 >   	      bot = inc;
 >   	    }
 > *************** lookup_block_symbol (register const stru
 > *** 1247,1265 ****
 >         while (bot < top)
 >   	{
 >   	  sym = BLOCK_SYM (block, bot);
 > ! 	  inc = SYMBOL_NAME (sym)[0] - name[0];
 > ! 	  if (inc == 0)
 > ! 	    {
 > ! 	      inc = STRCMP (SYMBOL_NAME (sym), name);
 > ! 	    }
 > ! 	  if (inc == 0 && SYMBOL_NAMESPACE (sym) == namespace)
 > ! 	    {
 > ! 	      return (sym);
 > ! 	    }
 > ! 	  if (inc > 0)
 > ! 	    {
 > ! 	      break;
 > ! 	    }
 >   	  bot++;
 >   	}
 >       }
 > --- 1272,1279 ----
 >         while (bot < top)
 >   	{
 >   	  sym = BLOCK_SYM (block, bot);
 > ! 	  if (SYMBOL_MATCHES_NAME (sym, name))
 > ! 	    return sym;
 >   	  bot++;
 >   	}
 >       }
 > 
 > 
From ezannoni@cygnus.com Thu Oct 12 12:35:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Daniel Berlin <dberlin@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] Mangling, take 2
Date: Thu, 12 Oct 2000 12:35:00 -0000
Message-id: <14822.4725.826556.108136@kwikemart.cygnus.com>
References: <m3lmvwdo71.fsf@dan2.cygnus.com>
X-SW-Source: 2000-10/msg00077.html
Content-length: 4857

I committed this one as well. With a ChangeLog entry!

Elena


Daniel Berlin writes:
 > This should be correct.
 > I don't have the changelogs handy to paste, I finally just checked out 5
 > seperate copies of the gdb tree so I could do rediffs there.
 > 
 > 
 > Any problems with this one that I missed?
 > Index: symtab.c
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/symtab.c,v
 > retrieving revision 1.15
 > diff -c -3 -p -r1.15 symtab.c
 > *** symtab.c	2000/09/04 08:29:25	1.15
 > --- symtab.c	2000/10/11 03:50:53
 > *************** gdb_mangle_name (struct type *type, int 
 > *** 296,301 ****
 > --- 303,311 ----
 >     char buf[20];
 >     int len = (newname == NULL ? 0 : strlen (newname));
 >   
 > +   if (OPNAME_PREFIX_P (field_name))
 > +     return xstrdup(physname);
 > + 
 >     is_full_physname_constructor =
 >       ((physname[0] == '_' && physname[1] == '_' &&
 >         (isdigit (physname[2]) || physname[2] == 'Q' || physname[2] == 't'))
 > *************** gdb_mangle_name (struct type *type, int 
 > *** 331,357 ****
 >         sprintf (buf, "__%s%s%d", const_prefix, volatile_prefix, len);
 >       }
 >     mangled_name_len = ((is_constructor ? 0 : strlen (field_name))
 > ! 		      + strlen (buf) + len
 > ! 		      + strlen (physname)
 > ! 		      + 1);
 >   
 > -   /* Only needed for GNU-mangled names.  ANSI-mangled names
 > -      work with the normal mechanisms.  */
 > -   if (OPNAME_PREFIX_P (field_name))
 >       {
 > -       const char *opname = cplus_mangle_opname (field_name + 3, 0);
 > -       if (opname == NULL)
 > - 	error ("No mangling for \"%s\"", field_name);
 > -       mangled_name_len += strlen (opname);
 >         mangled_name = (char *) xmalloc (mangled_name_len);
 > - 
 > -       strncpy (mangled_name, field_name, 3);
 > -       mangled_name[3] = '\0';
 > -       strcat (mangled_name, opname);
 > -     }
 > -   else
 > -     {
 > -       mangled_name = (char *) xmalloc (mangled_name_len);
 >         if (is_constructor)
 >   	mangled_name[0] = '\0';
 >         else
 > --- 341,350 ----
 >         sprintf (buf, "__%s%s%d", const_prefix, volatile_prefix, len);
 >       }
 >     mangled_name_len = ((is_constructor ? 0 : strlen (field_name))
 > ! 		      + strlen (buf) + len + strlen (physname) + 1);
 >   
 >       {
 >         mangled_name = (char *) xmalloc (mangled_name_len);
 >         if (is_constructor)
 >   	mangled_name[0] = '\0';
 >         else
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/symtab.h,v
 > retrieving revision 1.13
 > diff -c -3 -p -r1.13 symtab.h
 > *** symtab.h	2000/08/07 15:02:48	1.13
 > --- symtab.h	2000/10/11 03:50:53
 > *************** extern CORE_ADDR symbol_overlayed_addres
 > *** 170,175 ****
 > --- 170,177 ----
 >   #define SYMBOL_INIT_DEMANGLED_NAME(symbol,obstack)			\
 >     do {									\
 >       char *demangled = NULL;						\
 > +     if (SYMBOL_LANGUAGE (symbol) == language_unknown)                 \
 > +           SYMBOL_LANGUAGE(symbol) = language_auto;                    \
 >       if (SYMBOL_LANGUAGE (symbol) == language_cplus			\
 >   	|| SYMBOL_LANGUAGE (symbol) == language_auto)			\
 >         {									\
 > *************** extern CORE_ADDR symbol_overlayed_addres
 > *** 222,231 ****
 >   	    SYMBOL_CHILL_DEMANGLED_NAME (symbol) = NULL;		\
 >   	  }								\
 >         }									\
 > -     if (SYMBOL_LANGUAGE (symbol) == language_auto)			\
 > -       {									\
 > - 	SYMBOL_LANGUAGE (symbol) = language_unknown;			\
 > -       }									\
 >     } while (0)
 >   
 >   /* Macro that returns the demangled name for a symbol based on the language
 > --- 224,229 ----
 > *************** struct partial_symtab
 > *** 1047,1059 ****
 >   #define VTBL_FNADDR_OFFSET 2
 >   
 >   /* Macro that yields non-zero value iff NAME is the prefix for C++ operator
 > !    names.  If you leave out the parenthesis here you will lose!
 > !    Currently 'o' 'p' CPLUS_MARKER is used for both the symbol in the
 > !    symbol-file and the names in gdb's symbol table.
 > !    Note that this macro is g++ specific (FIXME). */
 > ! 
 >   #define OPNAME_PREFIX_P(NAME) \
 > !   ((NAME)[0] == 'o' && (NAME)[1] == 'p' && is_cplus_marker ((NAME)[2]))
 >   
 >   /* Macro that yields non-zero value iff NAME is the prefix for C++ vtbl
 >      names.  Note that this macro is g++ specific (FIXME).
 > --- 1045,1053 ----
 >   #define VTBL_FNADDR_OFFSET 2
 >   
 >   /* Macro that yields non-zero value iff NAME is the prefix for C++ operator
 > !    names.  If you leave out the parenthesis here you will lose!  */
 >   #define OPNAME_PREFIX_P(NAME) \
 > !   (!strncmp(NAME,"operator",8))
 >   
 >   /* Macro that yields non-zero value iff NAME is the prefix for C++ vtbl
 >      names.  Note that this macro is g++ specific (FIXME).
 > 
 > 
 > 
From kevinb@cygnus.com Thu Oct 12 15:02:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFC] Protoize remote-rdp.c, remote-sds.c, remote-sim.c
Date: Thu, 12 Oct 2000 15:02:00 -0000
Message-id: <1001012220154.ZM6317@ocotillo.lan>
References: <1001010054414.ZM1389@ocotillo.lan> <kevinb@cygnus.com>
X-SW-Source: 2000-10/msg00078.html
Content-length: 223

On Oct 9, 10:44pm, Kevin Buettner wrote:

> 	* remote-rdp.c (remote_rdp_xfer_inferior_memory): Protoize.
> 	* remote-sds.c (sds_xfer_memory): Protoize.
> 	* remote-sim.c (gdbsim_xfer_inferior_memory): Protoize.

Committed.
From kevinb@cygnus.com Thu Oct 12 15:05:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH RFC] Protoize remote-st.c, remote-utils.c, remote-vx.c
Date: Thu, 12 Oct 2000 15:05:00 -0000
Message-id: <1001012220502.ZM6323@ocotillo.lan>
X-SW-Source: 2000-10/msg00079.html
Content-length: 3446

More protoization...

Again, a FIXME comment was removed for reasons previously cited.

	* remote-st.c (st2000_xfer_inferior_memory): Protoize.
	* remote-utils.c (gr_multi_scan): Protoize.
	* remote-vx.c (vx_xfer_memory, net_get_symbols): Protoize.

Index: remote-st.c
===================================================================
RCS file: /cvs/src/src/gdb/remote-st.c,v
retrieving revision 1.4
diff -u -r1.4 remote-st.c
--- remote-st.c	2000/09/01 00:12:10	1.4
+++ remote-st.c	2000/10/12 21:48:44
@@ -548,14 +548,15 @@
   return len;
 }
 
-/* FIXME-someday!  Merge these two.  */
+/* Transfer LEN bytes between GDB address MYADDR and target address
+   MEMADDR.  If WRITE is non-zero, transfer them to the target,
+   otherwise transfer them from the target.  TARGET is unused.
+
+   Returns the number of bytes transferred. */
+
 static int
-st2000_xfer_inferior_memory (memaddr, myaddr, len, write, target)
-     CORE_ADDR memaddr;
-     char *myaddr;
-     int len;
-     int write;
-     struct target_ops *target;	/* ignored */
+st2000_xfer_inferior_memory (CORE_ADDR memaddr, char *myaddr, int len,
+			     int write, struct target_ops *target)
 {
   if (write)
     return st2000_write_inferior_memory (memaddr, myaddr, len);
Index: remote-utils.c
===================================================================
RCS file: /cvs/src/src/gdb/remote-utils.c,v
retrieving revision 1.7
diff -u -r1.7 remote-utils.c
--- remote-utils.c	2000/09/01 00:12:10	1.7
+++ remote-utils.c	2000/10/12 21:48:44
@@ -502,9 +502,7 @@
    pass non-matching data on.  */
 
 int
-gr_multi_scan (list, passthrough)
-     char *list[];
-     int passthrough;
+gr_multi_scan (char *list[], int passthrough)
 {
   char *swallowed = NULL;	/* holding area */
   char *swallowed_p = swallowed;	/* Current position in swallowed.  */
Index: remote-vx.c
===================================================================
RCS file: /cvs/src/src/gdb/remote-vx.c,v
retrieving revision 1.7
diff -u -r1.7 remote-vx.c
--- remote-vx.c	2000/08/27 22:30:29	1.7
+++ remote-vx.c	2000/10/12 21:48:46
@@ -468,19 +468,15 @@
 
 /* Copy LEN bytes to or from remote inferior's memory starting at MEMADDR
    to debugger memory starting at MYADDR.  WRITE is true if writing to the
-   inferior.
+   inferior.  TARGET is unused.
    Result is the number of bytes written or read (zero if error).  The
    protocol allows us to return a negative count, indicating that we can't
    handle the current address but can handle one N bytes further, but
    vxworks doesn't give us that information.  */
 
 static int
-vx_xfer_memory (memaddr, myaddr, len, write, target)
-     CORE_ADDR memaddr;
-     char *myaddr;
-     int len;
-     int write;
-     struct target_ops *target;	/* ignored */
+vx_xfer_memory (CORE_ADDR memaddr, char *myaddr, int len, int write,
+		struct target_ops *target)
 {
   int status;
   Rptrace ptrace_in;
@@ -800,14 +796,14 @@
   return (status == RPC_SUCCESS) ? 0 : -1;
 }
 
-/* Fetch a list of loaded object modules from the VxWorks target.
+/* Fetch a list of loaded object modules from the VxWorks target
+   and store in PLOADTABLE.
    Returns -1 if rpc failed, 0 otherwise
    There's no way to check if the returned loadTable is correct.
    VxWorks doesn't check it.  */
 
 static int
-net_get_symbols (pLoadTable)
-     ldtabl *pLoadTable;	/* return pointer to ldtabl here */
+net_get_symbols (ldtabl *pLoadTable)
 {
   enum clnt_stat status;