[arch-dev-public] CFLAGS
We have a couple of bugs open about our CFLAGS. 1) https://bugs.archlinux.org/task/44361 -Remove the no-op --param=ssp-buffer-size=4 switch from CFLAGS Since we moved from -fstack-protector to -fstack-protector-strong, this paramater is unused and can be removed. 2) https://bugs.archlinux.org/task/44362 - Add -fstack-check Read more about this here: https://gcc.gnu.org/onlinedocs/gccint/Stack-Checking.html This is essentially a no-op for most code, so should have no real performance hit. I can not find any benchmarks to demonstrate that though. This would mean: CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fstack-check" Opinions? Allan
On Mon, Jul 27, 2015 at 6:15 AM, Allan McRae <allan@archlinux.org> wrote:
We have a couple of bugs open about our CFLAGS.
1) https://bugs.archlinux.org/task/44361 -Remove the no-op --param=ssp-buffer-size=4 switch from CFLAGS Since we moved from -fstack-protector to -fstack-protector-strong, this paramater is unused and can be removed.
2) https://bugs.archlinux.org/task/44362 - Add -fstack-check Read more about this here: https://gcc.gnu.org/onlinedocs/gccint/Stack-Checking.html This is essentially a no-op for most code, so should have no real performance hit. I can not find any benchmarks to demonstrate that though.
This would mean: CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fstack-check"
Opinions?
Seems sound given our focus on IA32 (don't know about other architectures). +1 from me.
On 27/07, Jan Alexander Steffens wrote:
On Mon, Jul 27, 2015 at 6:15 AM, Allan McRae <allan@archlinux.org> wrote:
We have a couple of bugs open about our CFLAGS.
1) https://bugs.archlinux.org/task/44361 -Remove the no-op --param=ssp-buffer-size=4 switch from CFLAGS Since we moved from -fstack-protector to -fstack-protector-strong, this paramater is unused and can be removed.
2) https://bugs.archlinux.org/task/44362 - Add -fstack-check Read more about this here: https://gcc.gnu.org/onlinedocs/gccint/Stack-Checking.html This is essentially a no-op for most code, so should have no real performance hit. I can not find any benchmarks to demonstrate that though.
This would mean: CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fstack-check"
Opinions?
Seems sound given our focus on IA32 (don't know about other architectures). +1 from me.
Our focus on IA32? -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/
-fstack-check works very well on x86 and x86_64 but is quite buggy on other architectures like ARM. I'm not quite sure if that was the point being made though.
On 28/07/15 05:42, Jan Alexander Steffens wrote:
On Mon, Jul 27, 2015 at 6:15 AM, Allan McRae <allan@archlinux.org> wrote:
We have a couple of bugs open about our CFLAGS.
1) https://bugs.archlinux.org/task/44361 -Remove the no-op --param=ssp-buffer-size=4 switch from CFLAGS Since we moved from -fstack-protector to -fstack-protector-strong, this paramater is unused and can be removed.
2) https://bugs.archlinux.org/task/44362 - Add -fstack-check Read more about this here: https://gcc.gnu.org/onlinedocs/gccint/Stack-Checking.html This is essentially a no-op for most code, so should have no real performance hit. I can not find any benchmarks to demonstrate that though.
This would mean: CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fstack-check"
Opinions?
Seems sound given our focus on IA32 (don't know about other architectures). +1 from me.
Any other comments before I rebuild pacman with these changes? Allan
participants (4)
-
Allan McRae
-
Daniel Micay
-
Jan Alexander Steffens
-
Johannes Löthberg