This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] "info registers" is misleading


Fred,

Have a look through gdb/521.

http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=251&return_url=http%3A%2F%2Fsources.redhat.com%2Fcgi-bin%2Fgnatsweb.pl%3Fdatabase%3Dgdb%26category%3Dall%26severity%3Dall%26priority%3Dall%26responsible%3Dall%26submitter_id%3Dall%26state%3Dall%26ignoreclosed%3DIgnore%2520Closed%26class%3Dall%26synopsis%3D%26multitext%3D%26columns%3Dcategory%26columns%3Dstate%26columns%3Dresponsible%26columns%3Dsynopsis%26displaydate%3DDisplay%2520Current%2520Date%26cmd%3Dsubmit%2520query%26sortby%3DResponsible%26.cgifields%3Dcolumns%26.cgifields%3Doriginatedbyme%26.cgifields%3Ddisplaydate%26.cgifields%3Dignoreclosed

(I don't know of the attached link will work or not)
Andrew
Title: View PR 251 - gnatsweb
gdb  User: guest  Access: viewconf gnatsweb
MAIN PAGECREATEQUERYADV. QUERYLOGIN AGAINHELP

View Problem Report: 251

or send email to interested parties


Reporter's email: ac131313@cygnus.com
CC these people
on PR status email:
   
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.
File Attachments:
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:
Unformatted:

or send email to interested parties

Audit Trail:


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]