public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: "Theodore A. Roth" <troth@openavr.org>
To: Andrew Cagney <ac131313@redhat.com>
Cc: gdb@sources.redhat.com
Subject: Re: avr and frame unwinding
Date: Sat, 07 Jun 2003 20:23:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.44.0306071257490.28721-100000@bozoland.mynet> (raw)
In-Reply-To: <3EDFF5D5.5060704@redhat.com>

On Thu, 5 Jun 2003, Andrew Cagney wrote:

:)Can you try the exact same operation with a GDB that doesn't have the 
:)changes?  That way it should be possible to compare the two traces 
:)side-by-side and see where things are going wrong.
:)
:)A guess is that it is getting the unwound PC value wrong.  For the d10v 

That was the problem. I've got it working, but the solution was ugly (see 
below).

:)I had to make two tweaks:
:)
:)- abort the prologue scanner when it reached PC if that is before the 
:)end of the prologue
:)This stopped the prologue getting the unwound PC's location wrong.  It 
:)may not have yet executed the save PC instruction.

This seems to also hold for the avr. Adding the extra pc check before
prologue scanning like the d10v does got things working as far as stepping
and backtracing go.

:)
:)- track the register that the PC is in before it is saved
:)The code needs to be able to unwind the PC value in the prologue before 
:)it has been saved on the stack.
:)
:)Andrew
:)

Thanks for the nudge Andrew.

Any idea how to make this piece of code sane? I'm not thrilled with what I 
had to do to get the PC read and converted then finally stored in bufferp. 
This function is analogous to saved_regs_unwinder() in d10v-tdep.c.

static void
avr_saved_regs_unwinder (struct frame_info *next_frame,
                         CORE_ADDR *this_saved_regs,
                         int regnum, int *optimizedp,
                         enum lval_type *lvalp, CORE_ADDR *addrp,
                         int *realnump, void *bufferp)
{
  if (this_saved_regs[regnum] != 0)
    {
      *optimizedp = 0;
      *lvalp = lval_memory;
      *addrp = this_saved_regs[regnum];
      *realnump = -1;
      if (bufferp != NULL)
        {
          /* Read the value in from memory.  */

          if (regnum == AVR_PC_REGNUM)
            {
              /* Reading the return PC from the PC register is slightly
                 abnormal.  register_size(AVR_PC_REGNUM) says it is 4 bytes,
                 but in reality, only two bytes (3 in upcoming mega256) are
                 stored on the stack.

                 Also, note that the value on the stack is an addr to a word
                 not a byte, so we will need to multiply it by two at some
                 point.  */

              ULONGEST pc;
              unsigned char buf[2];

              read_memory (this_saved_regs[regnum], buf, sizeof (buf));
              pc = (extract_unsigned_integer (buf, 2) * 2) >> 8;
              memcpy (bufferp, &pc, sizeof(pc));
            }
          else
            {
              read_memory (this_saved_regs[regnum], bufferp,
                           register_size (current_gdbarch, regnum));
            }
        }

      return;
    }

  /* No luck, assume this and the next frame have the same register
     value.  If a value is needed, pass the request on down the chain;
     otherwise just return an indication that the value is in the same
     register as the next frame.  */
  frame_register_unwind (next_frame, regnum, optimizedp, lvalp, addrp,
			 realnump, bufferp);
}


The last problem I need to solve I think is also related to register
unwinding. If I step down into a function, then 'up' to move up the stack
frame, examining a local variable gives the wrong value. I need to do some
more research into why this is happening though. Am I on the right track
with thinking the register unwinding could be the problem? Maybe I'm setting 
the frame base incorrectly since it doesn't seem to resolve the variable's 
memory address?

Ted Roth

  reply	other threads:[~2003-06-07 20:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-06  0:35 Theodore A. Roth
2003-06-06  2:01 ` Andrew Cagney
2003-06-07 20:23   ` Theodore A. Roth [this message]
2003-06-07 22:37     ` Andrew Cagney
2003-06-08  0:26       ` Theodore A. Roth
2003-06-08 17:51         ` Theodore A. Roth
2003-06-08 19:15           ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44.0306071257490.28721-100000@bozoland.mynet \
    --to=troth@openavr.org \
    --cc=ac131313@redhat.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).