[rfc] Be in language c more c++ compatible

[rfc] Be in language c more c++ compatible

[Jan Kratochvil]

Hi,

I always see some terrible C++ GDB bug so I fix in some hours and then find out
it works in GDB when one has `set language c++'.  This usually happens with
artificial testcases like the one today:
	http://sourceware.org/ml/gdb-patches/2011-07/msg00387.html

I was told by Keith it also happens to him.

echo 'class C { typedef int t; t i; } c;'|g++ -c -o 1.o -g -x c++ -

FSF GDB HEAD
(gdb) show language 
The current source language is "auto; currently c".
(gdb) whatis C::t
type = C::t
(gdb) set language c++
(gdb) whatis C::t
type = int

patched FSF GDB HEAD:
(gdb) show language
The current source language is "auto; currently c".
(gdb) whatis C::t
type = int
(gdb) set language c++
(gdb) whatis C::t
type = int

The patch has two parts (two files), each part is sufficient to fix the problem
above.

The first (c-exp.y) part parses those parts of `language c++' which cannot
(I believe - RFC) lead to misinterpretation of any valid C code even in
`language c'.

The second (valops.c) part is there because with `language c++' parsing "C::t"
is straight OP_TYPE handled correctly in evaluate_subexp_standard.  But with
`language c' it gets parsed as OP_SCOPE and I find there a bug, copied the code
there.

Sure this patch is not a complete implementation of the idea, just an
incremental improvement.

No regressions on {x86_64,x86_64-m32,i686}-fedora15-linux-gnu.


Thanks,
Jan


gdb/
2011-07-15  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* c-exp.y (tokentab3, tokentab2): Remove the cxx_only field, comment it.
	(lex_one_token): No longer check them there.
	(yylex): Do not check for language_cplus.
	* valops.c (value_maybe_namespace_elt): Dereference LOC_TYPEDEF for
	EVAL_AVOID_SIDE_EFFECTS.

--- a/gdb/c-exp.y
+++ b/gdb/c-exp.y
@@ -1867,38 +1867,40 @@ struct token
   int cxx_only;
 };
 
+/* cxx_only is not used.  */
 static const struct token tokentab3[] =
   {
-    {">>=", ASSIGN_MODIFY, BINOP_RSH, 0},
-    {"<<=", ASSIGN_MODIFY, BINOP_LSH, 0},
-    {"->*", ARROW_STAR, BINOP_END, 1}
+    {">>=", ASSIGN_MODIFY, BINOP_RSH},
+    {"<<=", ASSIGN_MODIFY, BINOP_LSH},
+    {"->*", ARROW_STAR, BINOP_END}
   };
 
+/* cxx_only is not used.  */
 static const struct token tokentab2[] =
   {
-    {"+=", ASSIGN_MODIFY, BINOP_ADD, 0},
-    {"-=", ASSIGN_MODIFY, BINOP_SUB, 0},
-    {"*=", ASSIGN_MODIFY, BINOP_MUL, 0},
-    {"/=", ASSIGN_MODIFY, BINOP_DIV, 0},
-    {"%=", ASSIGN_MODIFY, BINOP_REM, 0},
-    {"|=", ASSIGN_MODIFY, BINOP_BITWISE_IOR, 0},
-    {"&=", ASSIGN_MODIFY, BINOP_BITWISE_AND, 0},
-    {"^=", ASSIGN_MODIFY, BINOP_BITWISE_XOR, 0},
-    {"++", INCREMENT, BINOP_END, 0},
-    {"--", DECREMENT, BINOP_END, 0},
-    {"->", ARROW, BINOP_END, 0},
-    {"&&", ANDAND, BINOP_END, 0},
-    {"||", OROR, BINOP_END, 0},
+    {"+=", ASSIGN_MODIFY, BINOP_ADD},
+    {"-=", ASSIGN_MODIFY, BINOP_SUB},
+    {"*=", ASSIGN_MODIFY, BINOP_MUL},
+    {"/=", ASSIGN_MODIFY, BINOP_DIV},
+    {"%=", ASSIGN_MODIFY, BINOP_REM},
+    {"|=", ASSIGN_MODIFY, BINOP_BITWISE_IOR},
+    {"&=", ASSIGN_MODIFY, BINOP_BITWISE_AND},
+    {"^=", ASSIGN_MODIFY, BINOP_BITWISE_XOR},
+    {"++", INCREMENT, BINOP_END},
+    {"--", DECREMENT, BINOP_END},
+    {"->", ARROW, BINOP_END},
+    {"&&", ANDAND, BINOP_END},
+    {"||", OROR, BINOP_END},
     /* "::" is *not* only C++: gdb overrides its meaning in several
        different ways, e.g., 'filename'::func, function::variable.  */
-    {"::", COLONCOLON, BINOP_END, 0},
-    {"<<", LSH, BINOP_END, 0},
-    {">>", RSH, BINOP_END, 0},
-    {"==", EQUAL, BINOP_END, 0},
-    {"!=", NOTEQUAL, BINOP_END, 0},
-    {"<=", LEQ, BINOP_END, 0},
-    {">=", GEQ, BINOP_END, 0},
-    {".*", DOT_STAR, BINOP_END, 1}
+    {"::", COLONCOLON, BINOP_END},
+    {"<<", LSH, BINOP_END},
+    {">>", RSH, BINOP_END},
+    {"==", EQUAL, BINOP_END},
+    {"!=", NOTEQUAL, BINOP_END},
+    {"<=", LEQ, BINOP_END},
+    {">=", GEQ, BINOP_END},
+    {".*", DOT_STAR, BINOP_END}
   };
 
 /* Identifier-like tokens.  */
@@ -2075,10 +2077,6 @@ lex_one_token (void)
   for (i = 0; i < sizeof tokentab3 / sizeof tokentab3[0]; i++)
     if (strncmp (tokstart, tokentab3[i].operator, 3) == 0)
       {
-	if (tokentab3[i].cxx_only
-	    && parse_language->la_language != language_cplus)
-	  break;
-
 	lexptr += 3;
 	yylval.opcode = tokentab3[i].opcode;
 	return tokentab3[i].token;
@@ -2088,10 +2086,6 @@ lex_one_token (void)
   for (i = 0; i < sizeof tokentab2 / sizeof tokentab2[0]; i++)
     if (strncmp (tokstart, tokentab2[i].operator, 2) == 0)
       {
-	if (tokentab2[i].cxx_only
-	    && parse_language->la_language != language_cplus)
-	  break;
-
 	lexptr += 2;
 	yylval.opcode = tokentab2[i].opcode;
 	if (in_parse_field && tokentab2[i].token == ARROW)
@@ -2525,8 +2519,7 @@ yylex (void)
   current.token = lex_one_token ();
   if (current.token == NAME)
     current.token = classify_name (expression_context_block);
-  if (parse_language->la_language != language_cplus
-      || (current.token != TYPENAME && current.token != COLONCOLON))
+  if (current.token != TYPENAME && current.token != COLONCOLON)
     return current.token;
 
   first_was_coloncolon = current.token == COLONCOLON;
--- a/gdb/valops.c
+++ b/gdb/valops.c
@@ -3501,7 +3501,16 @@ value_maybe_namespace_elt (const struct type *curtype,
     return NULL;
   else if ((noside == EVAL_AVOID_SIDE_EFFECTS)
 	   && (SYMBOL_CLASS (sym) == LOC_TYPEDEF))
-    result = allocate_value (SYMBOL_TYPE (sym));
+    {
+      struct type *type = SYMBOL_TYPE (sym);
+
+      /* If this is a typedef, then find its immediate target.  We use
+	 check_typedef to resolve stubs, but we ignore its result because we do
+	 not want to dig past all typedefs.  */
+      check_typedef (type);
+      type = TYPE_TARGET_TYPE (type);
+      return allocate_value (type);
+    }
   else
     result = value_of_variable (sym, get_selected_block (0));
 

Re: [rfc] Be in language c more c++ compatible

[Tom Tromey]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> echo 'class C { typedef int t; t i; } c;'|g++ -c -o 1.o -g -x c++ -
Jan> FSF GDB HEAD
Jan> (gdb) show language 
Jan> The current source language is "auto; currently c".

I am curious why this happens.
It seems like it should say "currently c++" -- I didn't check the code
but my mental model would be that if there is no frame, then the default
symtab should either be 'main' or, if no main, say the first CU in the
symbol file; and the default symtab's language should be used for auto.

Jan> The first (c-exp.y) part parses those parts of `language c++' which cannot
Jan> (I believe - RFC) lead to misinterpretation of any valid C code even in
Jan> `language c'.

I think so, though one would have to check eval.c and friends as well to
be certain.

Jan> The second (valops.c) part is there because with `language c++'
Jan> parsing "C::t" is straight OP_TYPE handled correctly in
Jan> evaluate_subexp_standard.  But with `language c' it gets parsed as
Jan> OP_SCOPE and I find there a bug, copied the code there.

I don't even know why we have OP_SCOPE.

Tom

Re: [rfc] Be in language c more c++ compatible

[Jan Kratochvil]

On Fri, 15 Jul 2011 22:58:28 +0200, Tom Tromey wrote:
> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> Jan> The current source language is "auto; currently c".
> 
> I am curious why this happens.
> It seems like it should say "currently c++" -- I didn't check the code
> but my mental model would be that if there is no frame, then the default
> symtab should either be 'main' or, if no main, say the first CU in the
> symbol file; and the default symtab's language should be used for auto.

You are close but I do not think it matters.

One can have purely C program which has dynamically (even indirectly) linked
some library in C++ and one should be able to access C++ expressions in that
library.  One cannot with the main program is in Fortran or other languages
but C vs. C++ are both mixed in the real world and also their parsing does not
conflict too much.


> Jan> The second (valops.c) part is there because with `language c++'
> Jan> parsing "C::t" is straight OP_TYPE handled correctly in
> Jan> evaluate_subexp_standard.  But with `language c' it gets parsed as
> Jan> OP_SCOPE and I find there a bug, copied the code there.
> 
> I don't even know why we have OP_SCOPE.

I agree, c-exp.y already tries to resolve everything to OP_TYPE and
OP_VAR_VALUE.  I admit I tried to remove but the code still depends on it.
Also non-C languages use OP_SCOPE.  I find that cleanup as a different one
/ additional one.


Thanks,
Jan

Re: [rfc] Be in language c more c++ compatible

[Mark Kettenis]

> Date: Fri, 15 Jul 2011 21:19:20 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> 
> Hi,
> 
> I always see some terrible C++ GDB bug so I fix in some hours and then find out
> it works in GDB when one has `set language c++'.  This usually happens with
> artificial testcases like the one today:
> 	http://sourceware.org/ml/gdb-patches/2011-07/msg00387.html
> 
> I was told by Keith it also happens to him.
> 
> echo 'class C { typedef int t; t i; } c;'|g++ -c -o 1.o -g -x c++ -

