This is the mail archive of the gdb-prs@sources.redhat.com 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]

pending/839: Re: mishandled enums in sparc-sun-solaris2.8 gcc 3.2 + gdb 20021001


>Number:         839
>Category:       pending
>Synopsis:       Re: mishandled enums in sparc-sun-solaris2.8 gcc 3.2 + gdb 20021001
>Confidential:   yes
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   unknown
>Arrival-Date:   Tue Nov 19 14:48:01 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     
>Release:        
>Organization:
>Environment:
>Description:
 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
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:


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