This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc][24/37] Eliminate builtin_type_ macros: Platform-neutral generic integers
- From: Joel Brobecker <brobecker at adacore dot com>
- To: uweigand at de dot ibm dot com
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 5 Sep 2008 20:14:28 -0700
- Subject: Re: [rfc][24/37] Eliminate builtin_type_ macros: Platform-neutral generic integers
- References: <20080831175045.128504000@de.ibm.com> <20080831175132.651479000@de.ibm.com>
> @@ -197,11 +197,11 @@ print_range_bound (struct type *type, ch
> the upper bound of the 0 .. -1 range types to be printed as
> a very large unsigned number instead of -1.
> To workaround this stabs deficiency, we replace the TYPE by
> - builtin_type_long when we detect that the bound is negative,
> + builtin_type_int32 when we detect that the bound is negative,
> and the type is a TYPE_CODE_INT. The bound is negative when
> 'm' is the last character of the number scanned in BOUNDS. */
> if (bounds[*n - 1] == 'm' && TYPE_CODE (type) == TYPE_CODE_INT)
> - type = builtin_type_long;
> + type = builtin_type_int32;
> ada_print_scalar (type, B, stream);
> if (bounds[*n] == '_')
> *n += 2;
I'm slightly concerned about the effect of this change on 64-bit
platforms. Normally, stabs is a 32bit format so this shouldn't be
a problem, but Tru64 is a 64-bit platform with stabs, and the
range values are stored as text in the stabs string. So presumably
64-bit range types are possible... However, I couldn't come up with
a case where things get degraded. Nor did the testsuite, which does
also test the case described in the comments), reveal any regression.
So I guess we should be OK.
> Index: gdb-head/gdb/p-typeprint.c
> ===================================================================
> --- gdb-head.orig/gdb/p-typeprint.c
> +++ gdb-head/gdb/p-typeprint.c
> @@ -756,7 +756,7 @@ pascal_type_print_base (struct type *typ
> {
> struct type *target = TYPE_TARGET_TYPE (type);
> if (target == NULL)
> - target = builtin_type_long;
> + target = builtin_type_int32;
> print_type_scalar (target, TYPE_LOW_BOUND (type), stream);
> fputs_filtered ("..", stream);
> print_type_scalar (target, TYPE_HIGH_BOUND (type), stream);
Just an observation: This part seems erroneous, no? type is a
TYPE_CODE_RANGE, but there is no underlying TARGET_TYPE? Would
it make better sense to error-out instead? On platforms using DWARF,
this should never happen (we complain about the missing base type
and use an integer type as a substitute). For stabs, things seem
a little less clear, but it looks like we also always create range
types with a base type. So maybe this should never happen. Anyway,
if there is a Fortran maintainer reading this...
--
Joel