Fix invalid XNU binaries generated by apelink in some edge cases
#1106
Conversation
A shell will fail with a syntax error on an empty `if` or `else` body.
That is, neither of these is allowed:
# Empty `if`
if [ ... ]; then
fi
# Empty `else`
if [ ... ]; then
...
else
fi
There were two places where `apelink` could generate problematic `if`'s:
1. The XNU shell generation for aarch64 binaries when no loaders (either
binary or source) are provided. They can't assimilate, so the resulting
`else` body becomes empty.
There is actually a code path guarded by the `gotsome` variable that
inserts an extra `true` in this case, but the variable was never
initialized, so in practice this code path didn't activate in my
tests. This is fixed by initializing the variable.
2. The loader extraction code when no loaders are provided and XNU
support is requested. This is fixed by adding a simliar code path
that prevents an empty body from being generated.
The `-s` option changed its meaning, but the docs weren't updated.
|
Looks good!
I'm a little surprised there was no compiler warning of use of an uninitialized variable during static flow analysis... was that perhaps inadvertently turned off? |
That's a very good question. I just did some research, and I believe the static analysis is on, it's just that If I remove all lines that assign to |
|
Thanks for the research. That's good to know that |
|
@jart Would you be interested in merging this? I don't think creating pure aarch64 binaries is a very common use case, but the fixes themselves, I think, are relatively uncontroversial (especially the uninitialized variable fix). |
There was a problem hiding this comment.
Yes I am interested in merging this. Another outstanding change from you. Approved. Come hang out with us on Discord by the way, if you haven't joined already. https://discord.gg/FwAVVu7eJ4
I was experimenting with
aarch64-only APE binaries that don't contain any embedded loaders. You can generate one with:When I copied the resulting binary to an M1 machine and tried to run it, I got the following confusing error:
The details of what's going on and how this it was fixed are in the commit message. The generated binaries still don't work because apparently you can't assimilate on Apple Silicon, but the error message is clearer:
While I'm at it, also fix slightly outdated apelink documentation.