jasonmolenda wrote:
In `ObjectFileMachO::GetAllArchSpecs()`, we call `ArchSpec::SetArchitecture()`,
```
base_arch.SetArchitecture(eArchTypeMachO, header.cputype, header.cpusubtype);
```
given a `mach_header`. This does
```
890 m_triple.setArchName(llvm::StringRef(core_def->name));
```
Then in llvm's `Triple::Triple()`,
```
1068 ObjectFormat = getDefaultFormat(*this);
```
And that's where the object file format is being set to ELF,
```
923 static Triple::ObjectFormatType getDefaultFormat(const Triple &T) {
-> 924 switch (T.getArch()) {
925 case Triple::UnknownArch:
926 case Triple::aarch64:
936 default:
937 return T.isOSDarwin() ? Triple::MachO : Triple::ELF;
```
The triple being passed in here is just "arm64" at this point, so the
T.isOSDarwin() fails, ObjectFile is set to ELF and it is never reset.
But I don't see why the ModuleArchSpec being set to ObjectFileELF (which I'd
never noticed before, ever) was not showing up in the triples, but -macho is,
when it's set in ObjectFileMachO. Maybe it's an ordering thing, where now that
the object file is being set in `ObjectFileMachO::GetAllArchSpecs` it is
constructing a triple string based on that, and it enters the picture.
It seems like it would be better to set the ObjectFile format in
`ArchSpec::SetArchitecture` when we know we're building a triple for a mach-o
file, to fix the erroneous ObjectFileELF setting from llvm when we only gave it
a cpu name. but let me look a little more.
https://github.com/llvm/llvm-project/pull/142704
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
