-
Notifications
You must be signed in to change notification settings - Fork 15k
[Clang][LLVM] Support for Fuchsia on ARM #163848
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -290,6 +290,8 @@ void arm::setArchNameInTriple(const Driver &D, const ArgList &Args, | |
| // Thumb2 is the default for V7 on Darwin. | ||
| (llvm::ARM::parseArchVersion(Suffix) == 7 && | ||
| Triple.isOSBinFormatMachO()) || | ||
| // Thumb2 is the default for Fuchsia. | ||
| Triple.isOSFuchsia() || | ||
| // FIXME: this is invalid for WindowsCE | ||
| Triple.isOSWindows(); | ||
|
|
||
|
|
@@ -452,6 +454,9 @@ arm::FloatABI arm::getDefaultFloatABI(const llvm::Triple &Triple) { | |
| case llvm::Triple::OpenBSD: | ||
| return FloatABI::SoftFP; | ||
|
|
||
| case llvm::Triple::Fuchsia: | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm wondering about this. It seems like it shouldn't be needed because the default case should already derive it correctly from But that's because I'm assuming that it should be Then there's We can probably iterate to get all these corners right. But we'll probably need to actually investigate each use proactively and get the knobs right for the Fuchsia context rather than only tweak things as problems arise. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For Fuchsia, on other architectures we don't specify any environment and I felt that requiring environment only for ARM (i.e. using There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh, I didn't realize that this "environment" was tied to the normalized triple text itself. I agree, we want the maximal triple to be something like |
||
| return FloatABI::Hard; | ||
|
|
||
| default: | ||
| if (Triple.isOHOSFamily()) | ||
| return FloatABI::Soft; | ||
|
|
||
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 haven't actually been able to discern how
aapcs-linuxactually differs fromaapcsoraapcs-vfp.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.
The resources I found when researching this is https://wiki.debian.org/ArmEabiPort and https://kanj.github.io/elfs/book/armMusl/cross-tools/abi.html and according to those the only difference is
enumsize:aapcsdefinesenums to be a variable sized type, while withaapcs-linuxthey are always ints (4 bytes).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.
Ah right, that is the default for
-fshort-enumIOW. I don't know why Linux long ago diverged from the clearly-published AAPCS on this, but for us matching Linux ABIs for this sort of detail (things likely relevant to porting code from arm-linux distinct from direct OS dependencies) is more important than published standards or CPU vendor's recommendations. It would be nice if the code made it easier to discover thataapcs-linuxmeansaapcs+-fshort-enum.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.
It's especially notable if not only the glibc-based Linux configurations, but musl, android, etc. are also still doing
-fshort-enum/aapcs-linuxthen there is no question that Fuchsia wants to follow them all. If e.g. Android differed from-gnueabihfon this then we might consider whether to align with one or the other.