Theo, Stuart, +++++
On Mon, 20 Feb 2017, Theo de Raadt wrote:
It replaces optimised(?) .S versions of memcpy with the shared C
code that contains the test & syslog_r & abort.
There's got to be a performance cost, not using the .S versions.
What is the average size of the copy please?
Years ago, I did a whole lot of tests with this. I was so disappointed
with memcpy that I NEVER use memcpy these days, only 'memmove'. I grew
up with 'bcopy' so I tend to think in terms of safe overlapped copies.
Yet here we are about a year later, still finding benieft from this
mechanism which finds an obscure bug at runtime.
Maybe we need to write the crashing code into each of the .S versions.
Unless you are trying to identify/block copying of overlapping data, and
correct me if I am wrong, but depending on the overlap, cannot you just
copy forwards or backwards to avoid over-writing data you are trying to
copy.
Does some of todays hardware have problems with cache optimization if you
are walking backwards through the cache?
Or is the whole point to avoid overlapping copies in the first place?
Regards - Damian
Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer
