From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-28258-listarch-gdb-patches=sources.redhat.com@sources.redhat.com>
Received: (qmail 1972 invoked by alias); 28 Oct 2003 21:58:19 -0000
Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-patches-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sources.redhat.com>
List-Help: <mailto:gdb-patches-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-patches-owner@sources.redhat.com
Received: (qmail 1965 invoked from network); 28 Oct 2003 21:58:16 -0000
Received: from unknown (HELO mx01.netapp.com) (198.95.226.53)
  by sources.redhat.com with SMTP; 28 Oct 2003 21:58:16 -0000
Received: from frejya.corp.netapp.com (frejya [10.10.20.91])
	by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id h9SLwG4Z001909
	for <gdb-patches@sources.redhat.com>; Tue, 28 Oct 2003 13:58:16 -0800 (PST)
Received: from bughouse.hq.netapp.com (bughouse.hq.netapp.com [10.34.24.48])
	by frejya.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id h9SLwFvj015363
	for <gdb-patches@sources.redhat.com>; Tue, 28 Oct 2003 13:58:15 -0800 (PST)
Received: from bughouse.hq.netapp.com (localhost.localdomain [127.0.0.1])
	by bughouse.hq.netapp.com (8.12.8/8.12.8) with ESMTP id h9SLwEfu021999
	for <gdb-patches@sources.redhat.com>; Tue, 28 Oct 2003 13:58:14 -0800
Received: (from nomura@localhost)
	by bughouse.hq.netapp.com (8.12.8/8.12.7/Submit) id h9SLwEQe021997
	for gdb-patches@sources.redhat.com; Tue, 28 Oct 2003 13:58:14 -0800
Date: Tue, 28 Oct 2003 21:58:00 -0000
From: Kevin Nomura <nomura@netapp.com>
To: gdb-patches@sources.redhat.com
Subject: inconsistent sigtramp code in mips target
Message-ID: <20031028215814.GY4320@bughouse.netapp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-SW-Source: 2003-10/txt/msg00819.txt.bz2

gdb 6.0, file gdb/mips-tdep.c, function mips_find_saved_regs:

There are calls to "set_reg_offset" in a loop, followed by
some individual calls after the loop.  The latter have
no effect if the register was processed in the loop
(see the code for set_reg_offset).  SP_REGNUM is like this,
but PC_REGNUM is not, because of the particular values of
these constants (ugh).


  if ((get_frame_type (fci) == SIGTRAMP_FRAME))
    {
      for (ireg = 0; ireg < MIPS_NUMREGS; ireg++)
        {
          CORE_ADDR reg_position = (get_frame_base (fci) + SIGFRAME_REGSAVE_OFF
                                    + ireg * SIGFRAME_REG_SIZE);
          set_reg_offset (saved_regs, ireg, reg_position);
        }
      for (ireg = 0; ireg < MIPS_NUMREGS; ireg++)
        {
          CORE_ADDR reg_position = (get_frame_base (fci)
                                    + SIGFRAME_FPREGSAVE_OFF
                                    + ireg * SIGFRAME_REG_SIZE);
          set_reg_offset (saved_regs, FP0_REGNUM + ireg, reg_position);
        }

      set_reg_offset (saved_regs, PC_REGNUM, get_frame_base (fci) + SIGFRAME_PC_OFF);
      /* SP_REGNUM, contains the value and not the address.  */
      set_reg_offset (saved_regs, SP_REGNUM, get_frame_base (fci));
      return;
    }


The logical patch would be to move the special cases up front,
but I have no way to test this out (no access to a MIPS UNIX
platform).

On the other hand this isn't purely academic.  I came across this
because I need to define a custom sigtramp frame for our own
MIPS embedded platform.  It was baffling for a while that my
modification to the SP_REGNUM override had no effect.