Bringing parity with aarch64-android https://github.com/google/android-riscv64/issues/9#issuecomment-1535454205
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/Driver/ToolChains/Clang.cpp | ||
---|---|---|
423 | should this... | |
450 | (ah, this is why you need Android early. but, yeah, probably worth moving all the Android stuff together, like with the other OSes?) | |
470 | ...be down here instead? | |
475–476 | (take care of all this android/arm stuff where you take care of android/riscv64? arm64 has frame pointers by "default default", so we don't need to mention it?) |
clang/lib/Driver/ToolChains/Clang.cpp | ||
---|---|---|
424 | seems like we don't even have a test for aarch64.*android target. I'll add a testcase. |
clang/lib/Driver/ToolChains/Clang.cpp | ||
---|---|---|
530 | You can use Triple.isRISCV64() |
(lgtm with craig.topper's suggested simplification.)
clang/lib/Driver/ToolChains/Clang.cpp | ||
---|---|---|
530 | lol. i could seem so much smarter if only i'd learn to read :-) |
clang/lib/Driver/ToolChains/Clang.cpp | ||
---|---|---|
530 | && has a lower precedence than ==. == doesn't need parens. | |
clang/test/Driver/frame-pointer-elim.c | ||
109 | Use --target= for new tests. -target has been deprecated since clang 3.x, albeit without a warning. | |
clang/test/Driver/frame-pointer.c | ||
61 | I don't think we need so many RUN lines. -O0 and -O1 suffice. |
Is there more context on why Android enables the frame pointer?
From what i gathered, this is more of an effort to have parity such that existing build flag overrides continue to be consistent.
well, when i said that on the internal chat, i thought you were asking "why do we say what clang already says?" :-)
if the question was actually "is there more context on why Android enables the frame pointer?" i'd have said something like "because Android developers [OS and app developers alike] do so much debugging from the field, where all we get is a crash report for something we probably can't repro locally, that having good _and_ cheap unwinds is super important to us".
Thanks. I suspected that was the answer, but I wanted to check that it made sense to copy AArch64.
Enabling the frame pointer is fine. We probably should revert ancient conventions by using -fasynchronous-unwind-tables...
should this...