Skip to content
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

getauxv bloat in static exe #21522

Open
michaelortmann opened this issue Sep 26, 2024 · 2 comments · May be fixed by #22276
Open

getauxv bloat in static exe #21522

michaelortmann opened this issue Sep 26, 2024 · 2 comments · May be fixed by #22276
Labels
bug Observed behavior contradicts documented or intended behavior os-linux standard library This issue involves writing Zig code for the standard library.

Comments

@michaelortmann
Copy link
Contributor

Zig Version

zig-0.14.0-dev.1646+b19d0fb0f

Steps to Reproduce and Observed Behavior

The following bugreport got lost in a comment of/after merged PR #16977

#16977 (comment)

This bug also contributes to #20711

Expected Behavior

If getauxval() code is not used and unreachable in the final exe, it should not end up there.

@michaelortmann michaelortmann added the bug Observed behavior contradicts documented or intended behavior label Sep 26, 2024
@rohlem
Copy link
Contributor

rohlem commented Sep 26, 2024

Wanted to mention that #20517 seems to have restricted it
from any build to only executables (and modules with root exposing main).

Is the suggestion to further restrict it to only @export it when building non-static (i.e. dynamic) artifacts?

I also think we could try moving the relevant comptime block into the container namespace used to define getauxval.
As far as I understand, that should make it analyzed exactly when the definition of getauxval that relies on it is analyzed.
(I think this would make some of the surrounding if condition unnecessary as well.)

@michaelortmann
Copy link
Contributor Author

While i was not able to push it into the container definition, tt looks like the definition of getauxval in

}.getauxval else getauxvalImpl;
depends on the export before
@export(&getauxvalImpl, .{ .name = "getauxval", .linkage = .weak });
, which makes it complex.

But if we add the builtin.link_mode == .dynamic to

if (extern_getauxval and (builtin.output_mode == .Exe or @hasDecl(root, "main"))) {
and reverse the logic in
pub const getauxval = if (extern_getauxval) struct {
to if (!extern_getauxval) it could fix all cases.

At least it fixes the case of a static executable (and my little hello world test executable, when stripped, went down from 2280 to 2176 bytes). I commited a patch but didnt create a PR yet due to limited test / fear of regression elsewhere:

michaelortmann@59d0c85

@alexrp alexrp added os-linux standard library This issue involves writing Zig code for the standard library. labels Oct 9, 2024
@wooster0 wooster0 linked a pull request Dec 20, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Observed behavior contradicts documented or intended behavior os-linux standard library This issue involves writing Zig code for the standard library.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants