From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#24703: Store references in 8-byte chunks in compiled code Date: Wed, 09 Nov 2016 21:40:05 +0100 Message-ID: <87oa1o75ga.fsf@gnu.org> References: <87mvi5lzqu.fsf@netris.org> <87inssncln.fsf@netris.org> <8737jwnb1c.fsf@netris.org> <87r37gstf6.fsf_-_@netris.org> <87d1j0sl1l.fsf@netris.org> <87a8e4glot.fsf@gnu.org> <8f2024ad-13c1-d4b1-1541-c2a5bddcb403@etorok.net> <87h98bdvng.fsf@gnu.org> <87k2d6qqee.fsf@netris.org> <20161024194022.GA1772@jasmine> <87insh1oxz.fsf@gnu.org> <87a8de7s6q.fsf@inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46172) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4ZgA-0005bM-54 for bug-guix@gnu.org; Wed, 09 Nov 2016 15:41:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c4Zg6-00076D-4Y for bug-guix@gnu.org; Wed, 09 Nov 2016 15:41:06 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:35878) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c4Zg6-000765-1K for bug-guix@gnu.org; Wed, 09 Nov 2016 15:41:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87a8de7s6q.fsf@inria.fr> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22\?\= \=\?utf-8\?Q\?'s\?\= message of "Sat, 05 Nov 2016 00:15:25 +0100") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Leo Famulari Cc: 24703@debbugs.gnu.org Hello! I read much more code than I wanted just to end up in gcc/builtins.c. In 8033772363b287ca529461e575ceb4a69d7af942 I added a patch for GCC 5.x and 6.x that disables the =E2=80=98movabs=E2=80=99 optimization for strcpy/= memcpy when the source is a string constant that contains =E2=80=9C/gnu/store=E2=80=9D = (I followed Mark=E2=80=99s advice to disable the optimization for any string that conta= ins =E2=80=9C/gnu/store=E2=80=9D, rather than just for strings that start with =E2=80=9C/gnu/store=E2=80=9D.) This can be tested by compiling a file like this one (comment or uncomment the lines that you want): --8<---------------cut here---------------start------------->8--- #include void foo (char *x, char *y) { /* memcpy(x, "this is a long string, a very long string", 42); */ /* strcpy(x, "STRCPY THIS IS A LONG STRING, A VERY LONG STRING"); */ strcpy(x, "STRCPY /gnu/store/THIS IS A LONG STRING, A VERY LONG STRING"); /* __builtin_strcpy(x, "THIS IS A LONG STRING, A VERY LONG STRING"); */ /* strcpy(y, "/gnu/store/THIS IS A LONG STRING, A VERY LONG STRING"); */ /* memcpy(y, "MEMCPY THIS IS A LONG STRING, A VERY LONG STRING", 30); */ memcpy(y, "MEMCPY /gnu/store/THIS IS A LONG STRING, A VERY LONG STRING", = 30); /* __builtin_memcpy(y, "/gnu/store/THIS IS A LONG STRING, A VERY LONG STR= ING", 30); */ } --8<---------------cut here---------------end--------------->8--- =E2=80=A6 and then running =E2=80=9Cobjdump -S foo.o | grep movabs=E2=80=9D= , for instance. Now we need a plan to actually fix the bug. The long-term goal is to rebuild everything with a compiler that has this patch, in the next =E2=80=98core-updates=E2=80=99. We might as well s= witch to GCC 5 as the default compiler. In the meantime, the only approach I can think of is to (1) ungraft more frequently than we=E2=80=99ve done so far, and (2) when we ungraft a packag= e, add gcc@5 as an input such that it gets rebuilt without the problem. Thoughts? Thanks, Ludo=E2=80=99.