[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
store_typed_address dies on label evaluation
From: |
Kevin Nomura |
Subject: |
store_typed_address dies on label evaluation |
Date: |
15 Aug 2002 15:16:58 -0700 |
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!
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- store_typed_address dies on label evaluation,
Kevin Nomura <=