From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Snyder To: Daniel Berlin Cc: Michael Elizabeth Chastain , gdb-patches@sources.redhat.com Subject: Re: [PATCH] New C++ abstraction patch Date: Wed, 21 Feb 2001 11:53:00 -0000 Message-id: <3A941CBE.F1604F19@cygnus.com> References: <200102210442.UAA21584@bosch.cygnus.com> X-SW-Source: 2001-02/msg00429.html Daniel Berlin wrote: > > Michael Elizabeth Chastain 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.*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.