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/16/2017 03:36 PM, Tedeschi, Walfred wrote:
> FRED:
> So, stopped at 0x0000000000400a0b set BND0 and did a step instruction and printed BND0
> Commands were:
> P $bnd0={0xFFFFF..., 0}
> Si
> P $bnd0 (output was the same as input)
That seems expected.
>
> For the value I set I should have got an segv. But I did not.
>> Other way is to do instruction stepping till " bndmov %bnd3,-0x80(%rbp)"
>> and examine the memory at the indicated places.
>
> Memory? I thought you'd examine the registers? What indicated places, BTW?
>
> FRED:
> Yes, tring to discover what happened to the set I stepped instructions till 0x0000000000400a2f
> This tells me that the BND0 should be at 0x50(%rbp)
Ah, yes I see what you mean now. Well, actually it should be
at -0x50(%rbp) [negative]. Now I don't know whether that
was just a typo. :-P Otherwise something's very odd indeed.
> but value was not the one I added by hand but the automatically set (with the patch)
> Interestingly without the patch, and repeating the same procedure, the value is the one I have set by hand while stopped at the prolog.
Could your patch be clearing something that disables bnd-related
instructions completely? Perhaps %bndcfgu?
In your patch you have:
for (int i = 0; i < I387_BND0R_REGNUM (tdep); i++)
regcache_raw_write (regcache, I387_BND0R_REGNUM (tdep) + i, bnd_buf);
What does the "I387_BND0R_REGNUM (tdep)" in the for loop
condition mean?
That should have been "the number of bnd registers" I suppose, but
doesn't look like that's what the code is really doing, as
I387_BND0R_REGNUM is really the number of the _first_ bnd register,
AFAICS. Shouldn't that be I387_NUM_BND_REGS instead, like:
for (int i = 0; i < I387_NUM_BND_REGS; i++)
regcache_raw_write (regcache, I387_BND0R_REGNUM (tdep) + i, bnd_buf);
?
Thanks,
Pedro Alves