Re: [patch/rfc] Use frame_type for sigtramp test in infrun.c

[Joel Brobecker <brobecker at gnat dot com>]

Andrew,

> >Just to make sure we're talking about the same patch, attached is the
> >patch I was working on (may need to be updated to the current sources).
> >Is that what you were refering to?
> 
> Yes, but no longer worry about the if(legacy_frame_p) path.

I have tested the attached patch on several platforms, and as expected,
found a few regression here and there. I started analyzing the
regressions on hp/ux, but this takes time, and I have to do something
else for a while. A quick glance doesn't say much about the source of
regressions, but my feeling after the few ones that I analyzed is that
they are a consequence of a latent bug somewhere else more than a
problem with the patch itself.  The fact that we have no regression on
both x86-linux and sparc-solaris is also encouraging. 

Below is a quick summary of the difference in the testsuite results
before and after the patch. It sounded like this patch would make your
life much easier. I'll let you and the other maintainers decide whether
it's acceptable to include this patch now, as a small step backward to
allow you to jump farther.

2004-04-05  Joel Brobecker  <brobecker@gnat.com>

        * infrun.c (handle_inferior_event): Rely on frame IDs to detect
        function calls.

Tested on x86-linux and sparc-solaris 2.8: No regression.

On hppa32 (hppa-hp-hpux11.00), we can argue that it's not necessarily
worse. We do have some improvement too. See hppa.txt attached.

On alpha-tru64, we have two regressions, but they are actually one
regression (we do the test twice in mi, and mi2), and it is really
minor:

        1  gdb.mi/mi-until.exp: until after while loop    PASS  FAIL
        2  gdb.mi/mi2-until.exp: until after while loop   PASS  FAIL
        
        The behavior remains the same, except we also get this warning:
        warning: (Internal error: pc 0x1200011c4 in read in psymtab,
        but not in symtab.)

On powerpc-aix 5.1, I get the following results:

        1 gdb.mi/gdb669.exp: next, try 1                  PASS  FAIL
        2 gdb.mi/gdb669.exp: next, try 2                  PASS  FAIL
        3 gdb.mi/gdb669.exp: next, try 3                  PASS  FAIL
        4 gdb.mi/mi2-pthreads.exp: mi runto 
          done_making_threads                             FAIL  PASS

Again, I think the regression do not show a problem with the patch
itself. I get the following output for the first failure:

     ~"[Switching to Thread 258]\n"^M
     220*stopped,reason="signal-received",signal-name="SIGTRAP",signal-meaning="Trace/breakpoint trap",thread-id="2",frame={addr="0x00000000",func="??",args=[]}^M

Thread support has been badly broken for me. I started investigating
a while ago but couldn't understand where this SIGTRAP was coming from
and had to pull out and work on some more urgent things. Still on my
list. (any hint as to how to track down that problem appreciated, btw :-).

Is for the other two failures, they *seem* to be a consequence of the
first one:

    &"Cannot find bounds of current function\n"^M
    220^error,msg="Cannot find bounds of current function"^M
    
I also ran the testsuite on an amd64-linux machine, and I know there
were some regressions there. Unfortunately, the machine appears to be
down right now, so I probably won't have access to it before tomorrow.
If my memory serves me well, I think there were 30 or 40 differences.

I didn't test it on mips-irix, though, because I've been having some
severe problems with that port :-/. I haven't had time to investigate
whether this is a build problem on my side, or some problem with the
code. But right now, GDB on that platform simply does not work, not even
"break main; run". Building without -O2 helps a bit, which suggests
either an optimization bug, or a code problem, such as an undefined
variable for instance. I'll have to investigate when I have a moment.

I'll let you decide whether the patch is acceptable or not. Sorry to
suggest this patch like this. I really want to get to the bottom of
these regressions, but I simply don't have the time right now. If you
didn't mention about it helping you with the frame code, I would
probably have delayed a bit its re-submission.

-- 
Joel

Attachment: hppa.txt
Description: Text document