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

["Tedeschi, Walfred" <walfred.tedeschi@intel.com>]

On 02/13/2017 01:03 PM, Pedro Alves wrote:
> On 02/13/2017 08:33 AM, Tedeschi, Walfred wrote:
>
>> On 02/08/2017 01:27 PM, Pedro Alves wrote:
>>> For passing local pointers to some function, it might be
>>> that GDB could be able to figure out which bound registers
>>> contains the bound for a given variable, or if spilled, where
>>> to find then, and set up the call to use the right bounds, but
>>> I have no idea of how to retrieve that information.  I suspect
>>> that it's not a mapping we could retrieve from the dwarf?  And
>>> then there's also the case of passing pointers to global
>>> variables, and pointers to memory that gdb malloc's into the
>>> inferior, like for array/string coercion:
>> ABI defines which BND is used for which parameter and what to do when it
>> is needed to pass more bounds than BND registers available.
> Sure, but ABI only specifies calling convention, not
> whatever the compiler decides to do inside the function bodies,
> right?  Say:
>
> extern void bar (int *ptr);
>
> void foo (int *ptr)
> {
>    // lots of code code here.
>    [...]
>
>    // PTR now lives in memory, or in a different register
>    // The corresponding BND register could have been
>    // spilled/reused too.
>
>    // do "call bar (ptr)" from the debugger while stopped here.
>    // How would GDB determine where the correct corresponding
>    // BND value is?
> }
>
> I haven't studied the BND documention in detail, but I don't
> imagine how the information necessary to be able to answer the
> question in the comment above, in the general case, could be
> determined from ABI-awareness alone, and I don't believe it's
> something that could be retrieved from DWARF either.  But
> I'd gladly be shown wrong.
You are absolutely right! there is no way to know what goes on with the 
BND register within the code itself.
Internally we have discussed how to represent the bound information on 
DWARF, but for one reason or another we did not
arrive at the point to formalize it and bring it to the committee.
Basically idea was to add as a new DW_AT that would work as a location 
list for the bounds of any type that would point to a DW_TAG_POINTER_TYPE,
DW_TAG_REFERENCE_TYPE or DW_rvalue_reference_type.

We still intend to bring this proposal to the committee.
>> if we set afterwards: Inferior call + Break point + register set.
>> we should not need any additional set and show for the architecture.
>> Hover as you pointed out in the other e-mail it is better to increase
>> testing and document it.
> Agreed, that sounds like a reasonable way to handle that use case.
> I think mentioning it in the documentation would be good.
>
> Thanks,
> Pedro Alves
>
I am working on the tests right now!

Thanks again for your review and 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