This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/3] bitpos: Expand type_field_bitpos to LONGEST and type.length to ULONGEST
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