These are identified by misc-include-cleaner. I've filtered out those that break builds. Also, I'm staying away from llvm-config.h, config.h, and Compiler.h, which likely cause platform- or compiler-specific build failures.
Currently, `DIContext::getLineInfoForAddress` and `DIContext::getLineInfoForDataAddress` returns empty DILineInfo when the debug info is missing for the given address. This is not differentiable with the case when debug info is found for the given address but the debug info is default value (filename:linenum is <invalid>:0). This change wraps the return types of `DIContext::getLineInfoForAddress` and `DIContext::getLineInfoForDataAddress` with `std::optional`.
--macho -d uses the `parseInputMachO` code path, which does not handle -M. Add -M handling for --macho as well. Close #61019 Pull Request: https://github.com/llvm/llvm-project/pull/113795
In a mach_header, the cpusubtype is a 32-bit field, but it's split in 2 subfields: - the low 24 bits containing the cpu subtype proper, (e.g., CPU_SUBTYPE_ARM64E 2) - the high 8 bits containing a capability field used for additional feature flags. Notably, it's only the subtype subfield that participates in fat file slice discrimination: the caps are ignored. arm64e uses the caps subfield to encode a ptrauth ABI version: - 0x80 (CPU_SUBTYPE_PTRAUTH_ABI) denotes a versioned binary - 0x40 denotes a kernel-ABI binary - 0x00-0x0F holds the ptrauth ABI version This teaches the basic obj tools to decode that (or ignore it when unneeded). It also teaches the MachO writer to default to emitting versioned binaries, but with a version of 0 (and without the kernel ABI flag). Modern arm64e requires versioned binaries: a binary with 0x00 caps in cpusubtype is now rejected by the linker and everything after. We can live without the sophistication of specifying the version and kernel ABI for now. Co-authored-by: Francis Visoiu Mistrih <francisvm@apple.com>
I'm planning to remove StringRef::equals in favor of
StringRef::operator==.
- StringRef::operator==/!= outnumber StringRef::equals by a factor of
70 under llvm/ in terms of their usage.
- The elimination of StringRef::equals brings StringRef closer to
std::string_view, which has operator== but not equals.
- S == "foo" is more readable than S.equals("foo"), especially for
!Long.Expression.equals("str") vs Long.Expression != "str".
`macho-relative-method-lists.test` is failing on little endian
platforms, when matching 'name'.
```
CHK32-NEXT: name 0x144 (0x{{[0-9a-f]*}}) instance_method_00
next:10'0 X error: no match found
18: name 0x144 (0x7ac)
```
This seems like the obvious fix.
Co-authored-by: Alex B <alexborcan@meta.com>
For Mach-O, ld64 supports the -fobjc-relative-method-lists flag which changes the format in which method lists are generated. The format uses delta encoding vs the original direct-pointer encoding. This change adds support to llvm-objdump and llvm-otool for decoding/dumping of method lists in the delta format. Previously, if a binary with this information format was passed to the tooling, it would output invalid information, trying to parse the delta lists as pointer lists. After this change, the tooling will output correct information if a binary in this format is encountered. The output format is closest feasible match to XCode 15.1's otool output. Tests are included for both 32bit and 64bit binaries. The code style was matched as close as possible to existing implementation of parsing non-delta method lists. Diff between llvm-objdump and XCode 15.1 otool:  Note: This is a retry of this PR: https://github.com/llvm/llvm-project/pull/84250 On the original PR, the armv7+armv8 builds were failing due to absolute offsets being different. Co-authored-by: Alex B <alexborcan@meta.com>
This reverts llvm/llvm-project#84250, commit aa6100643c2c8f9a1b06ba557b68b0fba477e3c7. See build failures: https://lab.llvm.org/buildbot/#/builders/178/builds/7028 https://lab.llvm.org/buildbot/#/builders/182/builds/9282 https://lab.llvm.org/buildbot/#/builders/186/builds/15299 https://lab.llvm.org/buildbot/#/builders/187/builds/14564
For Mach-O, ld64 supports the `-fobjc-relative-method-lists` flag which changes the format in which method lists are generated. The format uses delta encoding vs the original direct-pointer encoding. This change adds support to `llvm-objdump` and `llvm-otool` for decoding/dumping of method lists in the delta format. Previously, if a binary with this information format was passed to the tooling, it would output invalid information, trying to parse the delta lists as pointer lists. After this change, the tooling will output correct information if a binary in this format is encountered. The output format is closest feasible match to XCode 15.1's otool output. Tests are included for both 32bit and 64bit binaries. The code style was matched as close as possible to existing implementation of parsing non-delta method lists. Diff between llvm-objdump and XCode 15.1 otool:  --------- Co-authored-by: Alex B <alexborcan@meta.com>