bug-guix
[Top][All Lists]
Advanced

[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’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]