jasonmolenda wrote: I don't want to go with this approach, I don't want to see `-macho` in a triple that we're creating for any of these modules; this is going to break things down the line with firmware environments, I'm sure of it. It's also ugly.
This is an undesired behavior from llvm's Triple, because we create a Triple in ArchSpec::SetArchitecture with only a cpu specified, and llvm's Triple `getDefaultFormat()` is called when constructing the Triple, and assumes that an OS is defined. If no OS is specified, it sets the object file format to Triple::ELF by default. This is clearly wrong, it should be UnknownObjectFormat. If we later call Triple::setObjectFormat to specify the correct object file format, Triple adds "-macho" to the triple unconditionally. My guess is that other parts of llvm depend on the object file format being set to Triple::ELF when there is an unspecified OS. I wouldn't be surprised to see regressions if `getDefaultFormat()` changed to return UnknownObjectFormat when no OS is specified, as it really should be. And then if they got "-elf" added to triple strings when they called Triple::setObjectFormat they would also not want that behavior. I don't think any of these approaches to fixing this in ObjectFileMachO / ArchSpec are the right approach. llvm's Triple needs to have a way to set the object file format *without* changing the triple string, it needs to not set the object file format when no OS is specified, or we need to live with a Triple having an incorrect ObjectFormat in lldb. https://github.com/llvm/llvm-project/pull/144177 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
