On Wed, Sep 09, 2015 at 02:48:22PM -0400, Zack Weinberg wrote: > On 09/09/2015 01:13 PM, Rich Felker wrote: > > On Wed, Sep 09, 2015 at 12:47:10PM -0400, Zack Weinberg wrote: > >> On Wed, Sep 9, 2015 at 12:42 PM, Rich Felker <dal...@libc.org> wrote: > >>> You're making this harder than it needs to be. The "m" constraint is > >>> the wrong thing to use here. Simply use: > >>> > >>> __asm__(""::"r"(ptr):"memory"); > >> > >> Please review my earlier conversation with Adhemerval on exactly this > >> point. > > > > My understanding is that you consider this a "big hammer". Does that > > really matter if the intent is that it only be used in isolated, > > sensitive contexts? Are you just unhappy with the performance cost, or > > concerned that the clobber will cause more spilling of sensitive data? > > Please review *all* of my earlier conversation with Adhemerval, in > particular the bit where I compiled libressl three different ways and > analyzed the assembly dumps. I'm sure there's more to be said on the > topic, but *starting* from there.
OK, sorry for jumping back in without the full context. > > the hack with the "m" constraint is wrong and easily fixed > > It's not wrong; it is in fact the documented way to express a fixed-size > read access to one block of memory. Look for "ten bytes of a string" > within https://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/Extended-Asm.html > (sorry, there don't appear to be anchors). > > It merely doesn't work in C++, with Clang, or (maybe) with a block of > memory whose size cannot be determined at compile time. It relies on structs containing VLAs which are not standard C nor supported by any "GNU C" compilers except GCC. And features like this tend to be really fragile even in GCC because nobody uses them (for good reason -- they can't be expected to work except on certain GCC versions). You can disagree if you like, but that's why I called it "wrong". Rich