Isn't that a GCC bug?  I mean, if code is compiled with the C++
compiler it should be tagged as such in the debug info shouldn't it?

> The first (c-exp.y) part parses those parts of `language c++' which cannot
> (I believe - RFC) lead to misinterpretation of any valid C code even in
> `language c'.

I think this is a bad idea.

Re: [rfc] Be in language c more c++ compatible

[Jan Kratochvil]

On Sat, 23 Jul 2011 20:38:11 +0200, Mark Kettenis wrote:
> > echo 'class C { typedef int t; t i; } c;'|g++ -c -o 1.o -g -x c++ -
> 
> Isn't that a GCC bug?  I mean, if code is compiled with the C++
> compiler it should be tagged as such in the debug info shouldn't it?

I take the point that in these cases only a single CU is loaded.  While
currently GDB does not consider such CU for language detection (such as
because it does not contain `main') one possible fix is to just follow the CU
language, if it is the only CU loaded.


> > The first (c-exp.y) part parses those parts of `language c++' which cannot
> > (I believe - RFC) lead to misinterpretation of any valid C code even in
> > `language c'.
> 
> I think this is a bad idea.

There was another mail about use case when you combine C/C++ application/libs.

What are disadvantages of interpreting something as C++ instead of giving
error on such expression?


Thanks,
Jan

Re: [rfc] Be in language c more c++ compatible

[Matt Rice]

[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]

On Fri, Jul 15, 2011 at 12:19 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> Hi,
>
> I always see some terrible C++ GDB bug so I fix in some hours and then find out
> it works in GDB when one has `set language c++'.  This usually happens with
> artificial testcases like the one today:
>        http://sourceware.org/ml/gdb-patches/2011-07/msg00387.html

was curious what it did with the attached objc++ version.

which isn't really a supported language by any means.
gdb considers it to be 'minimal'/doesn't recognize the CU language in
the debuginfo.  and it is difficult to say how meaningful it would be
if it did.
I imagine gdb wants DW_TAG_partial_unit/DW_AT_language when
switching between c++/objective-c functions, I hadn't been able to
coax this out of gcc

anyhow the last line was a bit suprising.

gcc -g -o objcxx objc++.mm -lobjc

GNU gdb (GDB) Fedora (7.2-51.fc14)
(gdb) set language c++
(gdb) whatis C::t
No symbol "C" in current context.
(gdb) set language objective-c
(gdb) whatis C::t
No symbol "C" in current context.
(gdb) break main
Breakpoint 1 at 0x400808: file objc++.mm, line 47.
(gdb) r
Breakpoint 1, main () at objc++.mm:47
47	  Foo *foo = [[Foo alloc] init];
Warning: the current language does not match this frame.
(gdb) whatis C::t
type = t
(gdb) show language
The current source language is "objective-c".
Warning: the current language does not match this frame.
(gdb) set language c++
(gdb) whatis C::t
A syntax error in expression, near `'.

[-- Attachment #2: objc++.mm --]
[-- Type: text/plain, Size: 441 bytes --]

#include <objc/Object.h>

class C { 
  public:
  typedef int t;
  C();
  C(t);
  t i;
} c;

C::C()
{
  i = 9;
}

C::C(t x)
{
  i = x;
}

@interface Foo : Object
{
  @public
    C::t i;
}
- (C::t) bar;
@end

@implementation Foo
- (id) init
{
  if ((self = [super init]))
    i = 5;

  return self;
}

- (C::t) bar 
{
  return i;
}

@end

int main()
{
  Foo *foo = [[Foo alloc] init];
  C c = C([foo bar]);
  printf("%i %i\n", foo->i, c.i);
}

Re: [rfc] Be in language c more c++ compatible

[Jan Kratochvil]

On Sat, 23 Jul 2011 23:17:43 +0200, Matt Rice wrote:
> was curious what it did with the attached objc++ version.
> 
> which isn't really a supported language by any means.
> gdb considers it to be 'minimal'/doesn't recognize the CU language in
> the debuginfo.

dwarf2read.c:set_cu_language does not recognize DW_LANG_ObjC_plus_plus.


> gcc -g -o objcxx objc++.mm -lobjc
[...]
> (gdb) set language c++
> (gdb) whatis C::t
> A syntax error in expression, near `'.

the problem is the CU (Compilation Unit) is neither Java nor C++ and it even
has no DW_AT_MIPS_linkage_name, therefore `C::C' constructor gets symbol name
`C' which just cannot work.

There probably needs to be created new language_objcplus and adjust the code
accordingly.

I think this is outside of the scope of this thread.


Thanks,
Jan


--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -5019,7 +5019,7 @@ dwarf2_compute_name (char *name, struct die_info *die, struct dwarf2_cu *cu,
   /* These are the only languages we know how to qualify names in.  */
   if (name != NULL
       && (cu->language == language_cplus || cu->language == language_java
-	  || cu->language == language_fortran))
+	  || cu->language == language_fortran || cu->language == language_objc))
     {
       if (die_needs_namespace (die, cu))
 	{
@@ -5061,7 +5061,8 @@ dwarf2_compute_name (char *name, struct die_info *die, struct dwarf2_cu *cu,
 	     templates; two instantiated function templates are allowed to
 	     differ only by their return types, which we do not add here.  */
 
-	  if (cu->language == language_cplus && strchr (name, '<') == NULL)
+	  if ((cu->language == language_cplus || cu->language == language_objc)
+	      && strchr (name, '<') == NULL)
 	    {
 	      struct attribute *attr;
 	      struct die_info *child;
@@ -5171,7 +5172,8 @@ dwarf2_compute_name (char *name, struct die_info *die, struct dwarf2_cu *cu,
 
 	  if (physname && die->tag == DW_TAG_subprogram
 	      && (cu->language == language_cplus
-		  || cu->language == language_java))
+		  || cu->language == language_java
+		  || cu->language == language_objc))
 	    {
 	      struct type *type = read_type_die (die, cu);
 
@@ -5205,7 +5207,7 @@ dwarf2_compute_name (char *name, struct die_info *die, struct dwarf2_cu *cu,
 				       &length);
 	  ui_file_delete (buf);
 
-	  if (cu->language == language_cplus)
+	  if (cu->language == language_cplus || cu->language == language_objc)
 	    {
 	      char *cname
 		= dwarf2_canonicalize_name (name, cu,
@@ -10399,6 +10401,7 @@ set_cu_language (unsigned int lang, struct dwarf2_cu *cu)
       cu->language = language_pascal;
       break;
     case DW_LANG_ObjC:
+    case DW_LANG_ObjC_plus_plus:
       cu->language = language_objc;
       break;
     case DW_LANG_Cobol74:

Re: [rfc] Be in language c more c++ compatible

[Matt Rice]

On Sun, Jul 24, 2011 at 5:52 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Sat, 23 Jul 2011 23:17:43 +0200, Matt Rice wrote:
>> was curious what it did with the attached objc++ version.
>>
>> which isn't really a supported language by any means.
>
> I think this is outside of the scope of this thread.
>

Yeah, I pretty much came to the same conclusion,
after stewing on it overnight
except as it relates to:

>>There was another mail about use case when you >>combine C/C++ application/libs.

since objc++ is typically used to bridge a c++ library with an
objective-c library, and not generally a language used to write in
directly. there is also more opportunity for 'set language', in both
languages with the current language being
objective-c and setting to c++, but also the current language being
c++ and wanting to be objective-c.

what made me think of it, is the last time I was debugging a mixed
c++/objective-c program, having to call 'set language', was extremely
annoying, to the point that I added commands to my .gdbinit to lighten
the churn.

define cp
set language c++
end

define oc
set language objective-c
end

and setting the language was mostly something done in response to some
failed command.  Thus, I personally think anything that lessens the
amount of 'set language'ing is a good idea.

Re: [rfc] Be in language c more c++ compatible

[Tom Tromey]

Matt> what made me think of it, is the last time I was debugging a mixed
Matt> c++/objective-c program, having to call 'set language', was extremely
Matt> annoying, to the point that I added commands to my .gdbinit to lighten
Matt> the churn.

Adding real support for ObjC++ would be by far the best solution.

Tom

Re: [rfc] Be in language c more c++ compatible

[Tom Tromey]

Jan> The first (c-exp.y) part parses those parts of `language c++' which cannot
Jan> (I believe - RFC) lead to misinterpretation of any valid C code even in
Jan> `language c'.

Mark> I think this is a bad idea.

For the best results, one must also provide reasons why it is a bad
idea.  Otherwise when looking at the pros and cons, your dislike appears
in the cons list as merely a personal dislike -- which while not
unimportant certainly carries much less weight than technical arguments.

Tom