search for: bndldx

Displaying 4 results from an estimated 4 matches for "bndldx".

Did you mean: badidx
2013 Sep 10
3
[LLVMdev] Intel Memory Protection Extensions (and types question)
...; > http://download-software.intel.com/sites/default/files/319433-015.pdf(chapter 9) doesn't say anything like this. (Or does it?) > > See the BNDMOV instruction, which allows the bounds to be explicitly > loaded and stored to bounds registers. Contrast with BNDLDX / BNDSTX, > where the location is implicit. The BNDMOV instruction is also used for > stack spills of the bounds registers. This allows MPX to be used for range > checking in a similar way to the Thumb-2EE extensions. > Well, ok, you can treat this as a 192-bit fat pointer, but A...
2013 Sep 10
0
[LLVMdev] Intel Memory Protection Extensions (and types question)
...referring to? > http://download-software.intel.com/sites/default/files/319433-015.pdf (chapter 9) doesn't say anything like this. (Or does it?) See the BNDMOV instruction, which allows the bounds to be explicitly loaded and stored to bounds registers. Contrast with BNDLDX / BNDSTX, where the location is implicit. The BNDMOV instruction is also used for stack spills of the bounds registers. This allows MPX to be used for range checking in a similar way to the Thumb-2EE extensions. >> The pointer and metadata exist in separate registers, but single instr...
2013 Sep 10
0
[LLVMdev] Intel Memory Protection Extensions (and types question)
On 10 Sep 2013, at 12:13, Kostya Serebryany <kcc at google.com> wrote: > Well, ok, you can treat this as a 192-bit fat pointer, but AFAICT this is not the real intention of the MPX developers > since a fat pointer will break all ABIs, and MPX tries to preserve them. MPX is an implementation of the HardBound concept from UPenn, where this was a design goal (see also their 'low-fat
2013 Sep 10
2
[LLVMdev] Intel Memory Protection Extensions (and types question)
On Tue, Sep 10, 2013 at 1:19 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > On 10 Sep 2013, at 10:13, Kostya Serebryany <kcc at google.com> wrote: > > > How did you come with 320 bits? > > 320=64*4+64, which is the size of the metadata table entry plus pointer > size, > > > Sorry, that should have been 192. The specification allows the