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: Corinna Vinschen <vinschen at redhat dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Fri, 4 Mar 2005 10:46:05 +0100
- Subject: Re: [RFA] New GDB target iq2000
- References: <20050222114141.GA18314@cygbert.vinschen.de> <20050303173443.GD18681@nevyn.them.org>
- Reply-to: gdb-patches at sources dot redhat dot com
On Mar 3 12:34, Daniel Jacobowitz wrote:
> On Tue, Feb 22, 2005 at 12:41:41PM +0100, Corinna Vinschen wrote:
> > 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.
Sounds like a plan to me.
> 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. */
What's your exact concern with this function? It's just used inside
of the iq2000 prologue scanner to decide if the scanning loop should
break or continue.
> 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.
Except for calling iq2000_scan_prologue, a function which is entirely
internal to the iq2000 code and not available through the gdbarch framework.
I'm sorry, but the reason for getting rid of linetable-aware code is
somewhat beyond me. I'll happily do something else, as far as it's
available and works, but using skip_prologue_using_sal is really no
option here.
Any chance I can apply the code, after removing the
set_gdbarch_decr_pc_after_break call?
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.