summaryrefslogtreecommitdiff
path: root/gdb/findvar.c
diff options
context:
space:
mode:
authorJim Blandy <jimb@codesourcery.com>2004-02-19 22:45:31 +0000
committerJim Blandy <jimb@codesourcery.com>2004-02-19 22:45:31 +0000
commit6aded0b148af331991766786b4438f697e34e106 (patch)
tree11b5186c752bae2d2a16d5a065335debf591d5f1 /gdb/findvar.c
parentcb282f7548a17ae1df6c9bbf13436a900f003733 (diff)
downloadgdb-6aded0b148af331991766786b4438f697e34e106.tar.gz
* findvar.c (value_from_register): Doc fix.
Diffstat (limited to 'gdb/findvar.c')
-rw-r--r--gdb/findvar.c16
1 files changed, 8 insertions, 8 deletions
diff --git a/gdb/findvar.c b/gdb/findvar.c
index 3cb40b2c871..cb1ef655dc2 100644
--- 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;