Re: RFA: handle zero-length types in value_from_register

Re: RFA: handle zero-length types in value_from_register

[Jim Blandy]

The patches I posted here:

http://sources.redhat.com/ml/gdb-patches/2004-01/msg00717.html

haven't gotten any more comments since my last revision, so I've
committed them.

2004-02-17  Jim Blandy  <jimb@redhat.com>

	* findvar.c (value_from_register): If the type has no length, just
	return an acceptable value --- don't report an internal error.

	* stabsread.c (read_type): If we find any type numbers that are
	forward references, complain if the references aren't resolved by
	the time we're finished reading.
	(cleanup_undefined_types): Make error message more appropriate for
	a complaint.

Re: RFA: handle zero-length types in value_from_register

[Andrew Cagney]

> The patches I posted here:
> 
> http://sources.redhat.com/ml/gdb-patches/2004-01/msg00717.html
> 
> haven't gotten any more comments since my last revision, so I've
> committed them.

Jim, did you read this thread?
http://sources.redhat.com/ml/gdb-patches/2004-02/msg00075.html
Andrew

Re: RFA: handle zero-length types in value_from_register

[Jim Blandy]

Andrew Cagney <cagney@gnu.org> writes:

> > The patches I posted here:
> > http://sources.redhat.com/ml/gdb-patches/2004-01/msg00717.html
> > haven't gotten any more comments since my last revision, so I've
> > committed them.
> 
> Jim, did you read this thread?
> http://sources.redhat.com/ml/gdb-patches/2004-02/msg00075.html
> Andrew

No, I hadn't --- thanks.  I've committed the following.

2004-02-19  Jim Blandy  <jimb@redhat.com>

	* findvar.c (value_from_register): Doc fix.

*** findvar.c.~1.73.~	2004-02-17 23:24:28.000000000 -0500
--- findvar.c	2004-02-19 17:39:16.000000000 -0500
***************
*** 627,640 ****
           error.  
  
           Zero-length types can legitimately arise from declarations
!          like 'struct {}'.  GDB may also create them when it finds
!          bogus debugging information; for example, in GCC 2.95.4 and
!          binutils 2.11.93.0.2, the STABS BINCL->EXCL compression
!          process can create bad type numbers.  GDB reads these as
!          TYPE_CODE_UNDEF types, with zero length.  (That bug is
!          actually the only known way to get a zero-length value
!          allocated to a register --- which is what it takes to make it
!          here.)
  
           We'll just attribute the value to the original register.  */
        VALUE_LVAL (v) = lval_register;
--- 627,640 ----
           error.  
  
           Zero-length types can legitimately arise from declarations
!          like 'struct {}' (a GCC extension, not valid ISO C).  GDB may
!          also create them when it finds bogus debugging information;
!          for example, in GCC 2.95.4 and binutils 2.11.93.0.2, the
!          STABS BINCL->EXCL compression process can create bad type
!          numbers.  GDB reads these as TYPE_CODE_UNDEF types, with zero
!          length.  (That bug is actually the only known way to get a
!          zero-length value allocated to a register --- which is what
!          it takes to make it here.)
  
           We'll just attribute the value to the original register.  */
        VALUE_LVAL (v) = lval_register;

RFA: handle zero-length types in value_from_register

[Jim Blandy]

2004-01-27  Jim Blandy  <jimb@redhat.com>

	* findvar.c (value_from_register): If the type has no length, just
	return an acceptable value --- don't report an internal error.

Index: gdb/findvar.c
===================================================================
RCS file: /cvs/src/src/gdb/findvar.c,v
retrieving revision 1.66
diff -c -r1.66 findvar.c
*** gdb/findvar.c	30 Sep 2003 19:12:18 -0000	1.66
--- gdb/findvar.c	27 Jan 2004 05:28:52 -0000
***************
*** 617,623 ****
    struct value *v = allocate_value (type);
    CHECK_TYPEDEF (type);
  
