From: Michael Snyder <msnyder@cygnus.com>
To: Daniel Berlin <dberlin@redhat.com>
Cc: Michael Elizabeth Chastain <chastain@cygnus.com>,
gdb-patches@sources.redhat.com
Subject: Re: [PATCH] New C++ abstraction patch
Date: Wed, 21 Feb 2001 11:53:00 -0000 [thread overview]
Message-ID: <3A941CBE.F1604F19@cygnus.com> (raw)
In-Reply-To: <x7y9v0xz1w.fsf@dynamic-addr-83-177.resnet.rochester.edu>
Daniel Berlin wrote:
>
> Michael Elizabeth Chastain <chastain@cygnus.com> writes:
>
> > Hi Daniel,
> >
> > > I plan on using [^0-9]D[1-3]Ev$
> >
> > I am suspicious of the [^0-9] part. I just made a class named "B1",
> > and its destructor name is "_ZN2B1D2Ev". Indeed, I can't figure out
> > what problem the [^0-9] is trying to solve anyways.
>
> Make sure it's not the beginning of a name accidently.
> Of course, it's pointless, but I added it before I added the "ends in
> Ev" rule.
>
> I think the right thing is to do "^_Z.*[1-9][a-zA-Z_][a-zA-Z0-9_]+D[0-2]Ev$", since the class
> name always comes right before the destructor.
> This also makes sure we don't accidently get the classname, even if
> it's D[0-2].
>
> I generated this regex from staring at the demangler for a while.
> :)
>
> It's really (to break it down in case you see a part i've gotten wrong)
> _Z.*<mangled classname regex><mangled destructor name regex>Ev$
>
> 1-9 because you can't have a class name of length 0.
>
> I think i have a few valid identifier characters missing, i'll double
> check it if you think this regex would work if i added them.
>
> Otherwise, i'll look at cleaning up the ternary search tree stuff for
> demangled names and submitting it.
>
> Temporarily, of course, i'm more than happy to just take the speed hit
> in the name of correctness, and getting v3 abi supported properly.
When you speak of a speed hit, are you speaking of symbol-file-load time,
or expression evaluation time? I think expression evaluation is far
less important to optimize for speed than symbol loading. Lots of people
complain about the time gdb takes to start up on a new symbol file, while
very few (that I'm aware of) complain about the performance during
expression evaluation.
next prev parent reply other threads:[~2001-02-21 11:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-20 20:42 Michael Elizabeth Chastain
2001-02-20 23:42 ` Daniel Berlin
2001-02-21 11:53 ` Michael Snyder [this message]
2001-02-21 14:24 ` J.T. Conklin
2001-02-21 15:21 ` Michael Snyder
-- strict thread matches above, loose matches on Subject: below --
2001-02-21 7:43 Michael Elizabeth Chastain
2001-02-20 17:35 Michael Elizabeth Chastain
2001-02-20 19:42 ` Daniel Berlin
2001-02-21 10:42 ` Andrew Cagney
2001-02-21 13:03 ` Daniel Berlin
2001-02-21 13:25 ` Andrew Cagney
2001-02-21 15:19 ` Michael Snyder
2001-02-22 8:14 ` Andrew Cagney
2001-02-20 16:02 Daniel Berlin
2001-02-21 1:53 ` Eli Zaretskii
2001-02-21 10:56 ` Andrew Cagney
2001-02-21 13:31 ` Daniel Berlin
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=3A941CBE.F1604F19@cygnus.com \
--to=msnyder@cygnus.com \
--cc=chastain@cygnus.com \
--cc=dberlin@redhat.com \
--cc=gdb-patches@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