public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Yao Qi <qiyaoltc@gmail.com>
To: Walfred Tedeschi <walfred.tedeschi@intel.com>
Cc: qiyaoltc@gmail.com,  palves@redhat.com,
	 gdb-patches <gdb-patches@sourceware.org>,
	 brobecker@adacore.com
Subject: Re: Fwd: FW: [PATCH V5 1/2] Initialize bnd register before performing inferior calls.
Date: Wed, 27 Apr 2016 08:47:00 -0000	[thread overview]
Message-ID: <86h9enfnfn.fsf@gmail.com> (raw)
In-Reply-To: <571F7CC8.7070702@intel.com> (Walfred Tedeschi's message of "Tue,	26 Apr 2016 16:35:52 +0200")

Walfred Tedeschi <walfred.tedeschi@intel.com> writes:

[Could you reply to the mail rather than forward?]

> That is true, but not unattended.  In case BND registers are not set
> to init state the current context value will be used for the inferior
> call.
> Causing with a higher chance a BND violation.
>

If the BND violation is caused by GDB inferior call, GDB should take
care of the violation.  If the violation is caused by the function
itself we are doing inferior call, it is the right behavior.

Take the breakpoint for example, if I set a breakpoint in function foo,
and do the inferior call, the breakpoint is hit,

(gdb) b foo
Breakpoint 2 at 0x4004fa: file 2.c, line 11.
(gdb) p foo ()

Breakpoint 2, foo () at 2.c:11
11	  counter = 1;
The program being debugged stopped while in a function called from GDB.
Evaluation of the expression containing the function
(foo) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb) bt
#0  foo () at 2.c:11
#1  <function called from gdb>
#2  main (argc=1, argv=0x7fffffffdfc8) at 2.c:15

> The question is was that intended by the user? Likely not.
>

It has nothing to do with user's intention.  It is about the consistency
of GDB behavior.  If the execution of function foo triggers BND
violation, the inferior call to function foo (with the same context)
should trigger the BND violation as well.

> Also it will invalidate the inferior call usage.  The inferior call
> will finish before returning the result back to the user.

Looks the inferior call aborts when BND violation is triggered.  IMO,
GDB should stop and frame #0 is the place where BND violation is
triggered.

-- 
Yao (齐尧)

      reply	other threads:[~2016-04-27  8:47 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AC542571535E904D8E8ADAE745D60B19445B77C8@IRSMSX104.ger.corp.intel.com>
2016-04-26 14:36 ` Walfred Tedeschi
2016-04-27  8:47   ` Yao Qi [this message]

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=86h9enfnfn.fsf@gmail.com \
    --to=qiyaoltc@gmail.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=walfred.tedeschi@intel.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).