From: Stan Shebs <shebs@cygnus.com>
To: guo@cup.hp.com
Cc: ac131313@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: (patch) hpjyg15: hppah-nat.c & related
Date: Thu, 11 Nov 1999 16:46:00 -0000 [thread overview]
Message-ID: <199911120046.QAA29304@andros.cygnus.com> (raw)
In-Reply-To: <Pine.LNX.4.10.9911111610120.6426-100000@hpcll168.cup.hp.com>
Date: Thu, 11 Nov 1999 16:31:10 -0800 (PST)
From: Jimmy Guo <guo@cup.hp.com>
I'm aware of this problem and I'm trying to resolve this. Interestly,
yes I'm reversing what indent did, _not_ to create noises, but to remove
them. If you run indent on, say hppah-nat.c, straight from the 19991108
snapshot, you will see that it's not in GDB's coding style (since indent
is not happy with the way the code is!)
I've seen some inconsistent behavior from indent, and was planning to
investigate further one of these days. Nothing to get too excited
about, the oddities amounting to about ~100 in 400K lines of code,
but good to be aware of. diff -w is useful for separating out the
"real" diffs from the uninteresting ones.
Stan
From guo@cup.hp.com Thu Nov 11 16:47:00 1999
From: Jimmy Guo <guo@cup.hp.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: (patch) hpjyg15a, was Re: (patch) hpjyg15: hppah-nat.c & related
Date: Thu, 11 Nov 1999 16:47:00 -0000
Message-id: <Pine.LNX.4.10.9911111640190.6426-100000@hpcll168.cup.hp.com>
References: <382B5609.A4548C6D@cygnus.com>
X-SW-Source: 1999-q4/msg00244.html
Content-length: 3763
>I'd prefer the name (target_signal_p()) (Well actually I don't prefer
>that name but its more consistent with the general naming convetion :-).
>
>I'll check in a change to target.[ch] that adds the target_singal_p().
>Hmm, I might do it slightly differently - were getting too many separate
>places where there is code like:
>
> #if SIG...
> case TARGET_SIGNAL...
> #endif
>
>With that in, can the hppa-nat.c be re-submitted? BTW, you might also
>split it, I think it contains two changes - the code that uses this new
>function and something else.
Sure. Here is the part which makes use of target_signal_p (the
target.[ch] changes you are making).
Ignore the hpjyg15 patch, but use this (hpjyg15a), and the sequel I'm
cooking (hpjug15b).
ChangeLog:
1999-11-08 Jimmy Guo <guo@cup.hp.com>
* hppah-nat.c (require_notification_of_events): start by
ignoring all signals and then adding back in ones we're
interested in.
* infrun.c (handle_command): On HP, call
require_notification_of_events to ignore signals we don't
care.
Index: gdb/hppah-nat.c
/opt/gnu/bin/diff -r -c -N /view/guo.wdb.c//CLO/Components/WDB/Src/gnu/gdb/hppah-nat.c gdb/hppah-nat.c
*** /view/guo.wdb.c//CLO/Components/WDB/Src/gnu/gdb/hppah-nat.c Thu Nov 11 15:59:07 1999
--- gdb/hppah-nat.c Thu Nov 11 16:38:20 1999
***************
*** 698,703 ****
--- 698,705 ----
#if defined(PT_SET_EVENT_MASK)
int pt_status;
ptrace_event_t ptrace_events;
+ int nsigs;
+ int signum;
/* Instruct the kernel as to the set of events we wish to be
informed of. (This support does not exist before HPUX 10.0.
***************
*** 709,715 ****
the kernel to keep certain signals hidden from us, we do it
by calling sigdelset (ptrace_events.pe_signals, signal) for
each such signal here, before doing PT_SET_EVENT_MASK. */
! sigemptyset (&ptrace_events.pe_signals);
ptrace_events.pe_set_event = 0;
--- 711,740 ----
the kernel to keep certain signals hidden from us, we do it
by calling sigdelset (ptrace_events.pe_signals, signal) for
each such signal here, before doing PT_SET_EVENT_MASK. */
! /* RM: The above comment is no longer true. We start with ignoring
! * all signals, and then add the ones we are interested in. We could
! * do it the other way: start by looking at all signals and then
! * deleting the ones that we aren't interested in, except that
! * multiple gdb signals may be mapped to the same host signal
! * (eg. TARGET_SIGNAL_IO and TARGET_SIGNAL_POLL both get mapped to
! * signal 22 on HPUX 10.20) We want to be notified if we are
! * interested in either signal.
! */
! sigfillset (&ptrace_events.pe_signals);
!
! /* RM: Let's not bother with signals we don't care about */
! nsigs = (int) TARGET_SIGNAL_LAST;
! for (signum = nsigs; signum > 0; signum--)
! {
! if ((signal_stop_state (signum)) ||
! (signal_print_state (signum)) ||
! (!signal_pass_state (signum)))
! {
! if (target_signal_p (signum))
! sigdelset (&ptrace_events.pe_signals,
! target_signal_to_host (signum));
! }
! }
ptrace_events.pe_set_event = 0;
Index: gdb/infrun.c
/opt/gnu/bin/diff -r -c -N /view/guo.wdb.c//CLO/Components/WDB/Src/gnu/gdb/infrun.c gdb/infrun.c
*** /view/guo.wdb.c//CLO/Components/WDB/Src/gnu/gdb/infrun.c Fri Nov 5 18:37:38 1999
--- gdb/infrun.c Fri Nov 5 18:38:41 1999
***************
*** 3621,3626 ****
--- 3621,3633 ----
}
}
+
+ #ifdef GDB_TARGET_IS_HPPA
+ /* RM: Use OS interface to ignore signals we don't care about */
+ if (target_has_execution)
+ require_notification_of_events (inferior_pid);
+ #endif
+
do_cleanups (old_chain);
}
next parent reply other threads:[~1999-11-11 16:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.10.9911111610120.6426-100000@hpcll168.cup.hp.com>
1999-11-11 16:46 ` Stan Shebs [this message]
1999-11-11 17:13 ` Kevin Buettner
[not found] <Pine.LNX.4.10.9912150951120.29808-100000@hpcll168.cup.hp.com>
1999-12-16 0:07 ` Jeffrey A Law
1999-12-16 0:32 ` 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=199911120046.QAA29304@andros.cygnus.com \
--to=shebs@cygnus.com \
--cc=ac131313@cygnus.com \
--cc=gdb-patches@sourceware.cygnus.com \
--cc=guo@cup.hp.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