From: Randolph Chung <randolph@tausq.org>
To: gdb-patches@sources.redhat.com
Subject: [patch/rfa] Get rid of HP_OS_BUG
Date: Wed, 26 May 2004 06:11:00 -0000 [thread overview]
Message-ID: <20040526061133.GY7207@tausq.org> (raw)
In my continuing quest to hunt down all the hppa code scattered all
around arch-indep code, i found this....
HP_OS_BUG is actually not defined anywhere. Looking through the
changelogs, it looks like it used to be defined in m-hp9k320.h. I
believe this is a m68k HPUX machine that is no longer supported, so i
think we might as well get rid of it... unless someone tells me
otherwise i will check this in in a couple of days.
thanks,
randolph
2004-05-25 Randolph Chung <tausq@debian.org>
* infrun.c (trap_expected_after_continue): Remove HP_OS_BUG workaround.
(proceed, init_wait_for_inferior, handle_inferior_event): Likewise.
--- infrun.c.orig 2004-05-25 22:58:50.986405776 -0700
+++ infrun.c 2004-05-25 22:59:04.675324744 -0700
@@ -262,14 +262,6 @@ static int trap_expected;
static int stop_on_solib_events;
#endif
-#ifdef HP_OS_BUG
-/* Nonzero if the next time we try to continue the inferior, it will
- step one instruction and generate a spurious trace trap.
- This is used to compensate for a bug in HP-UX. */
-
-static int trap_expected_after_continue;
-#endif
-
/* Nonzero means expecting a trace trap
and should stop the inferior and return silently when it happens. */
@@ -768,18 +760,6 @@ proceed (CORE_ADDR addr, enum target_sig
if (prepare_to_proceed () && breakpoint_here_p (read_pc ()))
oneproc = 1;
-#ifdef HP_OS_BUG
- if (trap_expected_after_continue)
- {
- /* If (step == 0), a trap will be automatically generated after
- the first instruction is executed. Force step one
- instruction to clear this condition. This should not occur
- if step is nonzero, but it is harmless in that case. */
- oneproc = 1;
- trap_expected_after_continue = 0;
- }
-#endif /* HP_OS_BUG */
-
if (oneproc)
/* We will get a trace trap after one instruction.
Continue it automatically and insert breakpoints then. */
@@ -880,9 +860,6 @@ init_wait_for_inferior (void)
/* These are meaningless until the first time through wait_for_inferior. */
prev_pc = 0;
-#ifdef HP_OS_BUG
- trap_expected_after_continue = 0;
-#endif
breakpoints_inserted = 0;
breakpoint_init_inferior (inf_starting);
@@ -2019,9 +1996,6 @@ process_event_stop_test:
if (what.call_dummy)
{
stop_stack_dummy = 1;
-#ifdef HP_OS_BUG
- trap_expected_after_continue = 1;
-#endif
}
switch (what.main_action)
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
next reply other threads:[~2004-05-26 6:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-26 6:11 Randolph Chung [this message]
2004-05-26 17:30 ` Andrew Cagney
2004-05-26 12:59 Michael Elizabeth Chastain
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=20040526061133.GY7207@tausq.org \
--to=randolph@tausq.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