Re: [PATCH V7] amd64-mpx: initialize bnd register before performing inferior calls.

[Pedro Alves <palves@redhat.com>]

On 02/15/2017 01:01 PM, Tedeschi, Walfred wrote:

> Pedro wrote:
>> In reality it did not work as expected. When an inferior call is done 
>> and there is a breakpoint in the executed GDB issues a message like:
>>
>> "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."
> 
> This looks normal.  What were you expecting instead?
> 
> --
> Fred: 
> Message per se is fine. I was expecting that the inferior call should run isolated, exemplifying:
> 
> 1. Inferior is stopped.
> 2. inferior call is done.
> 3. breakpoint in inferior call is triggered.
> 4. continue is issued.
> 5. signal is presented to the user.
> 6. continue is issued again.
> 7. expected - control should be back to 1, i.e. on stop mode.
> 7. actual behavior - application finishes with the signal
> 8. actual behavior - after the breakpoint no result will be displayed to the user (about the inf call)

Just to be clear, I assume that between 3 and 4 there was
a 3.5 step:

  3.5. poke bnd registers manually, such that the infcall
       crashes with a bounds violation.

and that in step "5.", the signal you mention is a SIGSEGV
with bound violation info.

Correct?

I'm not seeing how an option to clear/not clear the bnd
registers changes anything for the parts you found unexpected.
All steps from 5. onward will be the same, won't they?

To not pass the SIGSEGV to the inferior, you can also
resume with "signal 0", or do "handle SIGSEGV nopass" before
the continue.

As for 8. being silent, that's something that I think would
be nice to change, though that's not specific to bnd at
all.

Thanks,
Pedro Alves

> In 6 if I use return instead I fall back to my expected behavior. In this sense, I think the user can work in that way.
> 
> I will continue a bit more testing now. I have got confused with an intermediate version 01/27/2017.
> It was not displaying the signal step (5), now it is on again. 
> --
> 
>> Also after that no signal generated within the function call is reported.
> 
> Please clarify.
> 
> Fred: I tried to summarize above, not sure I succeeded. 
> 
> Fred: Additional comment:
> Trying that now I am considering that this as a whole is more complicated than expected. 
> Too many actions to realize the simple thing that is set a register before an inferior call and perform the call.
> 
> I am inclined to give it a try in creating set/show for the feature and see how it behaves. 
> In fact I will do it and submit the V8 based on that let's see how it looks like.
> 
> Thanks a lot for the review!
> 
> Best regards,
> /Fred
> 
>> Not sure if this a limitation or a bug. In case you think it is a bug 
>> i can add some entries in Bugzilla.
> 
> Thanks,
> Pedro Alves