From: Jim Blandy <jimb@redhat.com>
To: Andrew Cagney <cagney@gnu.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: handle zero-length types in value_from_register
Date: Wed, 28 Jan 2004 05:49:00 -0000 [thread overview]
Message-ID: <vt2u12g4o82.fsf@zenia.home> (raw)
In-Reply-To: <40166D8B.8030209@gnu.org>
[-- 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;
next prev parent reply other threads:[~2004-01-28 5:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-27 5:36 Jim Blandy
2004-01-27 14:05 ` Andrew Cagney
2004-01-27 15:38 ` Jim Blandy
2004-01-27 16:43 ` Andrew Cagney
2004-01-28 5:49 ` Jim Blandy [this message]
2004-02-18 3:14 Jim Blandy
2004-02-18 15:03 ` Andrew Cagney
2004-02-19 22:53 ` Jim Blandy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=vt2u12g4o82.fsf@zenia.home \
--to=jimb@redhat.com \
--cc=cagney@gnu.org \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox