Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@gnat.com>
To: Andrew Cagney <cagney@gnu.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch/rfc] Use frame_type for sigtramp test in infrun.c
Date: Tue, 06 Apr 2004 01:48:00 -0000	[thread overview]
Message-ID: <20040406014818.GN871@gnat.com> (raw)
In-Reply-To: <406E0CEA.7040906@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 4190 bytes --]

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 #2: hppa.txt --]
[-- Type: text/plain, Size: 5408 bytes --]

1  gdb.base/annota1.exp: Core dumped and removed                       PASS
2  gdb.base/annota1.exp: No core dumped                       PASS
3  gdb.base/call-ar-st.exp: continue to 1241                  FAIL     PASS
4  gdb.base/call-ar-st.exp: continue to 1281                  FAIL     PASS
5  gdb.base/call-ar-st.exp: continue to 1286                  FAIL     PASS
6  gdb.base/call-ar-st.exp: continue to 1300                  FAIL     PASS
7  gdb.base/call-ar-st.exp: continue to 1305                  FAIL     PASS
8  gdb.base/call-ar-st.exp: continue to 1311                  FAIL     PASS
9  gdb.base/call-ar-st.exp: continuing to 1236                FAIL     PASS
10 gdb.base/call-ar-st.exp: next to 1237                      FAIL     PASS
11 gdb.base/call-ar-st.exp: print compute_with_small_structs  FAIL     PASS
12 gdb.base/call-ar-st.exp: print print_bit_flags_combo from  FAIL     PASS
   init_bit_flags_combo
13 gdb.base/call-ar-st.exp: print print_one_large_struct      FAIL     PASS
14 gdb.base/call-ar-st.exp: print print_struct_rep            FAIL     PASS
15 gdb.base/call-ar-st.exp: print sum_array_print             FAIL     PASS
16 gdb.base/call-ar-st.exp: step into init_bit_flags_combo    FAIL     PASS
17 gdb.base/call-ar-st.exp: step into print_long_arg_list     FAIL     PASS
18 gdb.base/foll-fork.exp: default parent follow, no          FAIL     PASS
   catchpoints
19 gdb.base/foll-fork.exp: explicit child follow, catch fork  PASS
20 gdb.base/foll-fork.exp: explicit child follow, no          FAIL     PASS
   catchpoints
21 gdb.base/foll-fork.exp: explicit child follow, set catch   PASS
   fork
22 gdb.base/foll-fork.exp: explicit parent follow, no         FAIL     PASS
   catchpoints
23 gdb.base/foll-fork.exp: explicit parent follow, set tcatch PASS
   fork
24 gdb.base/foll-fork.exp: explicit parent follow, tcatch     PASS
   fork
25 gdb.base/foll-fork.exp: info shows catchpoint pid          PASS
26 gdb.base/foll-fork.exp: info shows catchpoint without pid  PASS
27 gdb.base/foll-fork.exp: set follow child, cleanup          PASS
28 gdb.base/foll-fork.exp: set follow child, hit tbreak       FAIL
29 gdb.base/foll-fork.exp: set follow child, tbreak           PASS
30 gdb.base/foll-fork.exp: set follow parent, cleanup         PASS
31 gdb.base/foll-fork.exp: set follow parent, hit tbreak      PASS
32 gdb.base/foll-fork.exp: set follow parent, tbreak          PASS
33 gdb.base/funcargs.exp: backtrace through call with         PASS     FAIL
   trampolines
34 gdb.base/funcargs.exp: stepping back to main from function PASS     FAIL
   called with trampolines
35 gdb.base/funcargs.exp: stepping into function called with  PASS     FAIL
   trampolines
36 gdb.base/selftest.exp: send SIGINT signal to child process PASS     FAIL
37 gdb.base/selftest.exp: send ^C to child process            PASS     FAIL
38 gdb.base/signals.exp: break func1                          PASS     FAIL
39 gdb.base/signals.exp: break func2                          PASS     FAIL
40 gdb.base/signals.exp: break handler                        PASS     FAIL
41 gdb.base/signals.exp: break handler if 0                   PASS
42 gdb.base/signals.exp: bt in signals.exp                    FAIL
43 gdb.base/signals.exp: condition $handler_breakpoint_number PASS
44 gdb.base/signals.exp: continue in signals.exp              FAIL
45 gdb.base/signals.exp: handle SIG parses all legal actions  PASS
46 gdb.base/signals.exp: handle SIG with bogus action         PASS
47 gdb.base/signals.exp: handle SIG with multiple conflicting PASS
   actions
48 gdb.base/signals.exp: handle multiple SIGs                 PASS
49 gdb.base/signals.exp: handle multiple SIGs via integer     PASS
   range
50 gdb.base/signals.exp: handle with bogus SIG                PASS
51 gdb.base/signals.exp: handle without arguments             PASS
52 gdb.base/signals.exp: info signal 5                        PASS
53 gdb.base/signals.exp: info signal SIGTRAP                  PASS
54 gdb.base/signals.exp: info signals                         PASS
55 gdb.base/signals.exp: invalid signal number rejected       PASS
56 gdb.base/signals.exp: next to ++count #1 in signals.exp    FAIL
57 gdb.base/signals.exp: next to ++count #2 in signals.exp    FAIL
58 gdb.base/signals.exp: next to 2nd alarm                    FAIL
59 gdb.base/signals.exp: next to 2nd alarm;                            FAIL
60 gdb.base/signals.exp: next to alarm #1 in signals.exp      PASS
61 gdb.base/signals.exp: next to alarm #2 in signals.exp      FAIL
62 gdb.base/signals.exp: next to signal in signals.exp        PASS
63 gdb.base/signals.exp: override SIGINT                      PASS
64 gdb.base/signals.exp: override SIGTRAP                     PASS
65 gdb.base/signals.exp: p count #1 in signals.exp            FAIL
66 gdb.base/signals.exp: p count #2 in signals.exp            FAIL
67 gdb.base/signals.exp: p func1 #1 in signals.exp            FAIL
68 gdb.base/signals.exp: p func1 #2 in signals.exp            FAIL
69 gdb.base/signals.exp: sent signal 5                        FAIL
70 gdb.base/signals.exp: set $handler_breakpoint_number =     PASS
   $bpnum
71 gdb.base/signals.exp: set variable count = 0               PASS
72 gdb.base/signals.exp: signal without arguments disallowed  FAIL
73 gdb.base/step-line.exp: next over dummy 2                  PASS     FAIL
74 gdb.base/step-line.exp: step into f2                       PASS     FAIL

  reply	other threads:[~2004-04-06  1:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-29 23:38 Ulrich Weigand
2004-03-31 21:49 ` Andrew Cagney
2004-04-02 20:50 ` Andrew Cagney
2004-04-02 23:57   ` Joel Brobecker
2004-04-03  0:08   ` Joel Brobecker
2004-04-03  1:01     ` Andrew Cagney
2004-04-06  1:48       ` Joel Brobecker [this message]
2004-04-06 16:21         ` Joel Brobecker
2004-04-06 17:48           ` Andrew Cagney
2004-04-06 17:54             ` Daniel Jacobowitz
2004-04-06 18:11               ` Andrew Cagney
2004-04-06 23:33                 ` Andrew Cagney
2004-04-29 22:46         ` Andrew Cagney
  -- strict thread matches above, loose matches on Subject: below --
2004-03-16 18:57 Andrew Cagney
2004-03-19  0:09 ` Andrew Cagney
2004-03-21 22:38 ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040406014818.GN871@gnat.com \
    --to=brobecker@gnat.com \
    --cc=cagney@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox