From f98c22d5172c3479efd38c9123ae30205adff610 Mon Sep 17 00:00:00 2001 From: Jim Blandy Date: Thu, 19 Feb 2004 22:45:31 +0000 Subject: [PATCH] * findvar.c (value_from_register): Doc fix. --- gdb/ChangeLog | 4 ++++ gdb/findvar.c | 16 ++++++++-------- 2 files changed, 12 insertions(+), 8 deletions(-) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 11368fb..a6c6f96 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,7 @@ +2004-02-19 Jim Blandy + + * findvar.c (value_from_register): Doc fix. + 2004-02-19 Jeff Johnston * printcmd.c (print_scalar_formatted): Do not check for sizeof diff --git a/gdb/findvar.c b/gdb/findvar.c index 3cb40b2..cb1ef65 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; -- 2.7.4