2007-06-09 Markus Deuling <deuling@de.ibm.com>

* gdbarch.sh (ADDR_BITS_REMOVE): Replace by gdbarch_addr_bits_remove.
	* value.c (value_as_address): Likewise (comment).
	* remote-mips.c (common_breakpoint): Likewise.
	* regcache.c (read_pc_pid): Likewise.
	* printcmd.c (do_one_display): Likewise.
	* monitor.c (monitor_write_memory, monitor_read_memory)
	(monitor_insert_breakpoint): Likewise.
	* mips-tdep.c (heuristic_proc_start): Likewise.
	* infrun.c (insert_step_resume_breakpoint_at_frame)
	(insert_step_resume_breakpoint_at_caller): Likewise.
	* buildsym.c (record_line): Likewise.
	* arm-tdep.c (arm_scan_prologue, thumb_get_next_pc)
	(arm_get_next_pc): Likewise.
	* armnbsd-nat.c (arm_supply_gregset, fetch_register, store_register)
	(store_regs): Likewise.
	* arm-linux-tdep.c (arm_linux_supply_gregset): Likewise.
	* arm-linux-nat.c (fetch_register, fetch_regs): Likewise.
	* gdbarch.c, gdbarch.h: Regenerate.
This commit is contained in:
Ulrich Weigand 2007-06-09 13:49:20 +00:00
parent c9f4d5725d
commit bf6ae4641c
16 changed files with 70 additions and 49 deletions

View file

@ -962,10 +962,10 @@ value_as_address (struct value *val)
/* Assume a CORE_ADDR can fit in a LONGEST (for now). Not sure
whether we want this to be true eventually. */
#if 0
/* ADDR_BITS_REMOVE is wrong if we are being called for a
/* gdbarch_addr_bits_remove is wrong if we are being called for a
non-address (e.g. argument to "signal", "info break", etc.), or
for pointers to char, in which the low bits *are* significant. */
return ADDR_BITS_REMOVE (value_as_long (val));
return gdbarch_addr_bits_remove (current_gdbarch, value_as_long (val));
#else
/* There are several targets (IA-64, PowerPC, and others) which