Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Yao Qi <qiyaoltc@gmail.com>, Sergio Durigan Junior <sergiodj@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC] Support command "catch syscall" properly on different targets
Date: Tue, 03 Mar 2015 12:29:00 -0000	[thread overview]
Message-ID: <54F5A90E.8050704@redhat.com> (raw)
In-Reply-To: <86lhjei8md.fsf@gmail.com>

On 03/03/2015 12:11 PM, Yao Qi wrote:
> Sergio Durigan Junior <sergiodj@redhat.com> writes:
> 
>> You mean it's possible to use "catch syscall" on HP-UX targets?  I
>> wonder how it works.
> 
> Yes, that is what I meant, at least that is what I can tell from the
> source.

TARGET_WAITKIND_SYSCALL_ENTRY / TARGET_WAITKIND_SYSCALL_RETURN
was supported by the HP-UX target long before GNU/Linux gained
support.  See inf-ttrace.c.  However, I don't think "catch syscall"
itself ever did.  inf_ttrace_enable_syscall_events is only used
for watchpoints.  Not that I find we should go fix it, mind you.

In gdb 6.8, for example, we had:

      /* Be careful not to try to gather much state about a thread
         that's in a syscall.  It's frequently a losing proposition.  */
    case TARGET_WAITKIND_SYSCALL_ENTRY:
      if (debug_infrun)
        fprintf_unfiltered (gdb_stdlog, "infrun: TARGET_WAITKIND_SYSCALL_ENTRY\n");
      resume (0, TARGET_SIGNAL_0);
      prepare_to_wait (ecs);
      return;

      /* Before examining the threads further, step this thread to
         get it entirely out of the syscall.  (We get notice of the
         event when the thread is just on the verge of exiting a
         syscall.  Stepping one instruction seems to get it back
         into user code.)  */
    case TARGET_WAITKIND_SYSCALL_RETURN:
      if (debug_infrun)
        fprintf_unfiltered (gdb_stdlog, "infrun: TARGET_WAITKIND_SYSCALL_RETURN\n");
      target_resume (ecs->ptid, 1, TARGET_SIGNAL_0);
      prepare_to_wait (ecs);
      return;

I'd guess once this step after TARGET_WAITKIND_SYSCALL_RETURN
finishes, watchpoints end up processed.  Sounds like watchpoints
are broken on hpux then.  Not that anyone really cares though...

Thanks,
Pedro Alves


  reply	other threads:[~2015-03-03 12:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-27 14:23 Yao Qi
2015-02-27 18:49 ` Doug Evans
2015-03-03 11:56   ` Yao Qi
2015-03-03 12:14     ` Pedro Alves
2015-02-27 18:50 ` Pedro Alves
2015-03-03 12:06   ` Yao Qi
2015-03-03 12:38     ` Pedro Alves
2015-02-27 21:04 ` Sergio Durigan Junior
2015-03-03 12:11   ` Yao Qi
2015-03-03 12:29     ` Pedro Alves [this message]
2015-03-03 18:06       ` Sergio Durigan Junior
2015-03-03 18:18         ` Pedro Alves
2015-03-06 16:36         ` Yao Qi
2015-03-06 22:04           ` Sergio Durigan Junior
2015-03-09 14:29             ` Yao Qi
2015-03-10  4:53               ` Sergio Durigan Junior
2015-03-09 14:10         ` Yao Qi

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=54F5A90E.8050704@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=qiyaoltc@gmail.com \
    --cc=sergiodj@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