This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] new BASEREG_ADDRESS macro
- To: Nicholas Duffek <nsd at redhat dot com>
- Subject: Re: [RFA] new BASEREG_ADDRESS macro
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Fri, 12 Jan 2001 22:01:15 +0930
- Cc: gdb-patches at sources dot redhat dot com
- References: <200101032041.PAA14830@nog.bosbc.com>
Nicholas Duffek wrote:
>
> Recently I worked on an architecture in which the stack pointer, frame
> pointer, and addresses in other address registers are relative to an
> offset stored in a special register.
>
> Consequently, when GDB uses an address in one of those registers, e.g. to
> read a LOC_BASEREG symbol's value, the address must be modified by the
> offset address.
>
> This patch introduces a new multi-arch macro, BASEREG_ADDRESS(addr), which
> gives targets the opportunity to adjust addresses retrieved from
> SYMBOL_BASEREG(var) registers.
>
> The default value for BASEREG_ADDRESS is core_addr_identity(addr), a new
> function that returns its argument unchanged.
Can you think of a name other than BASEREG_ADDRESS() that better
reflects the transformation being performed? Have a look through gdbint
for ideas.
Reading the code:
get_saved_register (buf, NULL, NULL, frame, SYMBOL_BASEREG
(var),
NULL);
addr = extract_address (buf, REGISTER_RAW_SIZE (SYMBOL_BASEREG
(var)));
+ addr = BASEREG_ADDRESS (addr);
addr += SYMBOL_VALUE (var);
break;
}
my first guess was that BASEREG_ADDRESS returns the address of the
register BASE in, at or near ``addr''.
It also needs a gdbint.texi entry.
enjoy,
Andrew