| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
- Added `IMAGE_DLL_CHARACTERISTICS_EX_CET_COMPAT_STRICT_MODE`
- Added
`IMAGE_DLL_CHARACTERISTICS_EX_CET_SET_CONTEXT_IP_VALIDATION_RELAXED_MODE`
- Added
`IMAGE_DLL_CHARACTERISTICS_EX_CET_DYNAMIC_APIS_ALLOW_IN_PROC_ONLY`
- Added `IMAGE_DLL_CHARACTERISTICS_EX_CET_RESERVED_1`
- Added `IMAGE_DLL_CHARACTERISTICS_EX_CET_RESERVED_2`
- Added `IMAGE_DLL_CHARACTERISTICS_EX_FORWARD_CFI_COMPAT`
- Added `IMAGE_DLL_CHARACTERISTICS_EX_HOTPATCH_COMPATIBLE`
|
|
|
|
|
|
|
|
(#97229)
|
|
## Consistent PDB GUID in `llvm-readobj`
Currently, the PDB GUID is shown as a byte array:
`PDBGUID: (D8 4C 88 D9 26 15 1F 11 4C 4C 44 20 50 44 42 2E)`
This is inconsistent with `llvm-pdbutil` (e.g. `llvm-pdbutil dump
--summary`) which shows it as a hexadecimal string.
Additionally, `yaml2obj` uses the same hexadecimal string format.
In general, the hexadecimal string is the common representation for PDB
GUIDs on Windows.
This PR changes it to be consistent as shown below:
`PDBGUID: {D9884CD8-1526-111F-4C4C-44205044422E}`
|
|
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.
|
|
This change removes an unnecessary branch from a hot path. It's also
questionable API to override any previous error unconditonally.
|
|
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}.
|
|
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}.
|
|
GNU readelf introduced --extra-sym-info/-X to display the section name
for --syms (https://sourceware.org/PR30684). Port the feature, which is
currently llvm-readelf only.
For STO_AARCH64_VARIANT_PCS/STO_RISCV_VARIANT_PCS, the Ndx and Name
columns may not be aligned.
|
|
Reviewed By: jhenderson, MaskRay
Differential Revision: https://reviews.llvm.org/D156797
|
|
GCC doesn't like the implicit conversion here.
|
|
Fixes EHCont implementation in LLD. Closes #64570
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D157623
|
|
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
|
|
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
|
|
|
|
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
|
|
Differential Revision:https://reviews.llvm.org/D140555
|
|
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
|
std::size, introduced in C++17, allows us to directly obtain the
number of elements of an array.
|
|
Solve two issues that showed up when using LLD with Unreal Engine & FASTBuild:
1. It seems the S_OBJNAME record doesn't always record the "precomp signature". We were relying on that to match the PCH.OBJ with their dependent-OBJ.
2. MSVC link.exe is able to link a PCH.OBJ when the "precomp signatureÈ doesn't match, but LLD was failing. This was occuring since the Unreal Engine Build Tool was compiling the PCH.OBJ, but the dependent-OBJ were compiled & cached through FASTBuild. Upon a clean rebuild, the PCH.OBJs were recompiled by the Unreal Build Tool, thus the "precomp signatures" were changing; however the OBJs were already cached by FASTBuild, thus having an old "precomp signatures".
We now ignore "precomp signatures" and properly fallback to cmd-line name lookup, like MSVC link.exe does, and only fail if the PCH.OBJ type stream doesn't match the count expected by the dependent-OBJ.
Differential Revision: https://reviews.llvm.org/D136762
|
|
Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D134528
|
|
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
|
|
This also modifies llvm-readobj to be more future-proof when printing
the guard FIDs table by calculating the entry size correctly according
to MS docs.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D132924
|
|
Print flags as documented in MS docs.
https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#load-configuration-layout
https://docs.microsoft.com/en-us/windows/win32/secbp/pe-metadata
EH_CONTINUATION_TABLE_PRESENT is not mentioned in the docs but is
instead taken from Windows SDK headers.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D132823
|
|
|
|
|
|
Identified with modernize-use-nullptr.
|
|
const'. NFC
By default, such a non-template variable of non-volatile const-qualified type
having namespace-scope has internal linkage ([basic.link]), so no need for `static`.
|
|
Allow variable number of directories, as allowed by the
specification. NumberOfRvaAndSize will default to 16 if not specified,
as in the past.
Reviewed by: jhenderson
Differential Revision: https://reviews.llvm.org/D108825
|
|
future-proof against C++23
C++23 will make these conversions ambiguous - so fix them to make the
codebase forward-compatible with C++23 (& a follow-up change I've made
will make this ambiguous/invalid even in <C++23 so we don't regress
this & it generally improves the code anyway)
|
|
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D99078
|
|
|
|
|
|
This moves the `reportUniqueWarning` method to the base class.
My motivation is the following:
I've experimented with replacing `reportWarning` calls with `reportUniqueWarning`
in ELF dumper. I've found that for example for removing them from `DynRegionInfo` helper
class, it is worth to pass a dumper instance to it (to be able to call dumper()->reportUniqueWarning()).
The problem was that `ELFDumper<ELFT>` is a template class. I had to make `DynRegionInfo` to be templated
and do lots of minor changes everywhere what did not look reasonable/nice.
At the same time I guess one day other dumpers like COFF/MachO/Wasm etc might want to
start using `reportUniqueWarning` API too. Then it looks reasonable to move the logic to the
base class.
With that the problem of passing the dumper instance will be gone.
Differential revision: https://reviews.llvm.org/D92218
|
|
This patch adds support for creating Guard Address-Taken IAT Entry Tables (.giats$y sections) in object files, matching the behavior of MSVC. These contain lists of address-taken imported functions, which are used by the linker to create the final GIATS table.
Additionally, if any DLLs are delay-loaded, the linker must look through the .giats tables and add the respective load thunks of address-taken imports to the GFIDS table, as these are also valid call targets.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D87544
|
|
This broke both Firefox and Chromium (PR47905) due to what seems like dllimport
function not being handled correctly.
> This patch adds support for creating Guard Address-Taken IAT Entry Tables (.giats$y sections) in object files, matching the behavior of MSVC. These contain lists of address-taken imported functions, which are used by the linker to create the final GIATS table.
> Additionally, if any DLLs are delay-loaded, the linker must look through the .giats tables and add the respective load thunks of address-taken imports to the GFIDS table, as these are also valid call targets.
>
> Reviewed By: rnk
>
> Differential Revision: https://reviews.llvm.org/D87544
This reverts commit cfd8481da1adba1952e0f6ecd00440986e49a946.
|
|
This patch adds support for creating Guard Address-Taken IAT Entry Tables (.giats$y sections) in object files, matching the behavior of MSVC. These contain lists of address-taken imported functions, which are used by the linker to create the final GIATS table.
Additionally, if any DLLs are delay-loaded, the linker must look through the .giats tables and add the respective load thunks of address-taken imports to the GFIDS table, as these are also valid call targets.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D87544
|
|
Akin to dumpbin's /TLS option, this will print out the TLS directory, if
present, in the image.
Example output:
```
> llvm-readobj --coff-tls-directory test.exe
File: test.exe
Format: COFF-x86-64
Arch: x86_64
AddressSize: 64bit
TLSDirectory {
StartAddressOfRawData: 0x140004000
EndAddressOfRawData: 0x140004040
AddressOfIndex: 0x140002000
AddressOfCallBacks: 0x0
SizeOfZeroFill: 0x0
Characteristics [ (0x0)
]
}
```
Reviewed By: jhenderson, grimar
Differential Revision: https://reviews.llvm.org/D88635
|
|
This reverts commit ef4e971e5e18ae796466623df8f26265ba6bdfb5.
|
|
This patch adds support for creating Guard Address-Taken IAT Entry Tables (.giats$y sections) in object files, matching the behavior of MSVC. These contain lists of address-taken imported functions, which are used by the linker to create the final GIATS table.
Additionally, if any DLLs are delay-loaded, the linker must look through the .giats tables and add the respective load thunks of address-taken imports to the GFIDS table, as these are also valid call targets.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D87544
|
|
We have Error.cpp/.h which contains some code for working with error codes.
In fact we use Error/Expected<> almost everywhere already and we can get rid
of these files.
Note: a few places in the code used readobj specific error codes,
e.g. `return readobj_error::unknown_symbol`. But these codes are never really used,
i.e. the code checks the fact of a success/error call only.
So I've changes them to `return inconvertibleErrorCode()` for now.
It seems that these places probably should be converted to use `Error`/`Expected<>`.
Differential revision: https://reviews.llvm.org/D86772
|
|
We have a few helper functions like the following:
```
std::error_code create*Dumper(...)
```
In fact we do not need or want to use `std::error_code` and the code
can be simpler if we just return `std::unique_ptr<ObjDumper>`.
This patch does this change and refines the signature of `createDumper`
as well.
Differential revision: https://reviews.llvm.org/D86718
|
|
Currently, we only test the `--stackmap` option here:
https://github.com/llvm/llvm-project/blob/master/llvm/test/Object/stackmap-dump.test
it uses a precompiled MachO binary currently and I've found no tests for this option for ELF.
The implementation also has issues. For example, it might assert on a wrong version
of the .llvm-stackmaps section. Or it might crash on an empty or truncated section.
This patch introduces a new tools/llvm-readobj/ELF test file as well as implements a few
basic checks to catch simple crashes/issues
It also eliminates `unwrapOrError` calls in `printStackMap()`.
Differential revision: https://reviews.llvm.org/D85208
|
|
Summary: Dumping contents of `.llvm.call-graph-profile` section of COFF in the same format as ELF.
Reviewers: jhenderson, MaskRay, hans
Reviewed By: jhenderson
Subscribers: grimar, rupprecht, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81894
|
|
This reverts commit 101fbc01382edd89ea7b671104c68b30b2446cc0.
Remove leftover debugging attribute.
Update LLDB as well, which was missed before.
|
|
This reverts commit b5289656b865d2a73cf90819e20a96fb8414ab0b.
__attribute__((optnone)) doesn't build with msvc, see
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/16326
|
|
|
|
I noticed that std::error_code() does one-time initialization. Avoid
that overhead with Expected<T> and llvm::Error. Also, it is consistent
with the virtual interface and ELF, and generally cleaner.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D79643
|
