Re: [RFA] New GDB target iq2000

Daniel Jacobowitz
2005-03-04T22:01:10Z

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.

Could you try the attached patch, which explains what I meant?

I left the other function alone. skip_prologue_using_sal is already a
bit bogus, for the reasons identified by Kevin as well as for at least
one other that I can see. find_last_line_symbol is even boguser.
Basically, any code that compares the LINE member of two arbitrary SALs
_must_ be wrong. They don't even need to be in the same source file.

There's two things that GDB uses the guessed prologue line information
for. One is to place an initial breakpoint, so that the arguments have
been saved. This problem will hopefully eventually go away, with
improved GCC -fvar-tracking - we should be able to print the arguments
from anywhere. Someone needs to spend a little love on the compiler
side of this.

The other is as a limit for prologue scanners. IMO, what you need in
iq2000_scan_prologue is not line table data at all, but a list of
instructions which can not be considered part of the prologue.
Basically that is calls and branches, and a check that you only record
a register save the first time you see the register being saved.
Going too far here is not a major problem; after the patch below, I
think the call in iq2000_skip_prologue is basically redundant.
Returning FUNC_ADDR would work just about as well, since if we have no
line data, we probably have no symbolic argument information either.

--
Daniel Jacobowitz
CodeSourcery, LLC

Index: src/gdb/iq2000-tdep.c
===================================================================
--- src.orig/gdb/iq2000-tdep.c 2005-03-04 16:05:39.000000000 -0500
+++ src/gdb/iq2000-tdep.c 2005-03-04 16:39:49.000000000 -0500
@@ -335,20 +335,17 @@ iq2000_init_frame_cache (struct iq2000_f
static CORE_ADDR
iq2000_skip_prologue (CORE_ADDR pc)
{
- CORE_ADDR func_addr = 0 , func_end = 0;
+ CORE_ADDR func_addr = 0, func_end = 0, ret;
+
+ ret = skip_prologue_using_sal (pc);
+ if (ret)
+ return max (ret, pc);

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. */
+ /* Found a function. Use prologue parsing method. */
iq2000_init_frame_cache (&cache);
return iq2000_scan_prologue (func_addr, func_end, NULL, &cache);
}