store_typed_address dies on label evaluation

Kevin Nomura <[email protected]>
Newsgroups gmane.comp.gdb.bugs.general
Message-ID <[email protected]>
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!



_______________________________________________
Bug-gdb mailing list
[email protected]
http://mail.gnu.org/mailman/listinfo/bug-gdb
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.