Re: [RFA] New GDB target iq2000

Daniel Jacobowitz
2005-03-04T15:06:37Z

On Fri, Mar 04, 2005 at 04:01:29PM +0100, Corinna Vinschen wrote:
> On Mar 4 09:14, Daniel Jacobowitz wrote:
> > On Fri, Mar 04, 2005 at 10:46:05AM +0100, Corinna Vinschen wrote:
> > > I'm sorry, but the reason for getting rid of linetable-aware code is
> > > somewhat beyond me.
> >
> > Because _there is nothing architecture specific about what you are
> > doing_. Therefore, most likely, it is either right for all platforms
> > or wrong for this one. I want to understand which. If it's right for
> > all platforms, I'd like it to live in common code so that we can
> > maintain it for all platforms.
>
> The platform specific part is to call iq2000_scan_prologue if the
> line number information is bogus.
>
> > > 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.
> >
> > Why? Is it the same problem Kevin described? As I wrote, I have
> > successfully used this function on other architectures.
>
> I haven't exactly analyzed the situation so far, but using
> skip_prologue_using_sal results in three more FAILs in the testsuite:
>
> FAIL: gdb.base/break.exp: breakpoint small function, optimized file
> FAIL: gdb.base/break.exp: run until breakpoint set at small function, optimized file
> FAIL: gdb.base/nodebug.exp: running to inner in runto
>
> All three cases don't look like simple coincidence. In all three cases
> we suffer from either optimized code or unavailable debug information.
> The target specific "knowledge", which is represented by the call to
> iq2000_scan_prologue helps to master this situation.

Would you mind posting disassembly, line table (readelf -wl), and GDB
transcript for these failures?

I'm not trying to block the inclusion of the iq2000 port, but I would
like to make sure we understand this problem before we include a
workaround.