Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Berlin <dan@cgsoftware.com>
To: Michael Elizabeth Chastain <chastain@cygnus.com>
Cc: dan@cgsoftware.com, gdb@sources.redhat.com
Subject: Re: So what is wrong with v3 C++
Date: Fri, 29 Jun 2001 08:59:00 -0000	[thread overview]
Message-ID: <87zoarjn08.fsf@cgsoftware.com> (raw)
In-Reply-To: <200106290532.WAA01150@bosch.cygnus.com>

Michael Elizabeth Chastain <chastain@cygnus.com> writes:

> Dan Berlin writes:
>> 1. Template functions (names or types) have return types encoded,
>>    with the exceptions listed below.
> 
> Okay, we must comply with the ABI, then.
> 
>> You seem to want to get rid of return types from mangled names for
>> templates. This ain't gonna ever happen. It's done on purpose, it's
>> not an accident.
> 
> No, first I want to know what the spec requires.  The ABI spec wants the
> information to be present in the mangled name.  Now follow the information
> flow:
> 
>   mangled name -> demangled name (demangler)
>   demangled name -> user visible and user matchable names (gdb)
> 
> I accept the ABI spec, and I'm comfortable with the demangler preserving
> all the information including the return type.
> 
> We still have to figure out what to do if the user types:
> 
>   (gdb) break add_two_values
> 
> ... when add_two_values is a template.

Sure. 
What we really should be doing is something like find_methods, except
including templates.
That way, we could present a list like:

add_two_values<int, int>
add_two_values<float, int>

And let the user decide which ones they wanted breakpointed.

> 
> One option is to propagate this "return type in the name" all the way
> through to the user, and mention it in the documentation.  So the
> user really would have to type:
> 
>   (gdb) break 'int add_two_values<int,int>TAB
Oh, I see what you mean.

However, note, the new dwarf2 reader should fix this problem as well.

It was the reliance on mangled names that gave the return type.

Ah, yes.
Hand verified to be mostly fixed in the new d2 reader.

(gdb) b 'add_two_values<int>'
Breakpoint 1 at 0x10000830: file test2.cc, line 3.
(gdb)


There is a mismatch in the new d2 reader between psymbol names and
symbol names, because i haven't quite gotten scoping into the
psymbols.  So if you did "info func add", it would show
"int add_two_values<int> (int, int)".

However, this bug also causes b 'int add_two_values<int> (int, int)'
to work, just like it used to.
:)

STABS isn't possible to fix without generating it's own qualified
names, which won't work with namespaces.

So we'll probably need to document the difference anyway.

> 
>> LD, c++filt, nm, objdump, etc all use it.
>> GDB seems to *depend* on it more, but this is not a good thing. We
>> depend on mangled names too much.
> 
> nm, objdump, and c++filt just use demangling in their output.
> As far as I know, ld operates the same way.  Does it ever demangle a name
> and use the result for anything except error printing?

I have no idea. I'll check.
> 
> gdb is the only tool I know where people type in names and the tool
> has to match against demangled forms.

The thing is, it shouldn't match against demangled forms, it should
match against *fully qualified* forms.

When talking about symbols in C++, do you say "Yeah, look at the int
a::b(int a, int b) function." or "Yeah, look at the a::b function".

The whole reason we do demangled forms is because of limitations of
STABS (lack of namespace support, etc) that don't allow us to do full
qualified names.

However, using demangled forms gives us an interface that isn't quite
what the user expects, and causes us problems elsewhere.

It's okay to use the internally, but we really shouldn't expose them
to the user.

Think of it as if you had to write code like this:

int main(void)
{
        Aclass a;
        int c;
        c = int a::george(int, int)(5, 6);
}
That's what we've got now.

Of course, because STABS *won't* (IIRC, thinks like Third Eye do
support it) allow us to handle namespaces properly, I don't expect to
see this changed, and would fight it, for a few more years, until
STABS is much less prevalent.

> 
> If you are suggesting that the demangler should return a nice tree
> of information, instead of gdb doing its own re-parsing, I'm in favor
> of that.
> 
>> I've already rewritten the dwarf2 reader, including the scope work.
>> There would be little point in JimB rewriting it again.
> 
> I saw the patch.
> 
> Do you have any test results, or plans for getting it tested?

Yes. 
After I fix the known bugs, i'm going to start running the regression
tests and fixing those bugs.

Once we either end up with no regressions, or doing better than we
used to, i'll submit it for approval.

> 
> Michael

-- 
"I owed my friend George $25.  For about three weeks I owed it to
him.  The whole time I had the money on me -- he didn't know it.
Walking through New York City, 2:30 in the morning and got held
up.  He said, "Gimme all your money."  I said, "Wait a minute."
I said, "George, here's the 25 dollars I owe you."  The the
thief took a thousand dollars out of his own money and he gave
it to George.  At gunpoint made me borrow a thousand dollars
from George.
"-Steven Wright


  reply	other threads:[~2001-06-29  8:59 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-28 23:31 Michael Elizabeth Chastain
2001-06-29  8:59 ` Daniel Berlin [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-07-02 14:54 Benjamin Kosnik
2001-06-29 11:57 Benjamin Kosnik
2001-07-02 20:28 ` Per Bothner
2001-06-29 10:28 Michael Elizabeth Chastain
2001-06-29 11:40 ` Daniel Berlin
2001-06-29  0:56 Michael Elizabeth Chastain
2001-06-28 23:50 Michael Elizabeth Chastain
2001-06-29  8:59 ` Daniel Berlin
2001-06-28 20:42 Michael Elizabeth Chastain
2001-06-28 20:44 ` Christopher Faylor
2001-06-28 23:10   ` Daniel Berlin
2001-06-28 23:08 ` Daniel Berlin
2001-06-29  0:29 ` Tom Tromey
2001-06-28 18:12 Michael Elizabeth Chastain
2001-06-28 19:06 ` Daniel Berlin
2001-06-28 16:28 Andrew Cagney
2001-06-28 18:59 ` Daniel Berlin
2001-06-29 13:40 ` Jim Blandy
2001-06-29 23:15   ` Daniel Berlin
2001-06-30 10:06     ` Jim Blandy
2001-06-30 12:30       ` Daniel Berlin
2001-07-02  9:01         ` Jim Blandy
2001-07-04  9:22   ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zoarjn08.fsf@cgsoftware.com \
    --to=dan@cgsoftware.com \
    --cc=chastain@cygnus.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox