cp-name-parser.y

cp-name-parser.y

[Aleksandar Ristovski]

Hello,

Is it just me or is cpname_parse really not being used at all? I see there has 
been some effort put into parsing c++ specific sutff, but is it unfinished, or 
what is going on?

If you could, let me know how mature is that code there and can it be used.

Thanks,

Aleksandar Ristovski
QNX Software Systems

Re: cp-name-parser.y

[Daniel Jacobowitz]

On Fri, Feb 29, 2008 at 01:22:00PM -0500, Aleksandar Ristovski wrote:
> Hello,
>
> Is it just me or is cpname_parse really not being used at all? I see there 
> has been some effort put into parsing c++ specific sutff, but is it 
> unfinished, or what is going on?
>
> If you could, let me know how mature is that code there and can it be used.

What would you like to use it for?

It's not used yet for much.  I have a patch, most recently posted
around the end of October 2007, which uses it for every C++ symbol
we read in.  That's to fix symbol lookup issues for templates, and
so forth.  But the patch is a bit of a slowdown and I want to look at
your speedups first before I go there.  I'll be doing that soon.

-- 
Daniel Jacobowitz
CodeSourcery

Re: cp-name-parser.y

[Aleksandar Ristovski]

Daniel Jacobowitz wrote:
> On Fri, Feb 29, 2008 at 01:22:00PM -0500, Aleksandar Ristovski wrote:
>> Hello,
>>
>> If you could, let me know how mature is that code there and can it be used.
> 
> What would you like to use it for?
> 

I am looking at that since right now something like this:

-var-create - * "(anonymous namespace)::foobar"

will not work since c_parse doesn't know anything about '(anonymous namespace)'. 
I guess it wouldn't be too hard to hack around this particular case, but a 
proper solution would be preferable.

I see that language_defn for c++ uses c_preprocess_and_parse but there should 
probably be something like cp_preprocess_and_parse, sharing the macro handling 
part but calling cpname_parse instead of c_parse. Or maybe calling cpname_parse 
if c_parse fails.

The issue is evident when using IDE (CDT). IDE will call
ptype foobar
which prints type (correctly) something like this: '(anonymous 
namespace)::FooBar' and then IDE uses this string as argument to -var-create, 
but unfortunately, this doesn't work.

Re: cp-name-parser.y

[Daniel Jacobowitz]

On Fri, Feb 29, 2008 at 02:09:13PM -0500, Aleksandar Ristovski wrote:
> I am looking at that since right now something like this:
>
> -var-create - * "(anonymous namespace)::foobar"
>
> will not work since c_parse doesn't know anything about '(anonymous 
> namespace)'. I guess it wouldn't be too hard to hack around this 
> particular case, but a proper solution would be preferable.

I wonder what the right thing to do on a statement like that is.  The
problem with anonymous namespaces is that we call them all "(anonymous
namespace)", but they're many different namespaces, one for each file
with anonymous namespaces.  In that file, you would access the type
as just "foobar".  Maybe we should give each anonymous namespace
a different name.

Anyway, cp-name-parser.y isn't a replacement for c-exp.y.  It's a name
parser; it accepts both names and types in cases where we don't know
which are which, and it does not support any expressions except when
they can appear inside a template argument.  Once you've identified
something as a symbol name then you might hand it off to this parser
to find the canonical form of the name, before searching the symbol
table.

> The issue is evident when using IDE (CDT). IDE will call
> ptype foobar
> which prints type (correctly) something like this: '(anonymous  
> namespace)::FooBar' and then IDE uses this string as argument to 
> -var-create, but unfortunately, this doesn't work.

(Why are you creating a varobj for a type, anyway?)

-- 
Daniel Jacobowitz
CodeSourcery

Re: cp-name-parser.y

[Aleksandar Ristovski]

Daniel Jacobowitz wrote:
> On Fri, Feb 29, 2008 at 02:09:13PM -0500, Aleksandar Ristovski wrote:
>> I am looking at that since right now something like this:
>>
>> -var-create - * "(anonymous namespace)::foobar"
>>
>> will not work since c_parse doesn't know anything about '(anonymous 
>> namespace)'. I guess it wouldn't be too hard to hack around this 
>> particular case, but a proper solution would be preferable.
> 
> I wonder what the right thing to do on a statement like that is.  The
> problem with anonymous namespaces is that we call them all "(anonymous
> namespace)", but they're many different namespaces, one for each file
> with anonymous namespaces.  In that file, you would access the type
> as just "foobar".  Maybe we should give each anonymous namespace
> a different name.
I am not sure, but unique name should already be available in the form of 
mangled name (to me, at a first glance, creating unique names doesn't sound like 
a good idea).

However, in the case I am talking about, it is known which anonymous namespace 
is relevant since we have the frame, so really the only thing that is missing is 
to recognize that '(anonymous namespace)' could, effectively, be removed from 
the type name and then using the 'bare' var name crawl up the blocks to find the 
matching visible var in the given context. But I am not 100% sure the solution 
is generic.

> 
> Anyway, cp-name-parser.y isn't a replacement for c-exp.y.  It's a name
> parser; it accepts both names and types in cases where we don't know
> which are which, and it does not support any expressions except when
> they can appear inside a template argument.  Once you've identified
> something as a symbol name then you might hand it off to this parser
> to find the canonical form of the name, before searching the symbol
> table.
ok. So we could, perhaps, use it if c_parse fails and the language is c++?
> 
>> The issue is evident when using IDE (CDT). IDE will call
>> ptype foobar
>> which prints type (correctly) something like this: '(anonymous  
>> namespace)::FooBar' and then IDE uses this string as argument to 
>> -var-create, but unfortunately, this doesn't work.
> 
> (Why are you creating a varobj for a type, anyway?)
> 
In the example above 'foobar' is a variable defined in the anon. namespace, and 
'FooBar' is class name, and my last comment is not precise; IDE uses the 
variable name correctly but I am not familiar with internals on what does it do 
to build that name. In any case, the '(anonymous namespace)' part comes from gdb.

Re: cp-name-parser.y

[Daniel Jacobowitz]

On Fri, Feb 29, 2008 at 02:49:25PM -0500, Aleksandar Ristovski wrote:
> Daniel Jacobowitz wrote:
>> On Fri, Feb 29, 2008 at 02:09:13PM -0500, Aleksandar Ristovski wrote:
>>> I am looking at that since right now something like this:
>>>
>>> -var-create - * "(anonymous namespace)::foobar"
>>>
>>> will not work since c_parse doesn't know anything about '(anonymous  
>>> namespace)'. I guess it wouldn't be too hard to hack around this  
>>> particular case, but a proper solution would be preferable.
>>
>> I wonder what the right thing to do on a statement like that is.  The
>> problem with anonymous namespaces is that we call them all "(anonymous
>> namespace)", but they're many different namespaces, one for each file
>> with anonymous namespaces.  In that file, you would access the type
>> as just "foobar".  Maybe we should give each anonymous namespace
>> a different name.
> I am not sure, but unique name should already be available in the form of  
> mangled name (to me, at a first glance, creating unique names doesn't 
> sound like a good idea).

Yes, we could take the unique string from the mangled name and call it
(anonymous namespace _MESS_OF_GARBAGE)::foobar, and then recognize
that syntax when we parse expressions.

> However, in the case I am talking about, it is known which anonymous 
> namespace is relevant since we have the frame, so really the only thing 
> that is missing is to recognize that '(anonymous namespace)' could, 
> effectively, be removed from the type name and then using the 'bare' var 
> name crawl up the blocks to find the matching visible var in the given 
> context. But I am not 100% sure the solution is generic.

I don't know how the existing anonymous namespace code works.  It was
David Carlton's work and I wasn't following it at the time.  We need
them internally, to get bare lookup right, but maybe we should not
display them to the user - just call the type "foobar".

If we do that, though, what if there are multiple types named foobar?
Completely legal C++.  Well, no worse than the problem we have in C
anyway - so maybe that's the change we should make.

>> Anyway, cp-name-parser.y isn't a replacement for c-exp.y.  It's a name
>> parser; it accepts both names and types in cases where we don't know
>> which are which, and it does not support any expressions except when
>> they can appear inside a template argument.  Once you've identified
>> something as a symbol name then you might hand it off to this parser
>> to find the canonical form of the name, before searching the symbol
>> table.
> ok. So we could, perhaps, use it if c_parse fails and the language is c++?

No.  The two parsers are for different things.  We could recognize
that things with (anonymous namespace) in them are the names of C++
symbols in c-exp.y.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Re: cp-name-parser.y

[Aleksandar Ristovski]

Daniel Jacobowitz wrote:
> On Fri, Feb 29, 2008 at 02:49:25PM -0500, Aleksandar Ristovski wrote:
>> Daniel Jacobowitz wrote:
>>> On Fri, Feb 29, 2008 at 02:09:13PM -0500, Aleksandar Ristovski wrote:
>>>> I am looking at that since right now something like this:
>>>>
>>>> -var-create - * "(anonymous namespace)::foobar"
>>>>
> 
> Yes, we could take the unique string from the mangled name and call it
> (anonymous namespace _MESS_OF_GARBAGE)::foobar, and then recognize
> that syntax when we parse expressions.
I think _MESS_OF_GARBAGE is already sufficient, without combining it with 
'(anonymous namespace)'. _MESS_OF_GARBAGE is used only if print demangle is off. 
For MI interface, it should (almost always?) be the case.

When '(anonymous namespace)' is used, since it could be any anonymous namespace, 
it is not sufficient to uniquely identify a symbol and therefore we can only use 
this form if there is a valid frame that will give it a context.

In either case, I see nothing wrong with the way it is printed out, I see the 
problem with parsing either of the forms: _MESS_OF_GARBAGE and '(anonymous 
namespace)'. The first can not be parsed due to '.' in it and the latter due to 
'(anonymous namespace)'.

> 
> I don't know how the existing anonymous namespace code works.  It was
> David Carlton's work and I wasn't following it at the time.  We need
> them internally, to get bare lookup right, but maybe we should not
> display them to the user - just call the type "foobar".
I think it's ok the way it works now - makes it clear where it comes from.
> 
> If we do that, though, what if there are multiple types named foobar?
> Completely legal C++.  Well, no worse than the problem we have in C
> anyway - so maybe that's the change we should make.
> 

> 
> We could recognize
> that things with (anonymous namespace) in them are the names of C++
> symbols in c-exp.y.
> 
Or we could write new cp-exp.y for parsing mangled and demangled names (but this 
probably overlaps with cp-name-parser)?

Re: Re: cp-name-parser.y

[Daniel Jacobowitz]

On Mon, Mar 03, 2008 at 12:01:52PM -0500, Aleksandar Ristovski wrote:
> Daniel Jacobowitz wrote:
>> Yes, we could take the unique string from the mangled name and call it
>> (anonymous namespace _MESS_OF_GARBAGE)::foobar, and then recognize
>> that syntax when we parse expressions.
> I think _MESS_OF_GARBAGE is already sufficient, without combining it with  
> '(anonymous namespace)'. _MESS_OF_GARBAGE is used only if print demangle 
> is off. For MI interface, it should (almost always?) be the case.
>
> When '(anonymous namespace)' is used, since it could be any anonymous 
> namespace, it is not sufficient to uniquely identify a symbol and 
> therefore we can only use this form if there is a valid frame that will 
> give it a context.
>
> In either case, I see nothing wrong with the way it is printed out, I see 
> the problem with parsing either of the forms: _MESS_OF_GARBAGE and 
> '(anonymous namespace)'. The first can not be parsed due to '.' in it and 
> the latter due to '(anonymous namespace)'.

Sorry, that's not what I meant.  Any symbol is in one particular
anonymous namespace when we print it out.  So we could print out
which anonymous namespace it's in.

Given this:

namespace A
{
  int x;
  namespace
  {
    int y;
  }
}

using namespace A;
int foo()
{
  return x + y;
}

We get these:

drow@caradoc:~% c++filt _ZN1A1xE
A::x
drow@caradoc:~% c++filt _ZN1A19_GLOBAL__N__ZN1A1xE1yE
A::(anonymous namespace)::y

That mangling is actually "A::_GLOBAL__N__ZN1A1xE::y" according to the
ABI.  We could print out "A::(anonymous namespace A::x)::y".

But I see that this will not work with the latest GCC which just uses
_GLOBAL__N_1 on many platforms.

So the easiest solution may be to ignore "(anonymous namespace)::"
during symbol lookup.

A workaround you could try would be to use quoted symbol names.
Does this work?

-var-create - * "'(anonymous namespace)::foobar'"

-- 
Daniel Jacobowitz
CodeSourcery

Re: cp-name-parser.y

[Aleksandar Ristovski]

Daniel Jacobowitz wrote:
> Sorry, that's not what I meant.  Any symbol is in one particular
> anonymous namespace when we print it out.  So we could print out
> which anonymous namespace it's in.
Oh, ok. Now I see what you meant.
> 
> So the easiest solution may be to ignore "(anonymous namespace)::"
> during symbol lookup.
> 
> A workaround you could try would be to use quoted symbol names.
> Does this work?
> 
> -var-create - * "'(anonymous namespace)::foobar'"
> 
That worked. Thanks.

I will follow up with this, since it looks like there are other issues for the 
IDE. In particular, there seems to be quite a few cases where gdb can not parse 
forms printed by 'ptype'/'whatis'. I see mi equivalent is not implemented yet so 
maybe this should be taken into account then.

Re: cp-name-parser.y

[Daniel Jacobowitz]

On Mon, Mar 03, 2008 at 01:33:30PM -0500, Aleksandar Ristovski wrote:
> That worked. Thanks.
>
> I will follow up with this, since it looks like there are other issues for 
> the IDE. In particular, there seems to be quite a few cases where gdb can 
> not parse forms printed by 'ptype'/'whatis'. I see mi equivalent is not 
> implemented yet so maybe this should be taken into account then.

Yeah.  I am glad I could find a workaround for you, but there is still
a real problem.

-- 
Daniel Jacobowitz
CodeSourcery