guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#30111] [PATCH] gnu: address@hidden: Use retpoline options when buil


From: Ludovic Courtès
Subject: [bug#30111] [PATCH] gnu: address@hidden: Use retpoline options when building itself.
Date: Tue, 27 Feb 2018 10:37:10 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Hi Alex,

Sorry for the delay.

Alex Vong <address@hidden> skribis:

> This patch makes gcc use retpoline options when building itself. My last
> attempt to build it was successful. But after that I have changed
> something, I hope it wouldn't make it fail to build. (It shouldn't,
> since the options passed aren't changed.)

Any idea what upstream thinks of compiling GCC itself with these
options?  Do they offer a configure flag or something to help with that?

> Are we going to add these options to other natively compiled programs as
> well?

I don’t have a good answer.  Clearly we’ll want that in key packages,
but then where do we draw the line, and also how do we make sure we
don’t repeat ourselves?

Thoughts?

>>From f6b9caae6e13936be65550c871208a3425fe4ce4 Mon Sep 17 00:00:00 2001
> From: Alex Vong <address@hidden>
> Date: Thu, 25 Jan 2018 23:24:24 +0800
> Subject: [PATCH] gnu: address@hidden: Use retpoline options when building 
> itself.
>
> * gnu/packages/gcc.scm (address@hidden)[arguments]: Add retpoline options
> to #:make-flags.

[...]

> +    (arguments
> +     (substitute-keyword-arguments `(#:modules ((guix build gnu-build-system)
> +                                                (guix build utils)
> +                                                (ice-9 regex)
> +                                                (srfi srfi-1)
> +                                                (srfi srfi-26))
> +                                     ,@(package-arguments gcc-6))
> +       ;; Use retpoline options when building itself.
> +       ((#:make-flags flags)
> +        `(let* ((cross-compiling? ,(%current-target-system))
> +                (system (if cross-compiling?
> +                            ,(%current-target-system)
> +                            ,(%current-system)))
> +                (retpoline-opts '("-mindirect-branch=thunk"
> +                                  "-mfunction-return=thunk"
> +                                  "-mindirect-branch-register"))
> +                (append-flag
> +                 (lambda (flag)
> +                   (if (string-match 
> "^((BOOT_)?CFLAGS|C(XX)?FLAGS_FOR_TARGET)="
> +                                     flag)
> +                       (string-join (cons flag retpoline-opts))
> +                       flag)))
> +                (add-flag
> +                 (lambda (prefix flags)
> +                   (if (any (cut string-prefix? prefix <>) flags)
> +                       flags
> +                       (cons (string-append prefix
> +                                            (string-join retpoline-opts))
> +                             flags))))
> +                (add-gcc-flag (cut add-flag
> +                                (if cross-compiling? "CFLAGS=" 
> "BOOT_CFLAGS=")
> +                                <>))
> +                (add-c-lib-flag (cut add-flag "CFLAGS_FOR_TARGET=" <>))
> +                (add-c++-lib-flag (cut add-flag "CXXFLAGS_FOR_TARGET=" <>)))
> +           ;; Right now, the retpoline options are x86-specific.
> +           (if (any (cut string-prefix? <> system) '("x86_64" "i686"))
> +               (add-gcc-flag (add-c-lib-flag (add-c++-lib-flag (map 
> append-flag
> +                                                                    
> ,flags))))
> +               ,flags)))))

I’m a bit concerned by the apparent complexity and the extra maintenance
burden it may entail.  I don’t have any concrete suggestions though.  I
suppose we should somehow abstract GCC compilation to make it easier to
pass new flags?

Thanks,
Ludo’.





reply via email to

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