[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24703: Store references in 8-byte chunks in compiled code
From: |
Ludovic Courtès |
Subject: |
bug#24703: Store references in 8-byte chunks in compiled code |
Date: |
Wed, 09 Nov 2016 21:40:05 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
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 ‘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.
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?
Thanks,
Ludo’.