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
next prev parent 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).