This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] New GDB target iq2000
- From: Daniel Jacobowitz <drow at false dot org>
- To: gdb-patches at sources dot redhat dot com
- Date: Thu, 3 Mar 2005 12:34:43 -0500
- Subject: Re: [RFA] New GDB target iq2000
- References: <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