-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gcc12, gcc13: always mangle __FILE__ into invalid store path #255192
Conversation
And examples like Before:
After:
|
This seems like a pretty safe change to me and will reduce closure size in (presumably) all sorts of places. My bash-foo is not up to speed, so I'll leave that to others. |
Even dedupe is still able to fail
Will try a response file instead. Converting to draft. |
a3fc014
to
20b60ba
Compare
An attempt to use response files populated in setup hooks has at least 3 problems:
|
Response files would not help shorter term either: https://trofi.github.io/posts/299-maximum-argument-count-on-linux-and-in-gcc.html It might be simpler to patch |
20b60ba
to
ad1c188
Compare
Filed https://gcc.gnu.org/PR111527 for longer term solution in The patches still are able to reduce |
it's not a problem, but for headers in `/nix/store` this causes `-dev` | ||
inputs to be retained in runtime closure. | ||
|
||
Typical examples are `nix` -> `nlonhamm_json` and `pipewire` -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo: nlohmann
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, good catch! Fixed typo in 3 places.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a fine solution and it probably won't hurt any users outside. FILE is mostly an indication anyway.
ad1c188
to
bea823c
Compare
As a longer-term workaround proposed limit increase in linux kernel as well: https://lkml.org/lkml/2023/9/24/381 |
maps = map; | ||
} | ||
|
||
+/* Forward declatration for a $NIX_STORE remap hack below. */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+/* Forward declatration for a $NIX_STORE remap hack below. */ | |
+/* Forward declaration for a $NIX_STORE remap hack below. */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated the patch. Thank you!
maps = map; | ||
} | ||
|
||
+/* Forward declatration for a $NIX_STORE remap hack below. */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+/* Forward declatration for a $NIX_STORE remap hack below. */ | |
+/* Forward declaration for a $NIX_STORE remap hack below. */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated the patch. Thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not have enough expertise in GCC to take responsibility. But the patch seems sane, the solution seems reasonable. I am in favor of this change.
Building |
@trofi Have you tried to submit this patch upstream? I am recalling how I never got around to that with the Binutils patch, and then it became hard to maintain and that patch was puled out (by you no less :P). I sorely miss that patch (now, because LLVM depends on libbfd for the LTO plugin, I always end up recompiling LLVM for new arches even though it is multitarget). I don't want you to lose this patch and miss it too. So I think the lesson is to submit upstream first. To be clear I am definitely not saying we should block doing this on them accepting the patch. Rather that there should at least be an email thread we can link in Nixpkgs, and have the upstreaming process be started. Perfectly fine if it a takes a while for it to resolve itself. |
Without the change `__FILE__` used in static inline functions in headers embed paths to header files into executable images. For local headers it's not a problem, but for headers in `/nix/store` this causes `-dev` inputs to be retained in runtime closure. Typical examples are `nix` -> `nlonhmann_json` and `pipewire` -> `lttng-ust.dev`. Ideally we would like to use `-fmacro-prefix-map=` feature of `gcc` as: -fmacro-prefix-map=/nix/store/$hash1-nlohmann-json-ver=/nix/store/eeee.eee-nlohmann-json-ver -fmacro-prefix-map=/nix/... In practice it quickly exhausts argument lengtth limit due to `gcc` deficiency: https://gcc.gnu.org/PR111527 Until it;s fixed let's hardcode header mangling if $NIX_STORE variable is present in the environment. Tested as: $ printf "# 0 \"/nix/store/01234567890123456789012345678901-pppppp-vvvvvvv\" \nconst char * f(void) { return __FILE__; }" | NIX_STORE=/nix/store ./gcc/xgcc -Bgcc -x c - -S -o - ... .string "/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-pppppp-vvvvvvv" ... Mangled successfully.
bea823c
to
5371767
Compare
binutils patch context: Heh, it's still there for outdated I agree downstream changes are a problem. I hoped
This patch is a bit hacky as it hardcodes If you think it's fine as is I can propose to send it upstream as well. I can also do it optional upstream with a compile-time "on" flag. Longer term I would prefer to be able to pass megabytes of options to |
Sent the problem statement with this proof-of-concept patch to |
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Build-wise it works
This broke |
-fmacro-prefix-map=/nix/store/$hash1-nlohmann-json-ver=/nix/store/eeee.eee-nlohmann-json-ver | ||
-fmacro-prefix-map=/nix/... | ||
|
||
In practice it quickly exhausts argument lengtth limit due to `gcc` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In practice it quickly exhausts argument lengtth limit due to `gcc` | |
In practice it quickly exhausts argument length limit due to `gcc` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch! Proposed the fix as #268923
In practice it quickly exhausts argument lengtth limit due to `gcc` | ||
deficiency: https://gcc.gnu.org/PR111527 | ||
|
||
Until it;s fixed let's hardcode header mangling if $NIX_STORE variable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Until it;s fixed let's hardcode header mangling if $NIX_STORE variable | |
Until it's fixed let's hardcode header mangling if $NIX_STORE variable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch! Proposed the fix as #268923
Good find! Proposed the fix as #268920 |
The 23.11 release of NixOS has caused GCC to mangle __FILE__ names withing the nix-store. See <NixOS/nixpkgs#255192>. This causes gcov to fail with file-not-found errors: (DEBUG) Running gcov: 'gcov /build/source/rsort.gcda --branch-counts --branch-probabilities --demangled-names --hash-filenames --object-directory /build/source' in '/build/source' (ERROR) GCOV produced the following errors processing /build/source/rsort.gcda: Cannot open source file /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.38-27-dev/include/bits/string_fortified.h To work around this issue we add the --relative-only flag to gcov instucting it to not consider files with absoulte paths, thus excluding header files in the nix-store. Note: these files were already filtered out by gcovr, so the resulting documentation hasn't really changed.
Before the change macros like assert() embedded paths to source file into an executable binary. Examples are nlohmann_json embedding into nix:
Sometimes these dependencies are not too large: nlohmann_json is "just" 1MB of headers code.
But sometimes the
-dev
outputs contain python scripts and other build-only dependencies. The example islttng-ust
.Description of changes
Things done
sandbox = true
set innix.conf
? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)