This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
gdb/779: Re: mishandled enums in sparc-sun-solaris2.8 gcc 3.2 + gdb 20021001
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 19 Nov 2002 22:58:00 -0000
- Subject: gdb/779: Re: mishandled enums in sparc-sun-solaris2.8 gcc 3.2 + gdb 20021001
- Reply-to: Daniel Jacobowitz <drow at mvista dot com>
The following reply was made to PR gdb/779; it has been noted by GNATS.
From: Daniel Jacobowitz <drow@mvista.com>
To: gdb-gnats@sources.redhat.com
Cc:
Subject: gdb/779: Re: mishandled enums in sparc-sun-solaris2.8 gcc 3.2 + gdb 20021001
Date: Tue, 19 Nov 2002 17:57:39 -0500
On Wed, Oct 02, 2002 at 06:19:01PM -0000, rrh@cray.com wrote:
> >Category: gdb
> >Synopsis: mishandled enums in sparc-sun-solaris2.8 gcc 3.2 + gdb 20021001
> >Confidential: no
> >Severity: serious
> >Priority: medium
> >Class: sw-bug
> >Submitter-Id: net
> >Originator: rrh@cray.com
> >Release: gdb 20021001
> >Environment:
> sparc-sun-solaris2.8
> >Description:
> An enumeration constructed with members that are unsigned
> integers >= 0x80000000 confuses gdb 20021001. The type information
> is evidently dropped on the floor in gdb.
> If you compile the enclosed program -g, and then debug,
> and then put a breakpoint on the return statement in main,
> and then print out the values of the local variables, you'll get
> (gdb) print c
> $4 = Red
> (gdb) print good
> $5 = gCC_MEMORY_NB
> (gdb) print bad
> $6 = <error type>
> (gdb)
> note that the bad enumeration uses large numbers;
> the good enumeration uses values that aren't so large (bit 31 not set)
>
> The stabs information for the enums is:
> .stabs "color:t(0,24)=eRed:0,Blue:1,;",128,0,2,0
> .stabs "addr_bad:t(0,25)=ebCC_0_LOW_BADDR:2147483648,bCC_1_LOW_BADDR:2281701376,bCC_MEMORY_NB:100745216,;",128,0,6,0
> .stabs "addr_gooBreakpoint 3, error_type (pp=0xffbeda4c, objfile=0x377c30) at stabsread.c:2327
>
> gdb calls error_type with
>
> Breakpoint 3, error_type (pp=0xffbeda4c, objfile=0x377c30) at stabsread.c:2327
> 2327 complain (&error_type_complaint);
> (top-gdb) print *pp
> $1 = 0x36e8a5 "bCC_MEMORY_NB:100745216,;"
FYI, using GCC 3.2 and similar GDB versions (both older and newer) on i386-linux
there is no problem. Notice:
.stabs "addr_bad:t(1,2)=ebCC_0_LOW_BADDR:-2147483648,bCC_1_LOW_BADDR:-2013265920,bCC_MEMORY_NB:100745216,;",128,0,5,0
i.e. they come out as negative constants here.
The number in your debug info does not fit in a long; it would be nice
if GDB handled that more gracefully and I think GCC may be within its
rights to emit an enum whose base type is unsigned.
This looks like a limitation of the stabs reader.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer