[yaml2obj][obj2yaml][objdump] Handle MIPS COFF files (#112591)

- handle IMAGE_FILE_MACHINE_R4000 machine type
- handle MIPS COFF relocations

llvm-objdump can now parse MIPS COFF files.

[COFF] Add MIPS relocation types (#107814)

Add the MIPS COFF relocation types. They will be needed to add support
for MIPS Windows object file.

This is an extract of PR
https://github.com/llvm/

[COFF] Add MIPS relocation types (#107814)

Add the MIPS COFF relocation types. They will be needed to add support
for MIPS Windows object file.

This is an extract of PR
https://github.com/llvm/llvm-project/pull/107744.

show more ...

[Object][COFF] Fix CHPE metadata offset check (#109591)

[llvm] Prefer StringRef::substr to StringRef::slice (NFC) (#106190)

S.substr(N, M) is simpler than S.slice(N, N + M). Also, substr is
probably better recognizable than slice thanks to
std::string

[llvm] Prefer StringRef::substr to StringRef::slice (NFC) (#106190)

S.substr(N, M) is simpler than S.slice(N, N + M). Also, substr is
probably better recognizable than slice thanks to
std::string_view::substr.

show more ...

[llvm-readobj][COFF] Dump hybrid objects for ARM64X files. (#102245)

Fix MSVC "result of 32-bit shift implicitly converted to 64 bits" warning. NFC.

Remove unnecessary break to fix static analysis warning.

Fix MSVC "not all control paths return a value" warning. NFC.

[Object][COFF] Use uintptr_t for getRvaPtr call in Arm64XRelocRef::validate.

Fixes #97229.

[Object][COFF][llvm-readobj] Add support for ARM64X dynamic relocations. (#97229)

[nfc] Allow forwarding `Error` returns from `Expected` callers (#92208)

On a few compilers (clang 11/12 for example [1]), the following does not
result in a copy elision, and since `Error`'s copy d

[nfc] Allow forwarding `Error` returns from `Expected` callers (#92208)

On a few compilers (clang 11/12 for example [1]), the following does not
result in a copy elision, and since `Error`'s copy dtor is elided,
results in a compile error:

```
Expect<Something> foobar() {
...
if (Error E = aCallReturningError())
return E;
...
}
```

Moving `E` would, conversely, result in the pessimizing-move warning on
more recent clangs ("moving a local object in a return statement
prevents copy elision")

We just need to make the `Expected` ctor taking an `Error` take it as a
r-value reference.

[1] https://lab.llvm.org/buildbot/#/builders/54/builds/10505

show more ...

[Object][COFF][NFC] Introduce getMachineArchType helper. (#87370)

It's a common pattern that we have a machine type, but we don't care
which ARM64* platform we're dealing with. We already have
isA

[Object][COFF][NFC] Introduce getMachineArchType helper. (#87370)

It's a common pattern that we have a machine type, but we don't care
which ARM64* platform we're dealing with. We already have
isAnyArm64 for that, but it does not fit cases where we use a switch
statement. With this helper, it's easy to simplify such cases by using
Triple::ArchType instead of machine type.

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 suppo

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 support::{big,little,native} with
llvm::endianness::{big,little,native}.

show more ...

[llvm-readobj] Add support for dumping CHPE metadata.

CHPE metadata is used by ARM64EC/ARM64X PE files to provide metadata for
emulator/loader. Most of this metadata will need to be generated by LLD

[llvm-readobj] Add support for dumping CHPE metadata.

CHPE metadata is used by ARM64EC/ARM64X PE files to provide metadata for
emulator/loader. Most of this metadata will need to be generated by LLD.

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

show more ...

[llvm-lib] [llvm-readobj] [llvm-cvtres] Add Support for ARM64X object files.

Similar to D125411, but for ARM64X.

ARM64X PE binaries are hybrids containing both ARM64EC and pure ARM64
variants in on

[llvm-lib] [llvm-readobj] [llvm-cvtres] Add Support for ARM64X object files.

Similar to D125411, but for ARM64X.

ARM64X PE binaries are hybrids containing both ARM64EC and pure ARM64
variants in one file. They are usually linked by passing separate
ARM64EC and ARM64 object files to linker. Linked binaries use ARM64
machine and contain additional CHPE metadata in their load config.
CHPE metadata support is not part of this patch, I plan to send that later.

Using ARM64X as a machine type of object files themselves is somewhat
ambiguous, but such files are allowed by MSVC. It treats them as ARM64
or ARM64EC object, depending on the context. Such objects can be
produced with cvtres.exe -machine:arm64x.

Reviewed By: efriedma

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

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

Revert D139098 "[Alignment] Use Align for ObjectFile::getSectionAlignment"

This breaks lld.

This reverts commit 10c47465e2505ddfee4e62a2ab2e535abea3ec56.

[Alignment] Use Align for ObjectFile::getSectionAlignment

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

[ARM64EC 1/?] Add parsing support to llvm-objdump/llvm-readobj.

This is the first patch of a patchset to add initial support for
ARM64EC. Basic documentation is available at
https://docs.microsoft.c

[ARM64EC 1/?] Add parsing support to llvm-objdump/llvm-readobj.

This is the first patch of a patchset to add initial support for
ARM64EC. Basic documentation is available at
https://docs.microsoft.com/en-us/windows/uwp/porting/arm64ec-abi .
(Discourse post:
https://discourse.llvm.org/t/initial-patches-for-arm64ec-windows-11-now-posted/62449
.)

The file format for ARM64EC is basically identical to normal ARM64.
There are a few extra sections, but the existing code for reading ARM64
object files just works.

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

show more ...

[Object][COFF] Improve section name parsing

Inspired by discussions on D127369, we probably can further improve LLVM's COFF
section name parsing. Hopefully, this makes the logic simpler and handles

[Object][COFF] Improve section name parsing

Inspired by discussions on D127369, we probably can further improve LLVM's COFF
section name parsing. Hopefully, this makes the logic simpler and handles some
edge cases more elegantly.

Reviewed By: rnk

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

show more ...

[COFF] Don't reject executables with data directories pointing outside of provided data

Before bb94611d6545c2c5271f5bb01de1aa4228a37250, we didn't check
that the sections in the COFF executable actu

[COFF] Don't reject executables with data directories pointing outside of provided data

Before bb94611d6545c2c5271f5bb01de1aa4228a37250, we didn't check
that the sections in the COFF executable actually contained enough
raw data, when looking up what section contains tables pointed to
by the data directories.

That commit added checking, to avoid setting a pointer that points
out of bounds - by rejecting such executables.

It turns out that some binaries (e.g.g a "helper.exe" provided by
NSIS) contains a base relocation table data directory that points
into the wrong section. It points inside the virtual address space
allocated for that section, but the section contains much less raw
data, and the table points outside of the provided raw data.

No longer reject such binaries (to let tools operate on them and
inspect them), but don't set the table pointers (so that when
printing e.g. base relocations, we don't print anything).

This should fix the regression pointed out in
https://reviews.llvm.org/D126898#3565834.

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

show more ...

[Object][COFF] Fix section name parsing error when the name field is not null-padded

Some object files produced by Mirosoft tools contain sections whose name field
is not fully null-padded at the en

[Object][COFF] Fix section name parsing error when the name field is not null-padded

Some object files produced by Mirosoft tools contain sections whose name field
is not fully null-padded at the end. Microsoft's dumpbin is able to print the
section name correctly, but this causes parsing errors with LLVM tools.

So far, this issue only seems to happen when the section name is longer than 8
bytes. In this case, the section name field contains a slash (/) followed by the
offset into the string table, but the name field is not fully null-padded at the
end.

Reviewed By: mstorsjo

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

show more ...

[COFF] Fix -Wredundant-move