LWN: Comments on "Supporting Intel MPX in Linux"

Supporting Intel MPX in Linux

nix — Mon, 03 Mar 2014 15:28:38 +0000

Yours was the only implementation I can think of that allowed intermixing. :)

Supporting Intel MPX in Linux

rwmj — Thu, 27 Feb 2014 17:53:00 +0000

Not sure if one of the implementations you referred to was "Bounds Checking GCC" which I wrote a long long time ago, but anyway it allowed you to mix checked and unchecked code. That was, in fact, a pretty essential feature since it ran on SunOS and you couldn't recompile libc from source ... because you didn't have the source!

https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html

Supporting Intel MPX in Linux

etienne — Tue, 11 Feb 2014 17:00:03 +0000

So after removing the ia32 "bound" assembly instruction in the transition ia32->amd64 because it was useless (and became very slow), they re-invent it in amd64 with a new shiny name...

Supporting Intel MPX in Linux

nix — Thu, 30 Jan 2014 13:27:01 +0000

The function-call interface is changed so that when a pointer is passed to a function, the appropriate bounds are passed with it. Pointers returned from functions also carry bounds information.

Interestingly, they've thought of a way to do this while detecting non-MPXed-up ("legacy", heh) code and leaving its ABI unchanged. This was the biggest stumbling-block to using most past bounded-pointer implementations and tended to be why they never made any headway and generally got removed. (GCC and glibc have had, what, two bounded pointer implementations by now, each added with great effort, bitrotted over years, then finally removed?)

Supporting Intel MPX in Linux

Funcan — Thu, 30 Jan 2014 12:18:23 +0000

Is this information something that a tool like valgrind could hook into now? Valgrind is already extremely useful but if there is more/richer info that the compiler can emit then it can spot even more problem. Obviously this is mostly useful for debugging, but still useful.

Supporting Intel MPX in Linux

dlang — Thu, 30 Jan 2014 03:17:54 +0000

what's the performance impact of this going to be? it seems that just passing the pointerID along with the pointer value is going to cause enough data bloat to blow out caches and cause a very significant performance hit in many cases (even assuming that the CPU has a table large enough to hold every pointer in the system and the bounds and can check this without any overhead)