aboutsummaryrefslogtreecommitdiff
path: root/llvm/tools/llvm-objdump/MachODump.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-09-09MC: Use Triple form of lookupTarget in more places (#157591)Matt Arsenault1-2/+2
2025-09-08MC: Add Triple overloads for more MC constructors (#157321)Matt Arsenault1-21/+25
Avoids more Triple->string->Triple round trip. This is a continuation of f137c3d592e96330e450a8fd63ef7e8877fc1908
2025-08-11[llvm-objdump] Remove unnecessary casts (NFC) (#153128)Kazu Hirata1-3/+3
Ptr is already of const char *.
2025-08-07[llvm-objdump] Remove unnecessary casts (NFC) (#152443)Kazu Hirata1-8/+8
data() alaready returns const char *.
2025-05-25[llvm-objdump] Remove unused includes (NFC) (#141390)Kazu Hirata1-4/+0
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.
2025-03-17[NFC][DebugInfo] Wrap DILineInfo return type with std::optional to handle ↵Zequan Wu1-1/+2
missing debug info. (#129792) 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`.
2024-10-28[llvm-objdump] Handle -M for --machoFangrui Song1-0/+4
--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
2024-08-20[AArch64][MachO] Add ptrauth ABI version to arm64e cpusubtype. (#104650)Ahmed Bougacha1-3/+21
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>
2024-07-07[llvm] Remove redundant calls to std::unique_ptr<T>::get (NFC) (#97914)Kazu Hirata1-1/+1
2024-05-08[llvm] Use StringRef::operator== instead of StringRef::equals (NFC) (#91441)Kazu Hirata1-1/+1
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".
2024-03-19[llvm-objdump][macho] Fix relative method list dumping for little endian ↵alx321-4/+8
hosts (#85778) `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>
2024-03-16[llvm-objdump][macho] Add support for ObjC relative method lists (#85477)alx321-2/+110
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: ![image](https://github.com/llvm/llvm-project/assets/103613512/2277e3ff-d59c-4fff-b93a-e0587ee740a6) 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>
2024-03-15Revert "[llvm-objdump][macho] Add support for ObjC relative method lists ↵Kyungwoo Lee1-110/+2
(#84250)" 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
2024-03-14[llvm-objdump][macho] Add support for ObjC relative method lists (#84250)alx321-2/+110
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: ![objdump_vs_otool](https://github.com/llvm/llvm-project/assets/103613512/4fc04228-ed35-473d-b633-364402411b91) --------- Co-authored-by: Alex B <alexborcan@meta.com>
2023-12-11[llvm] Use StringRef::{starts,ends}_with (NFC) (#74956)Kazu Hirata1-2/+2
This patch replaces uses of StringRef::{starts,ends}with with StringRef::{starts,ends}_with for consistency with std::{string,string_view}::{starts,ends}_with in C++20. I'm planning to deprecate and eventually remove StringRef::{starts,ends}with.
2023-10-10Use llvm::endianness::{big,little,native} (NFC)Kazu Hirata1-3/+2
Note that llvm::support::endianness has been renamed to llvm::endianness while becoming an enum class as opposed to an enum. This patch replaces llvm::support::{big,little,native} with llvm::endianness::{big,little,native}.
2023-10-10[llvm] Drop unaligned from calls to llvm::support::endian::{read,write} (NFC)Kazu Hirata1-3/+1
The last template parameter of llvm::support::endian::{read,write} defaults to unaligned, so we can drop that at call sites.
2023-10-09[llvm][objdump] Remove support for printing the embedded Bitcode section in ↵Juergen Ributzka1-418/+0
MachO files. (#68457) It's no longer possible to submit bitcode apps to the Apple App Store. The tools used to create xar archived bitcode sections inside MachO files have been discontinued. Additionally, the xar APIs have been deprecated since macOS 12, so this change removes unnecessary code from objdump and all dependencies on libxar. This fixes rdar://116600767
2023-07-26[llvm-objdump] Remove bool MachOOnlyFirst from printPrivateHeaders after ↵Fangrui Song1-3/+3
D155045. NFC Mach-O can just use the global variable `FirstPrivateHeader`. If we ever manage to remove global variables, we can add a Config variable to Dumper. Either case, the parameter is not needed. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D156291
2023-07-14[llvm-objdump] Create ObjectFile specific dumpersFangrui Song1-2/+22
We pay the one-off boilerplate overhead to create `*Dumper` classes that derive from objdump::Dumper a la llvm-readobj. This has two primary advantages. First, a lot object file format specific code can be moved from llvm-objdump.cpp to *Dump.cpp files. Refactor `printPrivateHeaders` as an example. Second, with the introduction of ELFDumper<ELFT>, we can simplify a few dispatch functions in ELFDump.cpp. In addition, the ObjectFile specific dumpers contains a ObjectFile specific reference so that we can remove a lot of `cast<*ObjectFile>(Obj)`. Reviewed By: mtrofin Differential Revision: https://reviews.llvm.org/D155045
2023-07-11[llvm-objdump] Change errors to warnings for symbol section name dumpingFangrui Song1-1/+2
Port D69671 (llvm-readobj) to llvm-objdump. Add a class llvm::objdump::Dumper and move some free functions into Dumper so that they can call reportUniqueWarning. Warnings seems preferable in these cases as the issue is localized and we can continue dumping other information. Differential Revision: https://reviews.llvm.org/D154754
2023-06-13[llvm-objdump/mac] Add support for LC_ATOM_INFOKeith Smiley1-1/+4
This is a new load command first supported in Xcode 15's tools Differential Revision: https://reviews.llvm.org/D152847
2023-05-03[Demangle] remove unused status param of itaniumDemangleNick Desaulniers1-4/+2
No call sites interpreted this value meaningfully. Simplify this interface. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D149707
2023-05-03[Demangle] remove unused params of itaniumDemangleNick Desaulniers1-4/+2
No call sites use these parameters, so drop them. Equivalent to D148940. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D149703
2023-02-07[NFC][TargetParser] Remove llvm/ADT/Triple.hArchibald Elliott1-1/+1
I also ran `git clang-format` to get the headers in the right order for the new location, which has changed the order of other headers in two files.
2023-01-05Move from llvm::makeArrayRef to ArrayRef deduction guides - llvm/ partserge-sans-paille1-8/+8
Use deduction guides instead of helper functions. The only non-automatic changes have been: 1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*)) 2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase. 3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated. 4. The "reference mode" of makeArrayRef(ArrayRef<T> &) that acts as no-op is not supported (a constructor cannot achieve that). Per reviewers' comment, some useless makeArrayRef have been removed in the process. This is a follow-up to https://reviews.llvm.org/D140896 that introduced the deduction guides. Differential Revision: https://reviews.llvm.org/D140955
2022-10-14[llvm-objdump/mac] Add new function starts print modeKeith Smiley1-10/+46
This updates the `--function-starts` argument to now accept 3 different modes, `addrs` for just printing the addresses of the function starts (previous behavior), `names` for just printing the names of the function starts, and `both` to print them both side by side. In general if you're debugging function starts issues it's useful to see the symbol name alongside the address. This also mirrors Apple's `dyldinfo -function_starts` command which prints both. Differential Revision: https://reviews.llvm.org/D119050
2022-10-04[objdump] Support finding --source via --dsym filesJim Radford1-82/+109
Add support for auto-detecting or specifying dSYM files/directories to allow interleaving source with disassembly. Differential Revision: https://reviews.llvm.org/D135117 Patch by Jim Radford.
2022-08-31[lld-macho] Set the SG_READ_ONLY flag on __DATA_CONSTDaniel Bertalan1-0/+6
This flag instructs dyld to make the segment read-only after fixups have been performed. I'm not sure why this flag is needed, as on macOS 13 beta at least, __DATA_CONST is read-only even without this flag; but ld64 sets it as well. Differential Revision: https://reviews.llvm.org/D133010
2022-08-31[lld-macho] Support synthesizing __TEXT,__init_offsetsDaniel Bertalan1-0/+2
This section stores 32-bit `__TEXT` segment offsets of initializer functions, and is used instead of `__mod_init_func` when chained fixups are enabled. Storing the offsets lets us avoid emitting fixups for the initializers. Differential Revision: https://reviews.llvm.org/D132947
2022-08-30[llvm-otool] Print dyld_info output before chained_fixup outputNico Weber1-2/+2
This matches otool. Differential Revision: https://reviews.llvm.org/D132865
2022-08-28[llvm-objdump] Add -dyld_info to llvm-otoolDaniel Bertalan1-15/+59
This option outputs the location, encoded value and target of chained fixups, using the same format as `otool -dyld_info`. This initial implementation only supports the DYLD_CHAINED_PTR_64 and DYLD_CHAINED_PTR_64_OFFSET pointer encodings, which are used in x86_64 and arm64 userspace binaries. When Apple's effort to upstream their chained fixups code continues, we'll replace this code with the then-upstreamed code. But we need something in the meantime for testing ld64.lld's chained fixups code. Differential Revision: https://reviews.llvm.org/D132036
2022-08-24Add MachO MH_FILESET support to objdumpPeter Cooper1-0/+3
https://reviews.llvm.org/D131909
2022-08-24[llvm-objdump] Complete -chained_fixups supportDaniel Bertalan1-1/+30
This commit adds definitions for the `dyld_chained_import*` structs. The imports array is now printed with `llvm-otool -chained_fixups`. This completes this option's implementation. A slight difference from cctools otool is that we don't yet dump the raw bytes of the imports entries. When Apple's effort to upstream their chained fixups code continues, we'll replace this code with the then-upstreamed code. But we need something in the meantime for testing ld64.lld's chained fixups code. Differential Revision: https://reviews.llvm.org/D131982
2022-08-18[llvm-objdump] Support dumping segment information with -chained_fixupsDaniel Bertalan1-0/+80
This commit adds the definitions for `dyld_chained_starts_in_image`, `dyld_chained_starts_in_segment`, and related enums. Dumping their contents is possible with the -chained_fixups flag of llvm-otool. The chained-fixups.yaml test was changed to cover bindings/rebases, as well as weak imports, weak symbols and flat namespace symbols. Now that we have actual fixup entries, the __DATA segment contains data that would need to be hexdumped in YAML. We also test empty pages (to look for the "DYLD_CHAINED_PTR_START_NONE" annotation), so the YAML would end up quite large. So instead, this commit includes a binary file. When Apple's effort to upstream their chained fixups code continues, we'll replace this code with the then-upstreamed code. But we need something in the meantime for testing ld64.lld's chained fixups code. Differential Revision: https://reviews.llvm.org/D131961
2022-08-15[llvm-objdump] Start on -chained_fixups for llvm-otoolNico Weber1-2/+49
And --chained-fixups for llvm-objdump. For now, this only prints the dyld_chained_fixups_header and adds plumbing for the flag. This will be expanded in future commits. When Apple's effort to upstream their chained fixups code continues, we'll replace this code with the then-upstreamed code. But we need something in the meantime for testing ld64.lld's chained fixups code. Update chained-fixups.yaml with a file that actually contains the chained fixup data (`LinkEditData` doesn't encode it yet, so use `__LINKEDIT` via `--raw-segment=data`). Differential Revision: https://reviews.llvm.org/D131890
2022-07-07[llvm-objdump] Change some nonnull pointers to references. NFCFangrui Song1-2/+2
2022-05-25[MCDisassembler] Disambiguate Size parameter in tryAddingSymbolicOperand()Maksim Panchenko1-7/+8
MCSymbolizer::tryAddingSymbolicOperand() overloaded the Size parameter to specify either the instruction size or the operand size depending on the architecture. However, for proper symbolic disassembly on X86, we need to know both sizes, as an instruction can have two operands, and the instruction size cannot be reliably calculated based on the operand offset and its size. Hence, split Size into OpSize and InstSize. For X86, the new interface allows to fix a couple of issues: * Correctly adjust the value of PC-relative operands. * Set operand size to zero when the operand is specified implicitly. Differential Revision: https://reviews.llvm.org/D126101
2022-05-04[llvm-otool] Make `llvm-otool -l` output compatible with otool for ↵Nico Weber1-7/+17
LC_BUILD_VERSION Namely, only "symbolize" platform and tool names if `-v` is passed. (`llvm-otool -lv` output still isn't quite the same as `otool -lv` output, but `-v` output is arguably for consumption by humans, so I'm not changing that at this point. Someone else could change it if it was important to them.) Differential Revision: https://reviews.llvm.org/D124920
2022-02-22[NFC] Remove dead code (try 2)Arthur Eubanks1-5/+3
This is causing ../../llvm/include/llvm/Object/MachO.h:379:13: warning: private field 'Kind' is not used [-Wunused-private-field] FixupKind Kind; Previous attempt in a23f7c0cb6b42a06bc9707fdf46ce2a90080f61f.
2022-02-22Add support for chained fixup load commands to MachOObjectFileAdrian Prantl1-2/+13
This is part of a series of patches to upstream support for Mach-O chained fixups. This patch adds support for parsing the chained fixup load command and parsing the chained fixups header. It also puts into place the abstract interface that will be used to iterate over the fixups. Differential Revision: https://reviews.llvm.org/D113630
2022-02-22Add a (nonfunctional) -dyld_info flag to llvm-objdump.Adrian Prantl1-2/+11
Darwin otool implements this flag as a one-stop solution for displaying bind and rebase info. As I am working on upstreaming chained fixup support this command will be useful to write testcases. Differential Revision: https://reviews.llvm.org/D113573
2022-02-09[llvm-objdump/mac] Silence XAR deprecation warning (NFC)Keith Smiley1-2/+6
If you're building this on macOS 12.x+ this produces a deprecation warning. I'm not sure what this means for the bitcode format going forward, but it seems safe to silence for now. Differential Revision: https://reviews.llvm.org/D118569
2022-01-23[llvm-objdump] Use cast<> instead of dyn_cast<> to avoid dereference of nullptrSimon Pilgrim1-2/+2
The pointers are always dereferenced immediately, so assert the cast is correct instead of returning nullptr
2021-12-28[llvm] Use nullptr instead of 0 (NFC)Kazu Hirata1-2/+2
Identified with modernize-use-nullptr.
2021-11-17[llvm-objdump/mac] Add support for new load commandsKeith Smiley1-1/+7
Differential Revision: https://reviews.llvm.org/D113733
2021-10-08Move TargetRegistry.(h|cpp) from Support to MCReid Kleckner1-1/+1
This moves the registry higher in the LLVM library dependency stack. Every client of the target registry needs to link against MC anyway to actually use the target, so we might as well move this out of Support. This allows us to ensure that Support doesn't have includes from MC/*. Differential Revision: https://reviews.llvm.org/D111454
2021-06-30[llvm-objdump/mac] Print symbols at the same address deterministicallyJez Ng1-1/+1
By using stable_sort. Added a test case which previously failed when expensive checks were enabled. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D105240
2021-05-23[MC] Refactor MCObjectFileInfo initialization and allow targets to create ↵Philipp Krones1-4/+2
MCObjectFileInfo This makes it possible for targets to define their own MCObjectFileInfo. This MCObjectFileInfo is then used to determine things like section alignment. This is a follow up to D101462 and prepares for the RISCV backend defining the text section alignment depending on the enabled extensions. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D101921
2021-05-19Fix lld macho standalone build by including llvm/Config/llvm-config.h ↵Mariusz Ceier1-9/+9
instead of llvm/Config/config.h lld/MachO/Driver.cpp and lld/MachO/SyntheticSections.cpp include llvm/Config/config.h which doesn't exist when building standalone lld. This patch replaces llvm/Config/config.h include with llvm/Config/llvm-config.h just like it is in lld/ELF/Driver.cpp and HAVE_LIBXAR with LLVM_HAVE_LIXAR and moves LLVM_HAVE_LIBXAR from config.h to llvm-config.h Also it adds LLVM_HAVE_LIBXAR to LLVMConfig.cmake and links liblldMachO2.so with XAR_LIB if LLVM_HAVE_LIBXAR is set. Differential Revision: https://reviews.llvm.org/D102084
generated by cgit v1.1 at 2025-09-29 15:30:00 +0000