| |||||||||||||
The ups and downs of strlcpy()The ups and downs of strlcpy()Posted Jul 24, 2012 18:16 UTC (Tue) by renox (subscriber, #23785)In reply to: The ups and downs of strlcpy() by nix Parent article: The ups and downs of strlcpy()
> x86-64 GCC disables them by default (as does x86-32 modern GCC)
I wonder why the GCC developpers chose this default behaviour, x86-64 isn't register starved like x86-32.
(Log in to post comments)
The ups and downs of strlcpy() Posted Jul 24, 2012 23:19 UTC (Tue) by nix (subscriber, #2304) [Link]
Because the ABI allows it, because it still provides a performance improvement (somewhere between 1% and 5%, not insignificant, though well below the 8--12% I've seen reported for x86-32), and because it's useless -- everything from GDB through libgcj and now I find even glibc backtrace() uses the DWARF unwinder tables instead. Why maintain a 'feature' which costs a register and adds runtime overhead to every function call when nobody needs it?
The ups and downs of strlcpy() Posted Jul 25, 2012 15:11 UTC (Wed) by paulj (subscriber, #341) [Link]
One reason is debugging stack corruption, where normal tools may not give meaningful backtraces. With frame-pointers, you can easily figure out where earlier, uncorrupted, frames really are, and figuring out why it crashed.
The ups and downs of strlcpy() Posted Jul 25, 2012 17:17 UTC (Wed) by nix (subscriber, #2304) [Link]
Yep. That's why frame pointers should be *enableable*. It doesn't mean they should be on by default.
|
|||||||||||||