This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH V7] amd64-mpx: initialize bnd register before performing inferior calls.
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.
> 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