Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: gdb-patches@sources.redhat.com
Subject: Re: [RFA] New GDB target iq2000
Date: Thu, 03 Mar 2005 17:34:00 -0000	[thread overview]
Message-ID: <20050303173443.GD18681@nevyn.them.org> (raw)
In-Reply-To: <20050222114141.GA18314@cygbert.vinschen.de>

On Tue, Feb 22, 2005 at 12:41:41PM +0100, Corinna Vinschen wrote:
> Hi,
> 
> this posting contributes the iq2000 code for GDB.
> 
> There's just one problem with it.  Older GCC code (older than two days,
> actually), emits an asymmetrical register numbering in the dwarf2 debugging
> output.  The iq2000 uses register 31 as link register, which contains the
> return address to the calling function.  For some reason GCC emitted the
> register number 26 in the dwarf2 information for this register.  Every
> other register has been used unchanged in dwarf2, so there was no
> unambiguous translation from dwarf2 register numbers to real register
> numbers, if the dwarf2 register was "26".  This has been fixed yesterday
> in GCC HEAD.
> 
> As a result, the dwarf2 frame sniffer has a problem with code generated
> by GCC's older than two days.  This is no problem for the iq2000 frame
> sniffer implemented in iq2000-tdep.c, but as usual, the iq2000 frame
> sniffer is appended after the dwarf2 frame sniffer:
> 
>     frame_unwind_append_sniffer (gdbarch, dwarf2_frame_sniffer);
>     frame_unwind_append_sniffer (gdbarch, iq2000_frame_sniffer);
> 
> Would that be a good reason to disable the dwarf2 frame sniffer for now?
> Or shall I leave that as is?

It's up to you; I think leaving it as is and writing off the problem as
a broken compiler will probably be good enough for the iq2000 userbase.
If it isn't, we can come back to the problem later.

It looks good to me, but I have one concern.  You've got
find_last_line_symbol:

> +/* Function: find_last_line_symbol
> +
> +   Given an address range, first find a line symbol corresponding to
> +   the starting address.  Then find the last line symbol within the 
> +   range that has a line number less than or equal to the first line.
> +
> +   For optimized code with code motion, this finds the last address
> +   for the lowest-numbered line within the address range.  */

And you've got this too:

> +static CORE_ADDR
> +iq2000_skip_prologue (CORE_ADDR pc)
> +{
> +  CORE_ADDR func_addr = 0 , func_end = 0;
> +
> +  if (find_pc_partial_function (pc, NULL, & func_addr, & func_end))
> +    {
> +      struct symtab_and_line sal;
> +      struct iq2000_frame_cache cache;
> +
> +      /* Found a function.  */
> +      sal = find_pc_line (func_addr, 0);
> +      if (sal.end && sal.end < func_end)
> +	/* Found a line number, use it as end of prologue.  */
> +	return sal.end;
> +
> +      /* No useable line symbol.  Use prologue parsing method.  */
> +      iq2000_init_frame_cache (&cache);
> +      return iq2000_scan_prologue (func_addr, func_end, NULL, &cache);
> +    }
> +
> +  /* No function symbol -- just return the PC.  */
> +  return (CORE_ADDR) pc;
> +}

I'm trying to cut down on the proliferation of linetable-aware code in
tdep files.  We've already got skip_prologue_using_sal, which is
similar but not quite the same.  Will that work for iq2000?  Failing
that, should the new method be used on other targets?  There's nothing
iq2000 specific about it.


-- 
Daniel Jacobowitz
CodeSourcery, LLC


  parent reply	other threads:[~2005-03-03 17:34 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-22 16:35 Corinna Vinschen
2005-03-01 22:13 ` Jim Blandy
2005-03-01 22:19   ` Daniel Jacobowitz
2005-03-02  9:08   ` Corinna Vinschen
2005-03-03 17:34 ` Daniel Jacobowitz [this message]
2005-03-03 17:46   ` Kevin Buettner
2005-03-03 17:51     ` Daniel Jacobowitz
2005-03-03 19:17       ` Kevin Buettner
2005-03-04  9:46   ` Corinna Vinschen
2005-03-04 14:14     ` Daniel Jacobowitz
2005-03-04 15:01       ` Corinna Vinschen
2005-03-04 15:06         ` Daniel Jacobowitz
2005-03-04 15:51           ` Corinna Vinschen
2005-03-04 16:01             ` Daniel Jacobowitz
2005-03-04 22:01         ` Daniel Jacobowitz
2005-03-05 11:29           ` Mark Kettenis
2005-03-05 16:44             ` Daniel Jacobowitz
2005-03-05 18:13               ` Mark Kettenis
2005-03-05 19:37                 ` Daniel Jacobowitz
2005-03-05 20:18                   ` Mark Kettenis
2005-03-05 20:20                     ` Daniel Jacobowitz
2005-03-07 10:08                       ` Corinna Vinschen
2005-03-07 14:05                         ` Daniel Jacobowitz
2005-03-07 20:17                           ` Corinna Vinschen
2005-03-07 20:37                             ` Daniel Jacobowitz
2005-03-08  9:00                               ` Corinna Vinschen
2005-03-08 13:32                                 ` Daniel Jacobowitz
2005-03-07 21:32                   ` Daniel Jacobowitz
2005-03-07 21:35 ` Daniel Jacobowitz
2005-03-08  9:00   ` Corinna Vinschen

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=20050303173443.GD18681@nevyn.them.org \
    --to=drow@false.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