[patch] Fix gdb-gdb.py for flds_bnds copy-pastes

[patch] Fix gdb-gdb.py for flds_bnds copy-pastes

[Jan Kratochvil]

Hi,

one such a longstanding pain - accessing pretty-printed field name does not
work:

(gdb) p *type.main_type
$2 = 
{name = 0x0,
[...]
 field[0]:
 ########
  {name = 0x2115978 "i",
[...]
   bitpos = 0},
 cplus_stuff = 0xf33b80}
(gdb) p/r *type.main_type
$3 = {code = TYPE_CODE_STRUCT, [...]
  target_type = 0x0, flds_bnds = {fields = 0x21161f0, bounds = 0x21161f0},
                     ####################################################
  [...], func_stuff = 0xf33b80}}
(gdb) p type.main_type.field[0]
                       ########
There is no member named field.
###############################
(gdb) p type.main_type.fields[0]
                       #########
There is no member named fields.
################################
(gdb) p type.main_type.flds_bnds.fields[0]
                       ###################
$3 = {loc = {bitpos = 0, physaddr = 0, [...], name = 0x2115978 "i"}

Probably clear to check it in.  I had to `print/r' to suppress gdb-gdb.py to
ba able to access GDB types fields.


Thanks,
Jan


gdb/
2012-02-09  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* gdb-gdb.py (StructMainTypePrettyPrinter) <struct_field_img>: Print
	flds_bnds.fields.
	(StructMainTypePrettyPrinter) <bounds_img>: Print flds_bnds.bounds.

--- a/gdb/gdb-gdb.py
+++ b/gdb/gdb-gdb.py
@@ -166,7 +166,7 @@ class StructMainTypePrettyPrinter:
         """Return an image of the main_type field number FIELDNO.
         """
         f = self.val['flds_bnds']['fields'][fieldno]
-        label = "field[%d]:" % fieldno
+        label = "flds_bnds.fields[%d]:" % fieldno
         if f['artificial']:
             label += " (artificial)"
         fields = []
@@ -186,7 +186,7 @@ class StructMainTypePrettyPrinter:
         high = str(b['high'])
         if b['high_undefined'] != 0:
             high += " (undefined)"
-        return "bounds = {%s, %s}" % (low, high)
+        return "flds_bnds.bounds = {%s, %s}" % (low, high)
     def type_specific_img(self):
         """Return a string image of the main_type type_specific union.
         Only the relevant component of that union is printed (based on

[no-commit-intention] Naive unnamed fields for main_type [Re: [patch] Fix gdb-gdb.py for flds_bnds copy-pastes]

[Jan Kratochvil]

Hi,

I naively tried first to just use unnamed field which makes everything great:

(gdb) p *type.main_type
$2 =
{name = 0x0,
[...]
 fields[0]:
 #########
  {name = 0x2115978 "i",
[...]
   bitpos = 0},
 cplus_stuff = 0xf33b80}
(gdb) p/r *type.main_type
$3 = {code = TYPE_CODE_STRUCT, [...]
  target_type = 0x0, {fields = 0x21161f0, bounds = 0x21161f0},
                     ########################################
  [...], func_stuff = 0xf33b80}}
(gdb) p type.main_type.fields[0]
                       #########
$4 = {loc = {bitpos = 0, physaddr = 0, [...], name = 0x2115978 "i"}

But apparently we cannot:
$ echo 'struct { int a; struct { int b; }; } s;'|gcc -c -x c - -Wall -std=c90 -pedantic
<stdin>:1:34: warning: ISO C90 doesn’t support unnamed structs/unions [-pedantic]

We could with C99 (after GCC PR c/52182) but GDB sources are still
C90-compatible anyway and C90 spec really does not support unnamed fields.

(Plus everything should be in singular form like the databases do but that is
unrelated.)


Regards,
Jan


--- a/gdb/gdb-gdb.py
+++ b/gdb/gdb-gdb.py
@@ -165,8 +165,8 @@ class StructMainTypePrettyPrinter:
     def struct_field_img(self, fieldno):
         """Return an image of the main_type field number FIELDNO.
         """
-        f = self.val['flds_bnds']['fields'][fieldno]
-        label = "field[%d]:" % fieldno
+        f = self.val['fields'][fieldno]
+        label = "fields[%d]:" % fieldno
         if f['artificial']:
             label += " (artificial)"
         fields = []
@@ -179,7 +179,7 @@ class StructMainTypePrettyPrinter:
     def bounds_img(self):
         """Return an image of the main_type bounds.
         """
-        b = self.val['flds_bnds']['bounds'].dereference()
+        b = self.val['bounds'].dereference()
         low = str(b['low'])
         if b['low_undefined'] != 0:
             low += " (undefined)"
--- a/gdb/gdbtypes.h
+++ b/gdb/gdbtypes.h
@@ -582,7 +582,7 @@ struct main_type
 
     } *bounds;
 
-  } flds_bnds;
+  };
 
   /* For types with virtual functions (TYPE_CODE_STRUCT), VPTR_BASETYPE
      is the base class which defined the virtual function table pointer.  
@@ -1029,10 +1029,10 @@ extern void allocate_gnat_aux_type (struct type *);
    type, you need to do TYPE_CODE (check_type (this_type)).  */
 #define TYPE_CODE(thistype) TYPE_MAIN_TYPE(thistype)->code
 #define TYPE_NFIELDS(thistype) TYPE_MAIN_TYPE(thistype)->nfields
-#define TYPE_FIELDS(thistype) TYPE_MAIN_TYPE(thistype)->flds_bnds.fields
+#define TYPE_FIELDS(thistype) TYPE_MAIN_TYPE(thistype)->fields
 
 #define TYPE_INDEX_TYPE(type) TYPE_FIELD_TYPE (type, 0)
-#define TYPE_RANGE_DATA(thistype) TYPE_MAIN_TYPE(thistype)->flds_bnds.bounds
+#define TYPE_RANGE_DATA(thistype) TYPE_MAIN_TYPE(thistype)->bounds
 #define TYPE_LOW_BOUND(range_type) TYPE_RANGE_DATA(range_type)->low
 #define TYPE_HIGH_BOUND(range_type) TYPE_RANGE_DATA(range_type)->high
 #define TYPE_LOW_BOUND_UNDEFINED(range_type) \
@@ -1113,7 +1113,7 @@ extern void allocate_gnat_aux_type (struct type *);
 #define FIELD_ARTIFICIAL(thisfld) ((thisfld).artificial)
 #define FIELD_BITSIZE(thisfld) ((thisfld).bitsize)
 
-#define TYPE_FIELD(thistype, n) TYPE_MAIN_TYPE(thistype)->flds_bnds.fields[n]
+#define TYPE_FIELD(thistype, n) TYPE_MAIN_TYPE(thistype)->fields[n]
 #define TYPE_FIELD_TYPE(thistype, n) FIELD_TYPE(TYPE_FIELD(thistype, n))
 #define TYPE_FIELD_NAME(thistype, n) FIELD_NAME(TYPE_FIELD(thistype, n))
 #define TYPE_FIELD_LOC_KIND(thistype, n) FIELD_LOC_KIND (TYPE_FIELD (thistype, n))

Re: [patch] Fix gdb-gdb.py for flds_bnds copy-pastes

[Joel Brobecker]

> gdb/
> 2012-02-09  Jan Kratochvil  <jan.kratochvil@redhat.com>
> 
> 	* gdb-gdb.py (StructMainTypePrettyPrinter) <struct_field_img>: Print
> 	flds_bnds.fields.
> 	(StructMainTypePrettyPrinter) <bounds_img>: Print flds_bnds.bounds.

Looks good to me.

-- 
Joel

[commit] [patch] Fix gdb-gdb.py for flds_bnds copy-pastes

[Jan Kratochvil]

On Thu, 09 Feb 2012 16:11:29 +0100, Joel Brobecker wrote:
> > gdb/
> > 2012-02-09  Jan Kratochvil  <jan.kratochvil@redhat.com>
> > 
> > 	* gdb-gdb.py (StructMainTypePrettyPrinter) <struct_field_img>: Print
> > 	flds_bnds.fields.
> > 	(StructMainTypePrettyPrinter) <bounds_img>: Print flds_bnds.bounds.
> 
> Looks good to me.

Checked in:
	http://sourceware.org/ml/gdb-cvs/2012-02/msg00049.html


Thanks,
Jan

Re: [no-commit-intention] Naive unnamed fields for main_type [Re: [patch] Fix gdb-gdb.py for flds_bnds copy-pastes]

[Joel Brobecker]

> I naively tried first to just use unnamed field which makes everything great:

Hmmm, true! This flds_bnds union has been bugging me (when debugging)
pretty much ever since it was introduced.

Personally, I don't know what the obstacles are for switching to C99
(technical, FSF policy?). For this particular issue, I feel that it
would not exist if struct main_type was a C++ class. So that could be
another way out of that annoying union. (thinking aloud)

-- 
Joel

Re: [no-commit-intention] Naive unnamed fields for main_type [Re: [patch] Fix gdb-gdb.py for flds_bnds copy-pastes]

[Jan Kratochvil]

On Thu, 09 Feb 2012 16:16:21 +0100, Joel Brobecker wrote:
> Personally, I don't know what the obstacles are for switching to C99
> (technical, FSF policy?).

I do not see anything even close to C90 compatibility, there are tons of
errors with `gcc -std=c90 -pedantic', `sort -u' of them below.


Regards,
Jan

coff-x86_64.c:174:13: error: ISO C90 does not support ‘long long’ [-Werror=long-long]
pex64igen.c:2114:5: error: expected expression before ‘/’ token
pex64igen.c:2114:66: error: too many decimal points in number
./dwarf2.c:3549:3: error: ISO C90 forbids mixed declarations and code [-Werror=edantic]
readline.c:826:36: warning: ISO C forbids conversion of function pointer to object pointer type [-pedantic]
rlprivate.h:462:1: error: unknown type name ‘sigjmp_buf’
opcodes/i386-dis.c:728:26: error: comma at end of enumerator list [-Werror=edantic]
gdb/
i386-tdep.c:3481:24: error: use of C99 long long integer constant [-Werror=long-long]
        gdb/common/i386-xstate.h
                #define I386_XSTATE_X87         (1ULL << 0)
error: ISO C forbids forward references to ‘enum’ types [-Werror=edantic]
error: ISO C forbids assignment between function pointer and ‘void *’ [-Werror=edantic] 
error: ISO C does not allow extra ‘;’ outside of a function [-Werror=edantic]
error: ISO C forbids empty initializer braces [-Werror=edantic]
error: array initialized from parenthesized string constant [-Werror=edantic]
error: array size missing in ‘GdbMethods’
error: excess elements in array initializer [-Werror]
error: format ‘%x’ expects argument of type ‘unsigned int *’, but argument 3 has type ‘int *’ [-Werror=format]
error: initializer element is not computable at load time [-Werror]
error: invoking macro GDBPY_NEW_EVENT_TYPE argument 6: empty macro arguments are undefined in ISO C90 and ISO C++98 [-Werror]
error: non-ISO-standard escape sequence, '\e' [-Werror]
error: string length ‘1107’ is greater than the length ‘509’ ISO C90 compilers are required to support [-Werror=overlength-strings]
error: string length ‘1912’ is greater than the length ‘509’ ISO C90 compilers are required to support [-Werror=overlength-strings]
error: struct has no members [-Werror=edantic]
error: type of bit-field ‘building_fullname’ is a GCC extension [-Werror=edantic]

Re: [no-commit-intention] Naive unnamed fields for main_type [Re: [patch] Fix gdb-gdb.py for flds_bnds copy-pastes]

[Eli Zaretskii]

> Date: Thu, 9 Feb 2012 16:36:42 +0100
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: gdb-patches@sourceware.org
> 
> On Thu, 09 Feb 2012 16:16:21 +0100, Joel Brobecker wrote:
> > Personally, I don't know what the obstacles are for switching to C99
> > (technical, FSF policy?).
> 
> I do not see anything even close to C90 compatibility, there are tons of
> errors with `gcc -std=c90 -pedantic', `sort -u' of them below.

Even so, there's a difference between allowing several popular
extensions to C90 and _requiring_ C99.

Re: [no-commit-intention] Naive unnamed fields for main_type [Re: [patch] Fix gdb-gdb.py for flds_bnds copy-pastes]

[Alfred M. Szmidt]

   Personally, I don't know what the obstacles are for switching to
   C99 (technical, FSF policy?).

GNU policy is that it is OK to use C99, from the GNU Coding Standards,
Calling System Functions:

| Historically, C implementations differed substantially, and many
| systems lacked a full implementation of ANSI/ISO C89.  Nowadays,
| however, very few systems lack a C89 compiler and GNU C supports
| almost all of C99.  Similarly, most systems implement POSIX.1-1993
| libraries and tools, and many have POSIX.1-2001.

| Hence, there is little reason to support old C or non-POSIX systems,
| and you may want to take advantage of C99 and POSIX-1.2001 to write
| clearer, more portable, or faster code.  You should use standard
| interfaces where possible; but if GNU extensions make your program
| more maintainable, powerful, or otherwise better, don't hesitate to
| use them.  In any case, don't make your own declaration of system
| functions; that's a recipe for conflict.

Re: [no-commit-intention] Naive unnamed fields for main_type [Re: [patch] Fix gdb-gdb.py for flds_bnds copy-pastes]

[Stan Shebs]

On 2/9/12 7:16 AM, Joel Brobecker wrote:
>> I naively tried first to just use unnamed field which makes everything great:
> Hmmm, true! This flds_bnds union has been bugging me (when debugging)
> pretty much ever since it was introduced.
>
> Personally, I don't know what the obstacles are for switching to C99
> (technical, FSF policy?). For this particular issue, I feel that it
> would not exist if struct main_type was a C++ class. So that could be
> another way out of that annoying union. (thinking aloud)
>
The expected language dialect can be whatever we decide it to be.

There are basically three categories of gotchas:

1) Non-GCC compilers.  Although there's not the bootstrapping problem 
that GCC itself has, we do want people to use GDB even if it might be 
the only piece of GNU software on their systems.  We should at least 
build with the standard native compiler on our supported systems, but 
should feel free to use whatever flags.  Did any of the proprietary 
workstation compilers totally miss the C99 boat?

