Re: [PATCH 1/3] bitpos: Expand type_field_bitpos to LONGEST and type.length to ULONGEST

[Sergio Durigan Junior <sergiodj@redhat.com>]

On Monday, August 06 2012, Siddhesh Poyarekar wrote:

> On Sun, 05 Aug 2012 04:42:43 -0700, Michael wrote:
>> The ChangeLog mentions a modification to microblaze-tdep.c, but the
>> patch does not contain any changes to this file.
>> 
>
> Oh boy, I took the wrong diff from my repo when posting the patch -- I
> had the patch in two changesets. Attached is the real patch for this.
> ChangeLog added once again for review benefit.

Hi Siddesh,

Thanks for the patch.  One issue I found:

> diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c
> index 0ea4df1..9479098 100644
> --- a/gdb/gdbtypes.c
> +++ b/gdb/gdbtypes.c
> @@ -953,7 +953,7 @@ create_array_type (struct type *result_type,
>  
>  struct type *
>  lookup_array_range_type (struct type *element_type,
> -			 int low_bound, int high_bound)
> +			 LONGEST low_bound, LONGEST high_bound)
>  {
>    struct gdbarch *gdbarch = get_type_arch (element_type);
>    struct type *index_type = builtin_type (gdbarch)->builtin_int;
> @@ -989,7 +989,7 @@ create_string_type (struct type *result_type,
>  
>  struct type *
>  lookup_string_range_type (struct type *string_char_type,
> -			  int low_bound, int high_bound)
> +			  LONGEST low_bound, LONGEST high_bound)
>  {
>    struct type *result_type;

These two functions' prototypes have to be updated on gdbtypes.h.

Another issue I found, specifically on i386 RHEL 5.8 (gcc (GCC) 4.1.2
20080704 (Red Hat 4.1.2-52)):

    (gdb) print e^M
    $1 = 4294967295^M
    (gdb) FAIL: gdb.base/enumval.exp: print e
    print f^M
    $2 = -1152921504606846976^M
    (gdb) FAIL: gdb.base/enumval.exp: print f
    print J^M
    $3 = J^M
    (gdb) PASS: gdb.base/enumval.exp: print J
    print K^M
    $4 = <optimized out>^M
    (gdb) FAIL: gdb.base/enumval.exp: print K

I still haven't debugged further to see what's happening, and I also
haven't tested on a newer GCC (it can be a compiler bug, as you may
remember from our last talk).  I will come back if I have more info.

Thanks,

-- 
Sergio