On Feb 2, 2015, at 23:47, Gleb Kurtsou <g...@freebsd.org> wrote: > On (02/02/2015 17:06), Jeremie Le Hen wrote: >> Hi Gleb, >> On Sun, Feb 1, 2015 at 9:24 PM, Gleb Kurtsou <g...@freebsd.org> wrote: >>> I came across some build issues in libc.so and SSP. >>> >>> libc.ldscript (aka libc.so) unconditionally includes >>> @@LIBDIR@@/libssp_nonshared.a >>> >>> libssp* are not built if WITHOUT_SSP defined. >>> >>> ObsoleteFiles.inc doesn't mention libssp*. >>> >>> Consider WITHOUT_SSP=yes case. As soon as one does clean installworld >>> and/or removes stale libssp_nonshared.a ld fails to link anything >>> because of missing libssp_nonshared.a >> >> I think nowadays it would make sense to get it of WITHOUT_SSP >> altogether. This will turn this into a non-issue. > > Do you mean building libssp_nonshared unconditionally? It makes perfect > sense. The library is a single stub function. > > By building libssp* conditionally we may expect that -fstack-protector > complier option won't work. I wasn't able to reproduce this potential > problem. libc provides __stack_chk_fail and __stack_chk_guard. And I > failed to create a test case that would generate code using anything > like __memcpy_chk. > > Perhaps we should change MK_SSP to operate as documented (add > -fstack-protector to CFLAGS) and consider adding MK_SSP_SUPPORT option > for libraries. Although there is no reason to have MK_SSP_SUPPORT if > that would imply failure to run binaries or compile with > -fstack-protector.
Silly question: shouldn’t libc.ldscript be built, conditionally with libssp_nonshared.a? Doing that would be trivial… Are there any concerns with doing this?
signature.asc
Description: Message signed with OpenPGP using GPGMail
