[rfc][24/37] Eliminate builtin_type_ macros: Platform-neutral generic integers
Ulrich Weigand
uweigand@de.ibm.com
Sun Sep 7 16:44:00 GMT 2008
Joel Brobecker wrote:
> > @@ -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.
OK, thanks for verifying this.
> > 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...
I agree that this should never trigger, as create_range_type is
never called with a NULL index_type argument. (For stabsread.c
it seems it might get called with a builtin_type_error argument
in certain cases, but never NULL.)
The same holds for the copies of this code in m2-typeprint.c and
m2-valprint.c.
However, I simply wanted to preserve the status quo with this patch
set -- those checks can be removed with a follow-on patch.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
More information about the Gdb-patches
mailing list