[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24703: Store references in 8-byte chunks in compiled code
From: |
Leo Famulari |
Subject: |
bug#24703: Store references in 8-byte chunks in compiled code |
Date: |
Wed, 9 Nov 2016 18:16:52 -0500 |
User-agent: |
Mutt/1.7.1 (2016-10-04) |
On Wed, Nov 09, 2016 at 09:40:05PM +0100, Ludovic Courtès wrote:
> 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 ‘movabs’ optimization for strcpy/memcpy when
> the source is a string constant that contains “/gnu/store” (I followed
> Mark’s advice to disable the optimization for any string that contains
> “/gnu/store”, rather than just for strings that start with
> “/gnu/store”.)
>
> 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 <string.h>
> 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
> STRING", 30); */
> }
> --8<---------------cut here---------------end--------------->8---
>
> … and then running “objdump -S foo.o | grep movabs”, for instance.
Awesome. Thank you!
> 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 ‘core-updates’. We might as well switch 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’ve done so far, and (2) when we ungraft a package,
> add address@hidden as an input such that it gets rebuilt without the problem.
>
> Thoughts?
Sounds good to me. I wonder, with our current build farm, how often can
we do the full rebuilds required by ungrafting? I don't yet have a sense
of how long it takes.