This patch adds an XCOFF triple object format type into LLVM. This XCOFF triple object file type will be used later by object file and assembly generation for the AIX platform.
Details
- Reviewers
hubert.reinterpretcast sfertile chandlerc apaprocki JDevlieghere davide - Commits
- rGa03ae73c2932: Add XCOFF triple object format type for AIX
rLLDB355989: Add XCOFF triple object format type for AIX
rC355989: Add XCOFF triple object format type for AIX
rL355989: Add XCOFF triple object format type for AIX
Diff Detail
- Repository
- rL LLVM
Event Timeline
llvm/lib/Support/Triple.cpp | ||
---|---|---|
537 ↗ | (On Diff #189211) | If the conclusion is that checking XCOFF before COFF is fine, then we should remove the FIXME and just leave a normal comment. |
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp | ||
---|---|---|
2079 ↗ | (On Diff #189211) | No need to be sorry: :) This should probably just say error: XCOFF is unimplemented to be more direct in case anything is expecting "error:" in the output. |
llvm/lib/Support/Triple.cpp | ||
537 ↗ | (On Diff #189211) | Agreed, existing code seems fine as long as there is a comment explaining that xcoff must come before coff in case it isn't obvious at a quick glance. |
clang/lib/CodeGen/BackendUtil.cpp | ||
---|---|---|
1470 ↗ | (On Diff #189211) | This is confusing, you say fall through but you break? I would prefer a llvm_unreachable("XCOFF not yet implemented"); here and elsewhere in this patch. |
1486 ↗ | (On Diff #189211) | See previous comment. |
clang/lib/CodeGen/CodeGenModule.cpp | ||
4410 ↗ | (On Diff #189211) | See previous comment. |
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp | ||
2079 ↗ | (On Diff #189211) | Just bundle this with the WASM case, the error message is correct for both. |
llvm/lib/MC/MCContext.cpp | ||
165 ↗ | (On Diff #189211) | See previous comment. |
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp | ||
---|---|---|
2079 ↗ | (On Diff #189211) | I think they are different. |
llvm/lib/MC/MCContext.cpp | ||
---|---|---|
165 ↗ | (On Diff #189211) | It is certain that we will need MCSymbolXCOFF. But before we run into cases where we actually need a MCSymbolXCOFF, we could use the generic MCSymbol first for XCOFF platform. So I don't want to put a llvm_unreachable here. |
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp | ||
---|---|---|
2079 ↗ | (On Diff #189211) | I don't think the error message suggests that at all, and it's definitely not true. At this point neither XCOFF nor WASM is supported, and that's exactly what the log message says. |
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp | ||
---|---|---|
2079 ↗ | (On Diff #189211) | I agree that the error message for WASM does not indicate that the lack of support is inherent or intended to be permanent; however, it is not indicative either of an intent to implement the support. I am not sure what the intent is for WASM, but I do know that the intent for XCOFF is to eventually implement the support. I do not see how using an ambiguous message in this commit (when we know what the intent is) is superior to the alternative of having an unambiguous message. |
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp | ||
---|---|---|
2079 ↗ | (On Diff #189211) | I think we should keep this consistent with the other target so my vote is for grouping XCOFF with WASM. After all, if it's going to be implemented soon, the message will go away :) |
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp | ||
---|---|---|
2079 ↗ | (On Diff #189211) | Well, I don't know about "soon"... |
llvm/lib/MC/MCContext.cpp | ||
---|---|---|
165 ↗ | (On Diff #189211) | Would it make sense to add an llvm_unreachable now, and the first patch that actually uses an MCSymbol stubs out the class and removes the unreachable? |
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp | ||
---|---|---|
2079 ↗ | (On Diff #189211) | Okay. Shared message it is. |
llvm/lib/MC/MCContext.cpp | ||
165 ↗ | (On Diff #189211) | The first patch that uses MCSymbol do not necessarily need to stub out MCSymbolXCOFF, as MCSymbol seems to be generic and usable until we are doing some XCOFF specific things that needs to be represented by MCSymbolXCOFF. If the intention is MCSymbol should never get used, and different object file should have their own MCSymbolXXX class from the start, then I could add in the llvm_unreachable here, and I would also propose to replace the "return new (Name, *this) MCSymbol(MCSymbol::SymbolKindUnset, Name, IsTemporary);" with an llvm_unreachable as well. |
LGTM.
llvm/lib/MC/MCContext.cpp | ||
---|---|---|
165 ↗ | (On Diff #189211) | Ok I think falling through to create the generic MCSymbol in this patch is reasonable. |
llvm/lib/MC/MCObjectFileInfo.cpp | ||
---|---|---|
806 ↗ | (On Diff #189713) | This line is over 80 characters. |