aboutsummaryrefslogtreecommitdiff
path: root/llvm/tools/llvm-objdump/MachODump.cpp
AgeCommit message (Collapse)AuthorFilesLines
2021-05-10[llvm-objdump][MachO] Print a newline before lazy bind/bind/weak/exports trieFangrui Song1-5/+5
This adds a separator between two pieces of information. Reviewed By: #lld-macho, alexshap Differential Revision: https://reviews.llvm.org/D102114
2021-05-05[MC] Untangle MCContext and MCObjectFileInfoPhilipp Krones1-2/+5
This untangles the MCContext and the MCObjectFileInfo. There is a circular dependency between MCContext and MCObjectFileInfo. Currently this dependency also exists during construction: You can't contruct a MOFI without a MCContext without constructing the MCContext with a dummy version of that MOFI first. This removes this dependency during construction. In a perfect world, MCObjectFileInfo wouldn't depend on MCContext at all, but only be stored in the MCContext, like other MC information. This is future work. This also shifts/adds more information to the MCContext making it more available to the different targets. Namely: - TargetTriple - ObjectFileType - SubtargetInfo Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D101462
2021-04-22llvm-objdump: add --rpaths to macho supportKeith Smiley1-1/+15
This prints the rpaths for the given binary Reviewed By: kastiglione Differential Revision: https://reviews.llvm.org/D100681
2021-04-20[llvm-objdump] Remove "No" prefixes on variablesNico Weber1-26/+26
...to remove double negation in the code. Requested in D100583. No behavior change. Differential Revision: https://reviews.llvm.org/D100849
2021-04-20[llvm-objdump] Prefer positive boolean Verbose instead of negative ↵Fangrui Song1-15/+15
NonVerbose. NFC Differential Revision: https://reviews.llvm.org/D100791
2021-04-20[llvm-objdump] Add an llvm-otool toolNico Weber1-5/+5
This implements an LLVM tool that's flag- and output-compatible with macOS's `otool` -- except for bugs, but from testing with both `otool` and `xcrun otool-classic`, llvm-otool matches vanilla otool's behavior very well already. It's not 100% perfect, but it's a very solid start. This uses the same approach as llvm-objcopy: llvm-objdump uses a different OptTable when it's invoked as llvm-otool. This is possible thanks to D100433. Differential Revision: https://reviews.llvm.org/D100583
2021-04-14[llvm-objdump] Switch command-line parsing from llvm::cl to OptTableNico Weber1-122/+53
This is similar to D83530, but for llvm-objdump. The motivation is the desire to add an `llvm-otool` symlink to llvm-objdump that behaves like macOS's `otool`, using the same technique the at llvm-objcopy uses to behave like `strip` (etc). This change for the most part preserves behavior. In some cases, it increases compatibility with GNU objdump a bit. For example, the long options now require two dashes, and the long options taking arguments for the most part now require a `=` in front of the value. Exceptions are flags where tests passed the value separately, for these the separate form is kept as an alias to the = form. The one-letter short form args are now joined or separate and long longer accept a =, which also matches GNU objdump. cl::opt<>s in libraries now have to be explicitly plumbed through. This patch does that for --x86-asm-syntax=, but there's hope that we can remove that again. Differential Revision: https://reviews.llvm.org/D100433
2021-04-12Replace uses of std::iterator with explicit usingHamza Sood1-2/+2
This patch removes all uses of `std::iterator`, which was deprecated in C++17. While this isn't currently an issue while compiling LLVM, it's useful for those using LLVM as a library. For some reason there're a few places that were seemingly able to use `std` functions unqualified, which no longer works after this patch. I've updated those places, but I'm not really sure why it worked in the first place. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D67586
2021-03-08[llvm-objdump][MachO] Add support for dumping function startsAlexander Shaposhnikov1-2/+47
Add support for dumping function starts for Mach-O binaries. Test plan: make check-all Differential revision: https://reviews.llvm.org/D97027
2021-03-06[objdump] Use ListSeparator (NFC)Kazu Hirata1-27/+11
2021-01-29[llvm-objdump-macho] print per-second-level-page encodings for option ↵Greg McGary1-7/+16
--unwind-info Compact unwind entries have 8 bits for the encoding-table offset: * offsets 0..126 reference the global commmon-encodings table, while * offsets 127..255 reference a per-second-level-page table. This diff teaches `llvm-objdump` to print this per-page encodings table. Differential Revision: https://reviews.llvm.org/D93265
2021-01-26[llvm-objdump] Use append_range (NFC)Kazu Hirata1-10/+5
2021-01-12[llvm] Remove redundant string initialization (NFC)Kazu Hirata1-2/+2
Identified with readability-redundant-string-init.
2020-12-25[llvm-nm, llvm-objdump] Use llvm::is_contained (NFC)Kazu Hirata1-3/+1
2020-12-14[llvm-objdump] Use "--" for long options in --help textDavid Spickett1-12/+12
Single dash for these options is not recognised. Changes found by running this on the --help output and the user guide: grep -e ' -[a-zA-Z]\{2,\}' The user guide was updated in https://reviews.llvm.org/D92305 so no change there. Reviewed By: jhenderson, MaskRay Differential Revision: https://reviews.llvm.org/D92310
2020-11-21[llvm][clang][mlir] Add checks for the return values from Target::createXXX ↵Ella Ma1-13/+35
to prevent protential null deref All these potential null pointer dereferences are reported by my static analyzer for null smart pointer dereferences, which has a different implementation from `alpha.cplusplus.SmartPtr`. The checked pointers in this patch are initialized by Target::createXXX functions. When the creator function pointer is not correctly set, a null pointer will be returned, or the creator function may originally return a null pointer. Some of them may not make sense as they may be checked before entering the function, but I fixed them all in this patch. I submit this fix because 1) similar checks are found in some other places in the LLVM codebase for the same return value of the function; and, 2) some of the pointers are dereferenced before they are checked, which may definitely trigger a null pointer dereference if the return value is nullptr. Reviewed By: tejohnson, MaskRay, jpienaar Differential Revision: https://reviews.llvm.org/D91410
2020-10-16[objdump][macho] Check arch before formating reloc name as arm64 addendPeng Guo1-1/+2
Before formating ARM64_RELOC_ADDEND relocation target name as a hex number, the architecture need to be checked since other architectures can define a different relocation type with the same integer as ARM64_RELOC_ADDEND. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D89094
2020-08-07[llvm-libtool-darwin] Add constant CPU_SUBTYPE_ARM64_V8Sameer Arora1-0/+7
Add support for constant MachO::CPU_SUBTYPE_ARM64_V8. This constant is needed so as to match `llvm-libtool-darwin`'s behavior to that of cctools' libtool when `-arch_only` flag is passed in on command line. Reviewed by jhenderson, alexshap, smeenai Differential Revision: https://reviews.llvm.org/D85041
2020-05-02[Object] Change ObjectFile::getSymbolValue() return type to Expected<uint64_t>Xing GUO1-9/+11
Summary: In D77860, we have changed `getSymbolFlags()` return type to `Expected<uint32_t>`. This change helps bubble the error further up the stack. Reviewers: jhenderson, grimar, JDevlieghere, MaskRay Reviewed By: jhenderson Subscribers: hiraditya, MaskRay, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D79075
2020-04-18[Object] Change uint32_t getSymbolFlags() to Expected<uint32_t> ↵vgxbj1-1/+2
getSymbolFlags(). This change enables getSymbolFlags() to return errors which benefit error reporting in clients. Differential Revision: https://reviews.llvm.org/D77860
2020-04-09[llvm-objdump][NFC] MachODump.cpp interface cleanupHubert Tong1-26/+28
Continuing from D77388, this patch moves interface declarations associated with `MachODump.cpp` into the headers corresponding to the file that defines the variable. At the same time, these externs are moved into the `llvm::objdump` namespace. The externs defined in `MachODump.cpp` that are not referenced outside of it are given internal linkage. This patch does not rename the external functions defined by `MachODump.cpp` that are not clearly named as being specific to Mach-O. Reviewed By: jhenderson, MaskRay Differential Revision: https://reviews.llvm.org/D77730
2020-04-06[llvm-objdump][NFC] Declare command-line externs in headers with namespaceHubert Tong1-83/+71
Summary: This patch moves the forward declarations of command-line `cl::*` externs in `MachODump.cpp` and `llvm-objdump.cpp` into the headers corresponding to the file that defines the variable. At the same time, these externs are moved into the `llvm::objdump` namespace. The externs that are not referenced outside their defining translation unit are made static. This does not factor out uses of the Mach-O options from `llvm-objdump.cpp`. Reviewers: jhenderson, MaskRay, DiggerLin, jasonliu, daltenty Reviewed By: jhenderson, MaskRay Subscribers: rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77388
2020-02-03Omit "Contents of" headers when -no-leading-headers is specified.Michael Trent1-2/+3
Summary: llvm-objdump -macho will no longer print "Contents of" headers when disassembling section contents when -no-leading-headers is specified. For historical reasons, this flag is independent of -no-leading-addr. Reviewers: ab, pete, jhenderson Reviewed By: jhenderson Subscribers: rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73574
2020-02-03[llvm-objdump] Suppress spurious warnings when parsing Mach-O binaries.Michael Trent1-0/+6
Summary: llvm-objdump started warning when asked to disassemble a section that isn't present in the input files, in Yuanfang Chen's change: d16c162c9453db855503134fe29ae4a3c0bec936. The problem is that the logic was restricted only to the generic llvm-objdump parser, not to the Mach-O-specific parser used for Apple toolchain compatibility. The solution is to log section names from the Mach-O parser. The macho-cstring-dump.test has been updated to fail if it encounters this new warning in the future. Reviewers: pete, ab, lhames, jhenderson, grimar, MaskRay, ychen Reviewed By: jhenderson, grimar Subscribers: rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73586
2020-01-28Make llvm::StringRef to std::string conversions explicit.Benjamin Kramer1-1/+1
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here. This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies. This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2020-01-11[Disassembler] Delete the VStream parameter of MCDisassembler::getInstruction()Fangrui Song1-9/+3
The argument is llvm::null() everywhere except llvm::errs() in llvm-objdump in -DLLVM_ENABLE_ASSERTIONS=On builds. It is used by no target but X86 in -DLLVM_ENABLE_ASSERTIONS=On builds. If we ever have the needs to add verbose log to disassemblers, we can record log with a member function, instead of passing it around as an argument.
2020-01-07[NFC] Use isX86() instead of getArch()Jim Lin1-4/+2
Summary: This is a clean up for https://reviews.llvm.org/D72247. Reviewers: MaskRay, craig.topper, jhenderson Reviewed By: MaskRay Subscribers: hiraditya, rupprecht, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72320
2020-01-06[MC] Add parameter `Address` to MCInstPrinter::printInstFangrui Song1-3/+4
printInst prints a branch/call instruction as `b offset` (there are many variants on various targets) instead of `b address`. It is a convention to use address instead of offset in most external symbolizers/disassemblers. This difference makes `llvm-objdump -d` output unsatisfactory. Add `uint64_t Address` to printInst(), so that it can pass the argument to printInstruction(). `raw_ostream &OS` is moved to the last to be consistent with other print* methods. The next step is to pass `Address` to printInstruction() (generated by tablegen from the instruction set description). We can gradually migrate targets to print addresses instead of offsets. In any case, downstream projects which don't know `Address` can pass 0 as the argument. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D72172
2020-01-06[NFC] Fix trivial typos in commentsJames Henderson1-1/+1
Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D72143 Patch by Kazuaki Ishizaki.
2019-10-23[Mips] Use appropriate private label prefix based on Mips ABIMirko Brkusanin1-4/+6
MipsMCAsmInfo was using '$' prefix for Mips32 and '.L' for Mips64 regardless of -target-abi option. By passing MCTargetOptions to MCAsmInfo we can find out Mips ABI and pick appropriate prefix. Tags: #llvm, #clang, #lldb Differential Revision: https://reviews.llvm.org/D66795
2019-10-18Fix MSVC "result of 32-bit shift implicitly converted to 64 bits" warnings. ↵Simon Pilgrim1-1/+1
NFCI. llvm-svn: 375213
2019-09-20Can't pass .dSYM directory to llvm-objdump -dsym= (and error message is wrong)Michael Trent1-9/+22
Summary: Allow users to pass the path to a .dSYM directory to llvm-objdump's -dsym flag rather than requiring users to find the DWARF DSYM Mach-O within the bundle structure by hand. rdar://46873333 Reviewers: pete, lhames, friss, aprantl Reviewed By: pete, aprantl Subscribers: MaskRay, aprantl, rupprecht, seiya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67780 llvm-svn: 372421
2019-09-19[Object] Extend MachOUniversalBinary::getObjectForArchAlexander Shaposhnikov1-1/+1
Make the method MachOUniversalBinary::getObjectForArch return MachOUniversalBinary::ObjectForArch and add helper methods MachOUniversalBinary::getMachOObjectForArch, MachOUniversalBinary::getArchiveForArch for those who explicitly expect to get a MachOObjectFile or an Archive. Differential revision: https://reviews.llvm.org/D67700 Test plan: make check-all llvm-svn: 372278
2019-08-27[llvm-objdump] - Remove one overload of reportError. NFCI.George Rimar1-24/+22
There is a problem with reportError we have. Declaration says we have ArchiveName that follows the FileName: reportError(Error E, StringRef FileName, StringRef ArchiveName,... Though implementation have them reversed. I cleaned it up and removed an excessive reportError(Error E, StringRef File) version. Rebased on top of D66418. Differential revision: https://reviews.llvm.org/D66517 llvm-svn: 370034
2019-08-21[llvm-objdump] - Cleanup the error reporting.George Rimar1-44/+45
The error reporting function are not consistent. Before this change: * They had inconsistent naming (e.g. 'error' vs 'report_error'). * Some of them reported the object name, others - dont. * Some of them accepted the case when there was no error. (i.e. error code or Error had a success value). This patch tries to cleanup it a bit. It also renames report_error -> reportError, report_warning -> reportWarning and removes a full stop from messages. Differential revision: https://reviews.llvm.org/D66418 llvm-svn: 369515
2019-08-20[llvm-objdump] - Remove one of `report_error` functions and improve the ↵George Rimar1-13/+36
error reporting. One of the report_error functions was taking object::Archive::Child as an argument. It feels excessive, this patch removes it and introduce a helper function instead. Also I fixed a "TODO" in this patch what improved the message printed. Differential revision: https://reviews.llvm.org/D66468 llvm-svn: 369382
2019-08-15[llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere1-4/+4
Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
2019-08-14Recommit r368812 "[llvm/Object] - Convert SectionRef::getName() to return ↵George Rimar1-47/+109
Expected<>" Changes: no changes. A fix for the clang code will be landed right on top. Original commit message: SectionRef::getName() returns std::error_code now. Returning Expected<> instead has multiple benefits. For example, it forces user to check the error returned. Also Expected<> may keep a valuable string error message, what is more useful than having a error code. (Object\invalid.test was updated to show the new messages printed.) This patch makes a change for all users to switch to Expected<> version. Note: in a few places the error returned was ignored before my changes. In such places I left them ignored. My intention was to convert the interface used, and not to improve and/or the existent users in this patch. (Though I think this is good idea for a follow-ups to revisit such places and either remove consumeError calls or comment each of them to clarify why it is OK to have them). Differential revision: https://reviews.llvm.org/D66089 llvm-svn: 368826
2019-08-14Revert r368812 "[llvm/Object] - Convert SectionRef::getName() to return ↵George Rimar1-109/+47
Expected<>" It broke clang BB: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/16455 llvm-svn: 368813
2019-08-14[llvm/Object] - Convert SectionRef::getName() to return Expected<>George Rimar1-47/+109
SectionRef::getName() returns std::error_code now. Returning Expected<> instead has multiple benefits. For example, it forces user to check the error returned. Also Expected<> may keep a valuable string error message, what is more useful than having a error code. (Object\invalid.test was updated to show the new messages printed.) This patch makes a change for all users to switch to Expected<> version. Note: in a few places the error returned was ignored before my changes. In such places I left them ignored. My intention was to convert the interface used, and not to improve and/or the existent users in this patch. (Though I think this is good idea for a follow-ups to revisit such places and either remove consumeError calls or comment each of them to clarify why it is OK to have them). Differential revision: https://reviews.llvm.org/D66089 llvm-svn: 368812
2019-08-01[llvm-objdump] Fix jumptable detection when disassembling Mach-O binariesKuba Mracek1-18/+36
- Add LC_SEGMENT_64 handling in getSectionsAndSymbols to be able to find the base segment address from 64-bit Mach-O binaries. - Add "data in code" detection into the !symbolTableWorked case, extract it into a separate function. - Fix uninitialized variable usage on BaseSegmentAddress (initialize to 0). - Add test. Differential Revision: https://reviews.llvm.org/D65491 llvm-svn: 367578
2019-06-18Print dylib load kind (weak, reexport, etc) in llvm-objdump -m -dylibs-usedMichael Trent1-1/+10
Summary: Historically llvm-objdump prints the path to a dylib as well as the dylib's compatibility version and current version number. This change extends this information by adding the kind of dylib load: weak, reexport, etc. rdar://51383512 Reviewers: pete, lhames Reviewed By: pete Subscribers: rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62866 llvm-svn: 363746
2019-05-30Write new tests for r362121Michael Trent1-6/+57
Summary: The tests for r362121 ran dsymutil against a test binary every time. This caused problems on lld-x86_64-ubuntu-fast as dsymutil required a lipo tool be available to process those binaries. This change rewrites the new test cases in macho-disassemble-g-dsym to use bespoke test binaries (exe and dwarf) simplifying the test's runtime dependencies. The changes to tools/llvm-objdump/MachODump.cpp are unchanged from r362121 Reviewers: pete, lhames, JDevlieghere Reviewed By: pete Subscribers: smeenai, aprantl, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62694 llvm-svn: 362141
2019-05-30Reverting change r362121 due to lld-x86_64-ubuntu-fast test failuresMichael Trent1-57/+6
llvm-svn: 362123
2019-05-30Support Universal dSYM files in llvm-objdumpMichael Trent1-6/+57
Summary: Commonly programmers use llvm-objdump to disassemble Mach-O target binaries with Mach-O dSYMS. While llvm-objdump allows programmers to disassemble Universal binaries, it previously did not recognize Universal dSYM files. This change updates llvm-objdump to support passing in Universal files via the -dsym option. Now, when disassembling a Mach-O file either as a stand alone file or as an entry in a Universal binariy, llvm-objdump will search through a Universal dSYM for a Mach-O matching the architecture flag of the file being disassembled. Reviewers: pete, lhames Reviewed By: pete Subscribers: rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62642 llvm-svn: 362121
2019-05-22Properly categorize llvm-objdump optionsSerge Guelton1-23/+47
Filters out noise, and distinguish Mach-O related options from others. Differential Revision: https://reviews.llvm.org/D62195 llvm-svn: 361351
2019-05-16Recommit [Object] Change object::SectionRef::getContents() to return ↵Fangrui Song1-19/+16
Expected<StringRef> r360876 didn't fix 2 call sites in clang. Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now. Follow-up of D61781. llvm-svn: 360892
2019-05-16Revert r360876 "[Object] Change object::SectionRef::getContents() to return ↵Hans Wennborg1-16/+19
Expected<StringRef>" It broke the Clang build, see llvm-commits thread. > Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now. > > Follow-up of D61781. llvm-svn: 360878
2019-05-16[Object] Change object::SectionRef::getContents() to return Expected<StringRef>Fangrui Song1-19/+16
Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now. Follow-up of D61781. llvm-svn: 360876
2019-05-14AArch64: support binutils-like things on arm64_32.Tim Northover1-2/+27
This adds support for the arm64_32 watchOS ABI to LLVM's low level tools, teaching them about the specific MachO choices and constants needed to disassemble things. llvm-svn: 360663
generated by cgit v1.1 at 2025-09-29 18:29:59 +0000