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

The patch to fix this bug was committed in ‘core-updates’ in 8033772363b287ca529461e575ceb4a69d7af942, which has now been merged. Ludo’.

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

l...@gnu.org (Ludovic Courtès) skribis: > 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 gcc@5 as an input such that it gets rebuilt without the problem. As an example, I did that in commit

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

Leo Famulari skribis: > On Wed, Nov 09, 2016 at 09:40:05PM +0100, Ludovic Courtès wrote: [...] >> 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. >>

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

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

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

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

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

Leo Famulari skribis: > On Sat, Nov 05, 2016 at 12:15:25AM +0100, Ludovic Courtès wrote: [...] >> Instead, the knobs we have are (1) global flag to enable/disable each >> built-in function (like -fno-builtin-… does), and (2) an x86-specific >> knob to determine whether to

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

On Sat, Nov 05, 2016 at 12:15:25AM +0100, Ludovic Courtès wrote: > I’ve fiddled a bit with GCC and read some code. No success yet, but > here’s a status update. Thanks for writing this out! > Instead, the knobs we have are (1) global flag to enable/disable each > built-in function (like

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

I’ve fiddled a bit with GCC and read some code. No success yet, but here’s a status update. AIUI, ‘strcpy’ declarations are immediately (in the front-end) recognized as “built-ins” as they are read (IOW, there’s no explicit conversion from function call to built-in call.) ‘__builtin_strcpy’

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

Hi Mark, Mark H Weaver skribis: > l...@gnu.org (Ludovic Courtès) writes: [...] >>> So, if our approach is to use -fno-builtin-strcpy, then we will have to >>> apply it system-wide, and rebuild all of 'core-updates' from scratch. >> >> Another approach would be to patch GCC,

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

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> Unfortunately, it is too widespread. As I just pointed out in >> >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24712#13 >> >> Among the many packages that include these obfuscated store references, >> one

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

Leo Famulari skribis: > On Mon, Oct 17, 2016 at 11:36:57PM -0400, Mark H Weaver wrote: >> I've been investigating another approach: to enhance our scanner and >> grafter to handle these 8-byte-chunked references. I believe it is >> feasible, but only if we abandon the

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

On Mon, Oct 17, 2016 at 11:36:57PM -0400, Mark H Weaver wrote: > I've been investigating another approach: to enhance our scanner and > grafter to handle these 8-byte-chunked references. I believe it is > feasible, but only if we abandon the ability to change the file names of > grafts outside of

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

On 2016-10-17 12:42, Mark H Weaver wrote: > > Here's how to recover, for now: > > guix build --no-grafts -e '(@@ (gnu packages fontutils) fontconfig/fixed)' Thanks! On 2016-10-17 15:09, Ludovic Courtès wrote: > Török Edwin skribis: > >> On 2016-10-16 22:04,

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

Mark H Weaver skribis: > l...@gnu.org (Ludovic Courtès) writes: [...] >> We could use a self symlink, or we could use something like >> . >> >> Mark, WDYT? >> >> What remains to be

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

l...@gnu.org (Ludovic Courtès) writes: > Török Edwin skribis: > >> On 2016-10-16 22:04, Ludovic Courtès wrote: >>> Mark H Weaver skribis: >>> When grafting, how will we achieve confidence that we've found the correct occurrence of the last

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

Török Edwin skribis: > On 2016-10-16 22:04, Ludovic Courtès wrote: >> Mark H Weaver skribis: >> >>> When grafting, how will we achieve confidence that we've found the >>> correct occurrence of the last character? I think we will have to give >>> up

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

Török Edwin writes: > On 2016-10-16 22:04, Ludovic Courtès wrote: >> Mark H Weaver skribis: >> >>> When grafting, how will we achieve confidence that we've found the >>> correct occurrence of the last character? I think we will have to give >>> up

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

On 2016-10-16 22:04, Ludovic Courtès wrote: > Mark H Weaver skribis: > >> When grafting, how will we achieve confidence that we've found the >> correct occurrence of the last character? I think we will have to give >> up our recently added feature of being able to change the

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

Mark H Weaver skribis: > When grafting, how will we achieve confidence that we've found the > correct occurrence of the last character? I think we will have to give > up our recently added feature of being able to change the version number > of grafts. Wait, don’t jump to the

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

Here's what happens with a variant of 'unixodbc' with one character removed from its name, to make an odd number of characters. The last character 'c' is all by itself. The chunks of the reference /gnu/store/il1bn7n0l4yj3idrii23fhvzg4nn939i-unxodbc-2.3.4/etc are found in the following order:

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

Here's a complex example of a reference to: /gnu/store/80m11l8km7bwi9iljfyr82hmscaq4xk2-unixodbc-2.3.4/etc This also illustrates what can happen near the end of a reference. In this case, the last two characters are found at the end, within a 'mov' instruction, and the previous 4 characters

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

The 8-byte chunks may appear out of order. For example, in 'bash-static' we have this reference to: /gnu/store/7z3hpynjsbidxkq78xi5qi6lbcm8ndhp-glibc-intermediate-2.23 where the chunks are found in the following order: 1_/gnu/sto 2_ynjsbidx 3_re/7z3hp

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

Mark H Weaver writes: > Mark H Weaver writes: > >> Mark H Weaver writes: >> >>> It turns out there's an obfuscated self-reference to fontconfig's store >>> directory. Here's an excerpt of the output of "hexdump -C >>> libfontconfig.so.1.9.0":