* findvar.c (value_from_register): Doc fix.

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 11368fb79837aa6101ee2e6d74b03e9f7acd0f16..a6c6f965ade53db2b9ec3394a779ba49f44cb98d 100644 (file)
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,7 @@
+2004-02-19  Jim Blandy  <jimb@redhat.com>
+
+       * findvar.c (value_from_register): Doc fix.
+
 2004-02-19  Jeff Johnston  <jjohnstn@redhat.com>
 
        * printcmd.c (print_scalar_formatted): Do not check for sizeof

diff --git a/gdb/findvar.c b/gdb/findvar.c
index 3cb40b2c8713eb6918bcd708e839f0eb7318ccff..cb1ef655dc27ef7a87ddd2210d6a87f30bf2b38d 100644 (file)
--- a/gdb/findvar.c
+++ b/gdb/findvar.c
@@ -627,14 +627,14 @@ value_from_register (struct type *type, int regnum, struct frame_info *frame)
          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.)
+         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;