This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfc][24/37] Eliminate builtin_type_ macros: Platform-neutral generic integers


> @@ -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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]