From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9106 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: string word-at-a-time and atomic.h FAQ on twitter Date: Wed, 13 Jan 2016 18:30:50 +0100 Message-ID: <20160113173049.GF13558@port70.net> References: <20160105164640.GL23362@port70.net> <569569F9.5010608@openwall.com> <56956BA4.9050402@openwall.com> <20160112230738.GD13558@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="3V7upXqbjpZ4EhLz" X-Trace: ger.gmane.org 1452706270 21249 80.91.229.3 (13 Jan 2016 17:31:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Jan 2016 17:31:10 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9119-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 13 18:31:05 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aJPGD-0002p6-9U for gllmg-musl@m.gmane.org; Wed, 13 Jan 2016 18:31:05 +0100 Original-Received: (qmail 32420 invoked by uid 550); 13 Jan 2016 17:31:02 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 32402 invoked from network); 13 Jan 2016 17:31:01 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20160112230738.GD13558@port70.net> User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:9106 Archived-At: --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline * Szabolcs Nagy [2016-01-13 00:07:39 +0100]: > * Alexander Cherepanov [2016-01-13 00:09:56 +0300]: > > On 2016-01-13 00:02, Alexander Cherepanov wrote: > > >On 2016-01-05 19:46, Szabolcs Nagy wrote: > > >>i think compiler attributes should be used here on compilers that > > >>might break the code, but there is no attribute for this kind of > > >>oob access yet (although may_alias attribute is missing here too > > >>and should be added like in other string functions). > > > > > >Perhaps the noclone function attribute could be used in the meantime? > > > > > >https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-g_t_0040code_007bnoclone_007d-function-attribute-3205 > > > > Probably together with the noinline attribute... > > > > Another attribute which looks relevant is no_sanitize_address. > > > > https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-g_t_0040code_007bno_005fsanitize_005faddress_007d-function-attribute-3199 > > > > i think a no-lto attr should be used, maybe noinline > can achieve that. > i tried to do it with -fno-lto but it seems gcc-6 miscompiles musl with -flto anyway: lto incorrectly dead code eliminates _dlstart_c. (the libc entry point, _dlstart, is defined in toplevel inline asm in ldso/dlstart.c and it jumps to _dlstart_c) lto breaks symbol binding for environ, _environ, ___environ. (they should be weak, without that environ in a main binary has different address than in libc.so) libc.so built with -flto: $ readelf --dyn-syms -W libc.so |grep envi 22: 000000000028eb90 8 OBJECT GLOBAL DEFAULT 15 __environ 398: 000000000028eb90 8 OBJECT GLOBAL PROTECTED 15 ___environ 1034: 000000000028eb90 8 OBJECT GLOBAL PROTECTED 15 _environ 1107: 000000000028eb90 8 OBJECT GLOBAL DEFAULT 15 environ libc.so without -flto: $ readelf --dyn-syms -W libc.so |grep envi 22: 000000000028d2d8 8 OBJECT GLOBAL DEFAULT 15 __environ 398: 000000000028d2d8 8 OBJECT WEAK PROTECTED 15 ___environ 1034: 000000000028d2d8 8 OBJECT WEAK PROTECTED 15 _environ 1107: 000000000028d2d8 8 OBJECT WEAK DEFAULT 15 environ so i tried to -fno-lto to crt/*, dlstart.c and __environ.c and then libc seemed to build correctly, but during tests gcc lto1 ICE crashed. (i havent reported the bugs yet) given these issues i'm not convinced that lto build of libc is a good idea, but i attached a patch how the string issues might be worked around. --3V7upXqbjpZ4EhLz Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="lto.diff" diff --git a/Makefile b/Makefile index df20f94..3586697 100644 --- a/Makefile +++ b/Makefile @@ -113,6 +113,15 @@ NOSSP_SRCS = $(wildcard crt/*.c) \ src/ldso/dlstart.c src/ldso/dynlink.c $(NOSSP_SRCS:%.c=%.o) $(NOSSP_SRCS:%.c=%.lo): CFLAGS_ALL += $(CFLAGS_NOSSP) +# TODO: update the list when aliasing violations are fixed +NOLTO_SRCS = $(wildcard crt/*.c) \ + src/ldso/dlstart.c \ + src/string/stpcpy.c src/string/strlen.c \ + src/string/strchrnul.c src/string/memchr.c \ + src/string/memccpy.c str/string/strlcpy.c \ + src/string/strncpy.c +$(NOLTO_SRCS:%.c=%.o) $(NOLTO_SRCS:%.c=%.lo): CFLAGS_ALL += $(CFLAGS_NOLTO) + $(CRT_LIBS:lib/%=crt/%): CFLAGS_ALL += -DCRT # This incantation ensures that changes to any subarch asm files will diff --git a/configure b/configure index ee21771..4672ebb 100755 --- a/configure +++ b/configure @@ -113,6 +113,7 @@ CFLAGS_C99FSE= CFLAGS_AUTO= CFLAGS_MEMOPS= CFLAGS_NOSSP= +CFLAGS_NOLTO= CFLAGS_TRY= LDFLAGS_AUTO= LDFLAGS_TRY= @@ -344,6 +345,13 @@ tryflag CFLAGS_C99FSE -Wa,--noexecstack tryflag CFLAGS_NOSSP -fno-stack-protector # +# Check for options to disable LTO, which is needed for executable +# entry points and functions with aliasing violations. If not found, +# this is not an error; we assume the toolchain does not do LTO. +# +tryflag CFLAGS_NOLTO -fno-lto + +# # Check for options that may be needed to prevent the compiler from # generating self-referential versions of memcpy,, memmove, memcmp, # and memset. Really, we should add a check to determine if this @@ -660,6 +668,7 @@ CFLAGS_AUTO = $CFLAGS_AUTO CFLAGS_C99FSE = $CFLAGS_C99FSE CFLAGS_MEMOPS = $CFLAGS_MEMOPS CFLAGS_NOSSP = $CFLAGS_NOSSP +CFLAGS_NOLTO = $CFLAGS_NOLTO CPPFLAGS = $CPPFLAGS LDFLAGS = $LDFLAGS LDFLAGS_AUTO = $LDFLAGS_AUTO --3V7upXqbjpZ4EhLz--