gdb/251: The $fp problem
ac131313@cygnus.com
ac131313@cygnus.com
Thu Oct 18 18:35:00 GMT 2001
>Number: 251
>Category: gdb
>Synopsis: The $fp problem
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Nov 30 20:18:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator: EOF causes recursive internal error
>Release: unknown-1.0
>Organization:
>Environment:
>Description:
Some targets, such as ARM, have a ``frame pointer register'' or $fp. That register might be used as the frame base address but not necessarily (-fomit-frame-pointer).
Separatly, GDB provides a number of built-in registers including $fp. Here $fp is the current functions frame base as computed using debug info and other magic.
According to the doco: ``When ever possible, these four standard register names [$fp is one] are available on your machine even though the machine has different cannonical mnemonics, so long as there is no conflict.''
Problem is, GDB got it wrong. Instead, the user finds that:
info registers fp
prints the target $fp while
print $fp
prints the GDB built-in FP. I.e. the target register does not override the built-in register.
>How-To-Repeat:
>Fix:
(this is strictly theory but I don't think it is far off :-)
The problem occures because FP_REGNUM is overloaded.
target_map_name_to_register("fp") first searches the target architecture register name space and then the built-in register name space. Problem is, it returns FP_REGNUM for both cases.
Consequently, code such as read_relative_register_raw_bytes_for_frame() will always intercept a read of FP_REGNUM and map that onto the built-in register.
The fix is to kick the built-in FP regnum out of the target architecture's range of registers.
That is, if the target architecture has an $fp register, it is designated by FP_REGNUM - in the range [0 .. NUM_REGS + NUM_PSEUDO_REGS). If there is no architecture specific $fp, then the $fp register is identified using BUILTIN_FP_REGNUM - in [NUM_REGS + NUM_PSUEDO_REGS ..).
Since the code checking for the built-in register would be testing for BUILTIN_FP_REGNUM it would blissfully ignore (not intercept) any accesses to the target architectures FP_REGNUM.
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the Gdb-prs
mailing list