[llvm-objdump] Handle -M for --macho

--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/l

[llvm-objdump] Handle -M for --macho

--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

show more ...

[AArch64][MachO] Add ptrauth ABI version to arm64e cpusubtype. (#104650)

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 sub

[AArch64][MachO] Add ptrauth ABI version to arm64e cpusubtype. (#104650)

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>

show more ...

[llvm] Remove redundant calls to std::unique_ptr<T>::get (NFC) (#97914)

[llvm] Use StringRef::operator== instead of StringRef::equals (NFC) (#91441)

I'm planning to remove StringRef::equals in favor of
StringRef::operator==.

- StringRef::operator==/!= outnumber Stri

[llvm] Use StringRef::operator== instead of StringRef::equals (NFC) (#91441)

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".

show more ...

[llvm-objdump][macho] Fix relative method list dumping for little endian hosts (#85778)

`macho-relative-method-lists.test` is failing on little endian
platforms, when matching 'name'.

```
CHK32

[llvm-objdump][macho] Fix relative method list dumping for little endian 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>

show more ...

[llvm-objdump][macho] Add support for ObjC relative method lists (#85477)

For Mach-O, ld64 supports the -fobjc-relative-method-lists flag which
changes the format in which method lists are generate

[llvm-objdump][macho] Add support for ObjC relative method lists (#85477)

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>

show more ...

Revert "[llvm-objdump][macho] Add support for ObjC relative method lists (#84250)"

This reverts llvm/llvm-project#84250, commit aa6100643c2c8f9a1b06ba557b68b0fba477e3c7.

See build failures:
https:/

Revert "[llvm-objdump][macho] Add support for ObjC relative method lists (#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

show more ...

[llvm-objdump][macho] Add support for ObjC relative method lists (#84250)

For Mach-O, ld64 supports the `-fobjc-relative-method-lists` flag which
changes the format in which method lists are genera

[llvm-objdump][macho] Add support for ObjC relative method lists (#84250)

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>

show more ...

[llvm] Use StringRef::{starts,ends}_with (NFC) (#74956)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::

[llvm] Use StringRef::{starts,ends}_with (NFC) (#74956)

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.

show more ...

Use llvm::endianness::{big,little,native} (NFC)

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:

Use llvm::endianness::{big,little,native} (NFC)

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}.

show more ...

[llvm] Drop unaligned from calls to llvm::support::endian::{read,write} (NFC)

The last template parameter of llvm::support::endian::{read,write}
defaults to unaligned, so we can drop that at call si

[llvm] Drop unaligned from calls to llvm::support::endian::{read,write} (NFC)

The last template parameter of llvm::support::endian::{read,write}
defaults to unaligned, so we can drop that at call sites.

show more ...

[llvm][objdump] Remove support for printing the embedded Bitcode section in MachO files. (#68457)

It's no longer possible to submit bitcode apps to the Apple App Store.
The tools
used to create xa

[llvm][objdump] Remove support for printing the embedded Bitcode section in 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

show more ...

[llvm-objdump] Remove bool MachOOnlyFirst from printPrivateHeaders after D155045. NFC

Mach-O can just use the global variable `FirstPrivateHeader`.
If we ever manage to remove global variables, we c

[llvm-objdump] Remove bool MachOOnlyFirst from printPrivateHeaders after 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

show more ...

[llvm-objdump] Create ObjectFile specific dumpers

We pay the one-off boilerplate overhead to create `*Dumper` classes that derive
from objdump::Dumper a la llvm-readobj. This has two primary advanta

[llvm-objdump] Create ObjectFile specific dumpers

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

show more ...

[llvm-objdump] Change errors to warnings for symbol section name dumping

Port D69671 (llvm-readobj) to llvm-objdump. Add a class llvm::objdump::Dumper
and move some free functions into Dumper so tha

[llvm-objdump] Change errors to warnings for symbol section name dumping

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

show more ...

[llvm-objdump/mac] Add support for LC_ATOM_INFO

This is a new load command first supported in Xcode 15's tools

Differential Revision: https://reviews.llvm.org/D152847

[Demangle] remove unused status param of itaniumDemangle

No call sites interpreted this value meaningfully. Simplify this
interface.

Reviewed By: MaskRay

Differential Revision: https://reviews.llv

[Demangle] remove unused status param of itaniumDemangle

No call sites interpreted this value meaningfully. Simplify this
interface.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D149707

show more ...

[Demangle] remove unused params of itaniumDemangle

No call sites use these parameters, so drop them.
Equivalent to D148940.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D14

[Demangle] remove unused params of itaniumDemangle

No call sites use these parameters, so drop them.
Equivalent to D148940.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D149703

show more ...

[NFC][TargetParser] Remove llvm/ADT/Triple.h

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.

Move from llvm::makeArrayRef to ArrayRef deduction guides - llvm/ part

Use deduction guides instead of helper functions.

The only non-automatic changes have been:

1. ArrayRef(some_uint8_pointer, 0

Move from llvm::makeArrayRef to ArrayRef deduction guides - llvm/ part

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

show more ...

[llvm-objdump/mac] Add new function starts print mode

This updates the `--function-starts` argument to now accept 3 different
modes, `addrs` for just printing the addresses of the function starts
(p

[llvm-objdump/mac] Add new function starts print mode

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

show more ...

[objdump] Support finding --source via --dsym files

Add support for auto-detecting or specifying dSYM files/directories to
allow interleaving source with disassembly.

Differential Revision: https:/

[objdump] Support finding --source via --dsym files

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.

show more ...

[lld-macho] Set the SG_READ_ONLY flag on __DATA_CONST

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 b

[lld-macho] Set the SG_READ_ONLY flag on __DATA_CONST

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

show more ...

[lld-macho] Support synthesizing __TEXT,__init_offsets

This section stores 32-bit `__TEXT` segment offsets of initializer
functions, and is used instead of `__mod_init_func` when chained fixups
are

[lld-macho] Support synthesizing __TEXT,__init_offsets

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

show more ...

[llvm-otool] Print dyld_info output before chained_fixup output

This matches otool.

Differential Revision: https://reviews.llvm.org/D132865