This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
store_typed_address internal error
- From: Kevin Nomura <nomura at netapp dot com>
- To: gdb at sources dot redhat dot com
- Date: Mon, 19 Aug 2002 17:35:20 -0700
- Subject: store_typed_address internal error
gdb dies:
(gdb) x/10i args_done
../../gdb-mips/gdb/findvar.c:282: gdb-internal-error:
store_typed_address: type is not a pointer or reference
An internal GDB error was detected. This may make further
debugging unreliable. Continue this debugging session? (y or n) n
The chain of events:
The binary is Elf32 on a 64-bit architecture (MIPS64).
args_done is a label, that would make it an Elf32_Addr
symbol right? Anyway gdb's symbol reader seems to assign
it TYPE_CODE_INT. If that's wrong please say so.
The "x" command evaluates its argument and we arrive in
findvar.c:read_var_value
case LOC_LABEL:
/* Put the constant back in target format. */
...
store_typed_address (VALUE_CONTENTS_RAW (v), type,
SYMBOL_VALUE_ADDRESS (var));
store_typed_address hates arguments of TYPE_CODE_INT so
we die.
/* Store the address ADDR as a pointer of type TYPE at BUF, in target
form. */
void
store_typed_address (void *buf, struct type *type, CORE_ADDR addr)
{
if (TYPE_CODE (type) != TYPE_CODE_PTR
&& TYPE_CODE (type) != TYPE_CODE_REF)
internal_error (__FILE__, __LINE__,
"store_typed_address: "
"type is not a pointer or reference");
ADDRESS_TO_POINTER (type, buf, addr);
}
Should the label not have been assigned TYPE_CODE_INT during symbol
reading?
If the label's type is correct, then is store_typed_address too
picky? Or should read_var_value() be calling the weaker
store_signed_integer instead of store_typed_address to
accommodate Elf32 on a 64-bit architecture?
Elf32 on 64-bit strikes me as weird, in that pointers are not the
same size as addresses. I don't know how that is handled
throughout the gdb framework.
Thanks for any enlightenment!