2) Older versions of GCC.  For C99 this seems unlikely to be an issue 
anymore, who has a still-usable GCC that is over 10 years old?

3) Libraries/headers.  This is probably the most common way that people 
get hosed - their GCC is modern, but library and headers are several 
generations older, and possibly lacking C99-required bits.

Stan

Re: [no-commit-intention] Naive unnamed fields for main_type [Re: [patch] Fix gdb-gdb.py for flds_bnds copy-pastes]

[Tom Tromey]

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

Jan> I do not see anything even close to C90 compatibility, there are tons of
Jan> errors with `gcc -std=c90 -pedantic', `sort -u' of them below.

I'm not sure that all these problems really represent C90
incompatibilities.  Some of them are GNU extensions either discovered by
configure (or did you reconfigure with those options?) or by looking at
__GNUC__ (which is ok in the sense that we just shouldn't bother
supporting builds with -pedantic).

Jan> coff-x86_64.c:174:13: error: ISO C90 does not support ‘long long’ [-Werror=long-long]

Definitely a real bug :)

Jan> error: ISO C forbids forward references to ‘enum’ types [-Werror=edantic]

Do these really say 'edantic' (missing 'p')?
If so, could you report it as a GCC bug?

Tom

Re: [no-commit-intention] Naive unnamed fields for main_type [Re: [patch] Fix gdb-gdb.py for flds_bnds copy-pastes]

[Tom Tromey]

>>>>> "Stan" == Stan Shebs <stanshebs@earthlink.net> writes:

Stan> We should at least build with the standard native compiler on our
Stan> supported systems, but should feel free to use whatever flags.
Stan> Did any of the proprietary workstation compilers totally miss the
Stan> C99 boat?

Perhaps people with access to these machines could try it and report
back.

Stan> 3) Libraries/headers.  This is probably the most common way that
Stan> people get hosed - their GCC is modern, but library and headers are
Stan> several generations older, and possibly lacking C99-required bits.

I'm not so concerned about this.  We already have configure and we can
also import things from gnulib.

Tom

Re: [no-commit-intention] Naive unnamed fields for main_type [Re: [patch] Fix gdb-gdb.py for flds_bnds copy-pastes]

[Jan Kratochvil]

On Fri, 10 Feb 2012 19:04:47 +0100, Tom Tromey wrote:
> I'm not sure that all these problems really represent C90
> incompatibilities.  Some of them are GNU extensions either discovered by
> configure (or did you reconfigure with those options?)

Yes, it was built from `git clean -dfx'.


> Jan> coff-x86_64.c:174:13: error: ISO C90 does not support ‘long long’ [-Werror=long-long]
> 
> Definitely a real bug :)

`long long' is apparently not supported by ISO C90 compilers, so it is a bug
if GDB claims C90 compatibility.  Or what do you mean?


