bug#24703: Store references in 8-byte chunks in compiled code

[Leo Famulari]

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.