Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Kei Sakamoto" <sakamoto.kei@renesas.com>
To: "Andrew Cagney" <cagney@gnu.org>
Cc: <gdb-patches@sources.redhat.com>
Subject: Re: [RFA/m32r] Fix m32r  frame analyzer
Date: Thu, 07 Oct 2004 01:26:00 -0000	[thread overview]
Message-ID: <014801c4ac0c$a7de1130$5169910a@E5A02646> (raw)
In-Reply-To: <41642A1C.2010603@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

> The save_read_memory will need to be in decode_prologue and applied to
> every memory read as a fetch of PC+/-4 could equally fail.  That means
> more interface changes to decode_prologue (return success/fail?).
> 
> On fail, it should also return the old PC and not zero - look at
> find_function_start_sal for why.
> 
> If you make those changes, you can commit.
> 
> Andrew

I revised my patch and committed it. Thank you.

Kei Sakamoto

2004-10-07  Kei Sakamoto  <sakamoto.kei@renesas.com>

        * m32r-tdep.c (decode_prologue): Support functions written
        in assembler language. Recognize trap instructions as the
        end of prologue.
        (m32r_frame_unwind_cache): Ditto.
        (m32r_skip_prologue): Extend search limit. Quit analyzing
        prologue if pc's location is not readable.

[-- Attachment #2: m32r-tdep.patch --]
[-- Type: application/octet-stream, Size: 4083 bytes --]

Index: m32r-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/m32r-tdep.c,v
retrieving revision 1.32
diff -r1.32 m32r-tdep.c
3c3
<    Copyright 1996, 1998, 1999, 2000, 2001, 2002, 2003 Free Software
---
>    Copyright 1996, 1998, 1999, 2000, 2001, 2002, 2003, 2004 Free Software
259c259
< static void
---
> static int
261c261
< 		 CORE_ADDR *pl_endptr)
---
> 		 CORE_ADDR *pl_endptr, unsigned long *framelength)
266d265
<   int maybe_one_more = 0;
267a267
>   CORE_ADDR after_push = 0;
269a270
>   LONGEST return_value;
275a277,280
>       /* Check if current pc's location is readable. */
>       if (!safe_read_memory_integer (current_pc, 2, &return_value))
> 	return -1;
> 
277a283,285
>       if (insn == 0x0000)
> 	break;
> 
282,293d289
< 	  /* Clear the parallel execution bit from 16 bit instruction */
< 	  if (maybe_one_more)
< 	    {
< 	      /* The last instruction was a branch, usually terminates
< 	         the series, but if this is a parallel instruction,
< 	         it may be a stack framing instruction */
< 	      if (!(insn & 0x8000))
< 		{
< 		  /* nope, we are really done */
< 		  break;
< 		}
< 	    }
299,300d294
< 	  if (maybe_one_more)
< 	    break;		/* This isnt the one more */
304a299
> 
305a301,305
> 
> 	      /* Check if current pc's location is readable. */
> 	      if (!safe_read_memory_integer (current_pc, 2, &return_value))
> 		return -1;
> 
314a315,316
> 		      && safe_read_memory_integer (current_pc + 2, 2,
> 						   &return_value)
327c329
< 	      after_prologue = current_pc;
---
> 	      after_push = current_pc + 2;
365a368
> 
371a375,380
>       /* End of prolog if any of these are trap instructions */
>       if ((insn & 0xfff0) == 0x10f0)
> 	{
> 	  after_prologue = current_pc;
> 	  break;
> 	}
376d384
< 	  maybe_one_more = 1;
386d393
< 	      maybe_one_more = 1;
391a399,401
>   if (framelength)
>     *framelength = framesize;
> 
402a413,419
> 	  else if (after_push != 0)
> 	    /* We did not find a "mv fp,sp", but we DID find
> 	       a push.  Is it safe to use that as the
> 	       end of the prologue?  I just don't know. */
> 	    {
> 	      *pl_endptr = after_push;
> 	    }
410c427
<       return;
---
>       return 0;
411a429
> 
416a435,436
> 
>   return 0;
422c442
< #define DEFAULT_SEARCH_LIMIT 44
---
> #define DEFAULT_SEARCH_LIMIT 128
428a449
>   LONGEST return_value;
450c471,479
<   decode_prologue (pc, func_end, &sal.end);
---
> 
>   /* If pc's location is not readable, just quit. */
>   if (!safe_read_memory_integer (pc, 4, &return_value))
>     return pc;
> 
>   /* Find the end of prologue.  */
>   if (decode_prologue (pc, func_end, &sal.end, NULL) < 0)
>     return pc;
> 
454d482
< 
483c511
<   CORE_ADDR pc;
---
>   CORE_ADDR pc, scan_limit;
486c514
<   unsigned long op;
---
>   unsigned long op, op2;
489a518
> 
499d527
< 
500a529,530
> 
>   scan_limit = frame_pc_unwind (next_frame);
502c532
<        pc > 0 && pc < frame_pc_unwind (next_frame); pc += 2)
---
>        pc > 0 && pc < scan_limit; pc += 2)
516,517c546,547
< 	      else if (((op >> 8) == 0xe4)	/* ld24 r4, xxxxxx; sub sp, r4 */
< 		       && get_frame_memory_unsigned (next_frame, pc + 4,
---
> 	      else if (((op >> 8) == 0xe4)
> 		       && get_frame_memory_unsigned (next_frame, pc + 2,
519a550
> 		  /* ld24 r4, xxxxxx; sub sp, r4 */
522c553
< 		  pc += 2;
---
> 		  pc += 2;	/* skip sub instruction */
524,525d554
< 	      else
< 		break;
527c556,558
< 	      pc += 2;
---
> 	      if (pc == scan_limit)
> 		scan_limit += 2;	/* extend the search */
> 	      pc += 2;		/* skip the immediate data */
551a583,588
> 	  break;		/* end of stack adjustments */
> 	}
>       else if ((op & 0xfff0) == 0x10f0)
> 	{
> 	  /* end of prologue if this is a trap instruction */
> 	  break;		/* end of stack adjustments */
553,557d589
<       else if (op == 0x7000)
< 	/* nop */
< 	continue;
<       else
< 	break;

      reply	other threads:[~2004-10-07  1:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-05 10:13 Kei Sakamoto
2004-10-06 17:24 ` Andrew Cagney
2004-10-07  1:26   ` Kei Sakamoto [this message]

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='014801c4ac0c$a7de1130$5169910a@E5A02646' \
    --to=sakamoto.kei@renesas.com \
    --cc=cagney@gnu.org \
    --cc=gdb-patches@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