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
next prev parent 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