Fwd: FW: [PATCH V5 1/2] Initialize bnd register before performing inferior calls.

Fwd: FW: [PATCH V5 1/2] Initialize bnd register before performing inferior calls.

[Walfred Tedeschi]

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

> BND registers should be initialized before performing an inferior call
> to avoid undesired bound violations.

What are the undesired bound violations?  Do have an example?

Resetting BND registers in the inferior call isn't right to me, the BND 
setting isn't in effect in the inferior call.  If the function can 
trigger bound violations, it is expected that it still can trigger 
violations in the inferior call.

--
yao (齐尧)

Yao,

Thanks a lot for your quick review! :)

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.

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

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

In any case the user can still set the values and examine a bound 
violation and the its causes by setting the BND registers by stopping at 
the prologue of the function being called.

Have i answered your question?

Best regards,
-Fred

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: Fwd: FW: [PATCH V5 1/2] Initialize bnd register before performing inferior calls.

[Yao Qi]

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 (齐尧)