!   if (CONVERT_REGISTER_P (regnum, type))
      {
        /* The ISA/ABI need to something weird when obtaining the
           specified value from this register.  It might need to
--- 617,641 ----
    struct value *v = allocate_value (type);
    CHECK_TYPEDEF (type);
  
!   if (TYPE_LENGTH (type) == 0)
!     {
!       /* It doesn't matter much what we return for this: since the
!          length is zero, it could be anything.  But if allowed to see
!          a zero-length type, the register-finding loop below will set
!          neither mem_stor nor reg_stor, and then report an internal
!          error.  
! 
!          Zero-length types can legitimately arise from declarations
!          like 'struct {}'.  GDB also creates them when it finds bogus
!          debugging information (for example, TYPE_CODE_UNDEF has a
!          length of zero).
! 
!          We'll just attribute the value to the original register.  */
!       VALUE_LVAL (v) = lval_register;
!       VALUE_ADDRESS (v) = regnum;
!       VALUE_REGNO (v) = regnum;
!     }
!   else if (CONVERT_REGISTER_P (regnum, type))
      {
        /* The ISA/ABI need to something weird when obtaining the
           specified value from this register.  It might need to

Re: RFA: handle zero-length types in value_from_register

[Andrew Cagney]

> 2004-01-27  Jim Blandy  <jimb@redhat.com>
> 
> 	* findvar.c (value_from_register): If the type has no length, just
> 	return an acceptable value --- don't report an internal error.
> 
This looks to need a test case.

Andrew

Re: RFA: handle zero-length types in value_from_register

[Jim Blandy]

Andrew Cagney <cagney@gnu.org> writes:

> > 2004-01-27  Jim Blandy  <jimb@redhat.com>
> > 	* findvar.c (value_from_register): If the type has no length,
> > just
> > 	return an acceptable value --- don't report an internal error.
> >
> This looks to need a test case.

I tried to put one together, but the bug only occurs when the
zero-length value is allocated to a register.  I couldn't find any way
to make that happen at all.  So the only known instance of this bug
depends on bad debug info.

Re: RFA: handle zero-length types in value_from_register

[Andrew Cagney]

> Andrew Cagney <cagney@gnu.org> writes:
> 
> 
>> > 2004-01-27  Jim Blandy  <jimb@redhat.com>
>> > 	* findvar.c (value_from_register): If the type has no length,
>> > just
>> > 	return an acceptable value --- don't report an internal error.
>> >
> 
>> This looks to need a test case.
> 
> 
> I tried to put one together, but the bug only occurs when the
> zero-length value is allocated to a register.  I couldn't find any way
> to make that happen at all.  So the only known instance of this bug
> depends on bad debug info.

The commentary should really reflect this important detail (also mention 
the compiler that's broken for instance).  Should GDB also complain 
about the bogus info?

Andrew

Re: RFA: handle zero-length types in value_from_register

[Jim Blandy]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]


Andrew Cagney <cagney@gnu.org> writes:
> > Andrew Cagney <cagney@gnu.org> writes:
> >
> >> > 2004-01-27  Jim Blandy  <jimb@redhat.com>
> >> > 	* findvar.c (value_from_register): If the type has no length,
> >> > just
> >> > 	return an acceptable value --- don't report an internal error.
> >> >
> >
> >> This looks to need a test case.
> > I tried to put one together, but the bug only occurs when the
> > zero-length value is allocated to a register.  I couldn't find any way
> > to make that happen at all.  So the only known instance of this bug
> > depends on bad debug info.
> 
> The commentary should really reflect this important detail (also
> mention the compiler that's broken for instance).  Should GDB also
> complain about the bogus info?

Seems reasonable.  I've attached a revision of the original patch,
with an expanded comment, and a separate patch that makes GDB complain
when it sees the bogus info.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: tolerate reading zero-length values from registers --]
[-- Type: text/x-patch, Size: 2124 bytes --]

2004-01-27  Jim Blandy  <jimb@redhat.com>

	* findvar.c (value_from_register): If the type has no length, just
	return an acceptable value --- don't report an internal error.

Index: gdb/findvar.c
===================================================================
RCS file: /cvs/src/src/gdb/findvar.c,v
retrieving revision 1.68
diff -c -r1.68 findvar.c
*** gdb/findvar.c	26 Jan 2004 20:36:32 -0000	1.68
--- gdb/findvar.c	28 Jan 2004 05:47:05 -0000
***************
*** 617,623 ****
    struct value *v = allocate_value (type);
    CHECK_TYPEDEF (type);
  
!   if (CONVERT_REGISTER_P (regnum, type))
      {
        /* The ISA/ABI need to something weird when obtaining the
           specified value from this register.  It might need to
--- 617,646 ----
    struct value *v = allocate_value (type);
    CHECK_TYPEDEF (type);
  
!   if (TYPE_LENGTH (type) == 0)
!     {
!       /* It doesn't matter much what we return for this: since the
!          length is zero, it could be anything.  But if allowed to see
!          a zero-length type, the register-finding loop below will set
!          neither mem_stor nor reg_stor, and then report an internal
!          error.  
! 
!          Zero-length types can legitimately arise from declarations
!          like 'struct {}'.  GDB may also create them when it finds
!          bogus debugging information; for example, in GCC 2.94.4 and
!          binutils 2.11.93.0.2, the STABS BINCL->EXCL compression
!          process can create bad type numbers.  GDB reads these as
!          TYPE_CODE_UNDEF types, with zero length.  (That bug is
!          actually the only known way to get a zero-length value
!          allocated to a register --- which is what it takes to make it
!          here.)
! 
!          We'll just attribute the value to the original register.  */
!       VALUE_LVAL (v) = lval_register;
!       VALUE_ADDRESS (v) = regnum;
!       VALUE_REGNO (v) = regnum;
!     }
!   else if (CONVERT_REGISTER_P (regnum, type))
      {
        /* The ISA/ABI need to something weird when obtaining the
           specified value from this register.  It might need to

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: check that forward reference type numbers are resolved --]
[-- Type: text/x-patch, Size: 2207 bytes --]

2004-01-27  Jim Blandy  <jimb@redhat.com>

	* stabsread.c (read_type): If we find any type numbers that are
	forward references, complain if the references aren't resolved by
	the time we're finished reading.
	(cleanup_undefined_types): Make error message more appropriate for
	a complaint.

Index: gdb/stabsread.c
===================================================================
RCS file: /cvs/src/src/gdb/stabsread.c,v
retrieving revision 1.72
diff -c -r1.72 stabsread.c
*** gdb/stabsread.c	19 Jan 2004 01:20:11 -0000	1.72
--- gdb/stabsread.c	28 Jan 2004 05:39:16 -0000
***************
*** 1446,1456 ****
        if (read_type_number (pp, typenums) != 0)
  	return error_type (pp, objfile);
  
-       /* Type is not being defined here.  Either it already exists,
-          or this is a forward reference to it.  dbx_alloc_type handles
-          both cases.  */
        if (**pp != '=')
! 	return dbx_alloc_type (typenums, objfile);
  
        /* Type is being defined here.  */
        /* Skip the '='.
--- 1446,1466 ----
        if (read_type_number (pp, typenums) != 0)
  	return error_type (pp, objfile);
  
        if (**pp != '=')
!         {
!           /* Type is not being defined here.  Either it already
!              exists, or this is a forward reference to it.
!              dbx_alloc_type handles both cases.  */
!           type = dbx_alloc_type (typenums, objfile);
! 
!           /* If this is a forward reference, arrange to complain if it
!              doesn't get patched up by the time we're done
!              reading.  */
!           if (TYPE_CODE (type) == TYPE_CODE_UNDEF)
!             add_undefined_type (type);
! 
!           return type;
!         }
  
        /* Type is being defined here.  */
        /* Skip the '='.
***************
*** 4197,4203 ****
  	default:
  	  {
  	    complaint (&symfile_complaints,
! 		       "GDB internal error.  cleanup_undefined_types with bad type %d.",
  		       TYPE_CODE (*type));
  	  }
  	  break;
--- 4207,4214 ----
  	default:
  	  {
  	    complaint (&symfile_complaints,
! 		       "forward-referenced types left unresolved, "
!                        "type code %d.",
  		       TYPE_CODE (*type));
  	  }
  	  break;