> Jan> error: ISO C forbids forward references to ‘enum’ types [-Werror=edantic]
> 
> Do these really say 'edantic' (missing 'p')?
> If so, could you report it as a GCC bug?

Checked now it is popular GCC PR c/44774.


Thanks,
Jan

Re: [no-commit-intention] Naive unnamed fields for main_type [Re: [patch] Fix gdb-gdb.py for flds_bnds copy-pastes]

[Tom Tromey]

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

Jan> `long long' is apparently not supported by ISO C90 compilers, so it
Jan> is a bug if GDB claims C90 compatibility.  Or what do you mean?

I mean that this is clearly a C90 violation.

Another question is whether some compilers accept parts of C99 but not
all of it.

As to the original problem, anonymous unions are a GCC extension, now in
C11 -- but not in C99:

barimba. echo 'struct { int a; struct { int b; }; } s;'|gcc --syntax-only -x c - -Wall -std=c99 -pedantic
<stdin>:1:34: warning: ISO C99 doesn’t support unnamed structs/unions [-pedantic]

So moving to C99 wouldn't help that.

Tom

Re: [no-commit-intention] Naive unnamed fields for main_type [Re: [patch] Fix gdb-gdb.py for flds_bnds copy-pastes]

[Jan Kratochvil]

On Fri, 10 Feb 2012 20:21:43 +0100, Tom Tromey wrote:
> As to the original problem, anonymous unions are a GCC extension, now in
> C11 -- but not in C99:
> 
> barimba. echo 'struct { int a; struct { int b; }; } s;'|gcc --syntax-only -x c - -Wall -std=c99 -pedantic
> <stdin>:1:34: warning: ISO C99 doesn’t support unnamed structs/unions [-pedantic]
> 
> So moving to C99 wouldn't help that.

In GCC PR c/52182 Joseph S. Myers explained me my ISO C99 misread, that GCC is
right with this error.


Thanks,
Jan

Re: [no-commit-intention] Naive unnamed fields for main_type [Re: [patch] Fix gdb-gdb.py for flds_bnds copy-pastes]

[Mark Kettenis]

> From: Tom Tromey <tromey@redhat.com>
> Date: Fri, 10 Feb 2012 12:21:43 -0700
> 
> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> 
> Jan> `long long' is apparently not supported by ISO C90 compilers, so it
> Jan> is a bug if GDB claims C90 compatibility.  Or what do you mean?
> 
> I mean that this is clearly a C90 violation.
> 
> Another question is whether some compilers accept parts of C99 but not
> all of it.

Quite a few compilers do.  For example, 'long long' was a popular
extension adopted by many vendors even before C99 was ratified.

On OpenBSD we still have some platforms stuck with GCC 2.95.  It
already includes quite a bit of C99 functionality, but some bits are
missing.  The most important one is that it doesn't allow declarations
after statements.  But I (and many C programmers with me) consider
that to be bad style and a C99 misfeature anyway.

Re: [no-commit-intention] Naive unnamed fields for main_type [Re: [patch] Fix gdb-gdb.py for flds_bnds copy-pastes]

[Jan Kratochvil]

On Sun, 12 Feb 2012 11:19:50 +0100, Mark Kettenis wrote:
> On OpenBSD we still have some platforms stuck with GCC 2.95.

And does it support unnamed fields?

echo 'struct { int a; struct { int b; }; } s;'|gcc -c -x c - -Wall 

At least gcc-2.96-116.7.2.i386 does.


> already includes quite a bit of C99 functionality, but some bits are
> missing.

So maybe unnamed fields are OK for GDB?


Thanks,
Jan