Many sections either do not have a support of `Size`/`Content` or support just a
one of them, e.g only `Content`.
`Section` is the base class for sections. This patch adds `Content` and `Size` members
to it and removes similar members from derived classes. This allows to cleanup and
generalize the code and adds a support of these keys for all sections (`SHT_MIPS_ABIFLAGS`
is a only exception, it requires unrelated specific changes to be done).
I had to update/add many tests to test the new functionality properly.
Differential revision: https://reviews.llvm.org/D89039
(this doesn't cover all cases - libDebugInfoDWARF has a default error
handler that prints errors without any exit code handling - I'll be
following up with a patch for that after this)
dsymutil was incorrectly ignoring aliases to private extern symbols in
the MachODebugMapParser. This resulted in spurious warnings about not
being able to find symbols.
rdar://49652389
Differential revision: https://reviews.llvm.org/D89444
Summary:
This patch does the following:
1. Make InitTargetOptionsFromCodeGenFlags() accepts Triple as a
parameter, because some options' default value is triple dependant.
2. DataSections is turned on by default on AIX for llc.
3. Test cases change accordingly because of the default behaviour change.
4. Clang Driver passes in -fdata-sections by default on AIX.
Reviewed By: MaskRay, DiggerLin
Differential Revision: https://reviews.llvm.org/D88737
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
Adds more testing in basic-assembly.s and a new test tables.s.
Adds support to yaml reading and writing of tables as well.
Differential Revision: https://reviews.llvm.org/D88815
This diff is similar to what D71394 did for `llvm-objdump` -- it avoids
trying to look up a section name for STABS symbols, since some STABS
symbol types (like `N_OSO`) use the `n_sect` field to store other data
instead of a section index.
Differential Revision: https://reviews.llvm.org/D88468
If the metadata is valid yaml, we can print it, even if it failed
validation. That makes it easier to debug any wrong metadata.
Differential Revision: https://reviews.llvm.org/D89243
Specification for `SHT_HASH` table says (https://refspecs.linuxbase.org/elf/gabi4+/ch5.dynamic.html#hash)
that it contains `Elf32_Word` entries for both `32/64` bit objects.
But there is a problem with `EM_S390` and `ELF::EM_ALPHA` platforms: they use 8-bytes entries.
(see the issue reported: https://bugs.llvm.org/show_bug.cgi?id=47681).
Currently we might infer the size of the dynamic symbols table from hash table,
but because of the issue mentioned, the calculation is wrong. And also we don't dump the hash table
properly.
I am not sure if we want to support 8-bytes entries as they violates specification and also the
`.hash` table is kind of deprecated by itself (the `.gnu.hash` table is used nowadays).
So, the solution this patch suggests is to ban using of the hash table on `EM_S390/EM_ALPHA` platforms.
Differential revision: https://reviews.llvm.org/D88817
At AMD, in an internal audit of our code, we found some corner cases
where we were not quite differentiating targets enough for some old
hardware. This commit is part of fixing that by adding three new
targets:
* The "Oland" and "Hainan" variants of gfx601 are now split out into
gfx602. LLPC (in the GPUOpen driver) and other front-ends could use
that to avoid using the shaderZExport workaround on gfx602.
* One variant of gfx703 is now split out into gfx705. LLPC and other
front-ends could use that to avoid using the
shaderSpiCsRegAllocFragmentation workaround on gfx705.
* The "TongaPro" variant of gfx802 is now split out into gfx805.
TongaPro has a faster 64-bit shift than its former friends in gfx802,
and a subtarget feature could be set up for that to take advantage of
it. This commit does not make that change; it just adds the target.
V2: Add clang changes. Put TargetParser list in order.
V3: AMDGCNGPUs table in TargetParser.cpp needs to be in GPUKind order,
so fix the GPUKind order.
Differential Revision: https://reviews.llvm.org/D88916
Change-Id: Ia901a7157eb2f73ccd9f25dbacec38427312377d
This patch makes the opcode_base and the standard_opcode_lengths fields
of the line table optional. When both of them are not specified,
yaml2obj emits them according to the line table's version.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D88355
It fixes possible scenarios when we crash/assert with `--hash-symbols` when
dumping an invalid GNU hash table which has a broken value in the buckets array.
This fixes a crash reported in comments for
https://bugs.llvm.org/show_bug.cgi?id=47681
Differential revision: https://reviews.llvm.org/D88561
This removes "VerifyEachPass" parameters from a lot of functions which is nice.
Don't verify after special passes or VerifierPass.
This introduces verification on loop and cgscc passes, verifying the corresponding function/module.
Reviewed By: ychen
Differential Revision: https://reviews.llvm.org/D88764
The `Group` class represents a group section and it is
named inconsistently with other sections which all has
the "Section" suffix. It is sometimes confusing,
this patch addresses the issue.
Differential revision: https://reviews.llvm.org/D88892
We have `--addrsig` implemented for `llvm-readobj`.
Usually it is convenient to use a single tool for dumping,
so it seems we might want to implement `--addrsig` for `llvm-readelf` too.
I've selected a simple output format which is a bit similar to one,
used for dumping of the symbol table. It looks like:
```
Address-significant symbols section '.llvm_addrsig' contains 2 entries:
Num: Name
1: foo
2: bar
```
Differential revision: https://reviews.llvm.org/D88835
This diff adds support for universal binaries to llvm-objcopy.
This is a recommit of 32c8435ef7 with the asan issue fixed.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D88400
Rename the DwarfFile class in DWARFLinker to DWARFFile. This is
consistent with the other DWARF classes and avoids a ODR violation with
the DwarfFile class in AsmPrinter.
Remove usages of special error reporting functions(error(),
reportError()). Errors are reported as Expected<>/Error returning
values. This part is for ELF subfolder of llvm-objcopy.
Testing: check-all.
Differential Revision: https://reviews.llvm.org/D87987
Some targets have different defaults. This patch defers initialization of `TargetOptions` so that a future patch can pass `TargetOptions` to `InitTargetOptionsFromCodeGenFlags`
Reviewed By: jasonliu
Differential Revision: https://reviews.llvm.org/D88748
Specification for SHT_HASH table says (https://refspecs.linuxbase.org/elf/gabi4+/ch5.dynamic.html#hash)
that it contains Elf32_Word entries for both 32/64 bit objects.
Currently both GNU linkers and LLD sets the `sh_entsize` field to `4`.
At the same time, `yaml2obj` ignores the `EntSize` field for SHT_HASH sections.
This patch fixes this and also adds a support for obj2yaml: it will not
dump this field when the `sh_entsize` contains the default value (`4`).
Differential revision: https://reviews.llvm.org/D88652
This is mostly for the benefit of the LBR latency mode.
Right now, it performs no checking. If this is run on non-supported hardware, it will produce all zeroes for latency.
Differential Revision: https://reviews.llvm.org/D85254
New change: Updated lit.local.cfg to use pass the right argument to llvm-exegesis to actually request the LBR mode.
Differential Revision: https://reviews.llvm.org/D88670
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 4fcd1a8e65 as
`llvm/test/tools/llvm-exegesis/X86/lbr/mov-add.s` failed on hosts
without LBR supported if the build has LIBPFM enabled. On that host,
`perf_event_open` fails with `EOPNOTSUPP` on LBR config. That change's
basic assumption
> If this is run on a non-supported hardware, it will produce all zeroes for latency.
could not stand as `perf_event_open` system call will fail if the
underlying hardware really don't have LBR supported.
The patch adds a new TargetMachine member "registerPassBuilderCallbacks" for targets to add passes to the pass pipeline using the New Pass Manager (similar to adjustPassManager for the Legacy Pass Manager).
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D88138
This is mostly for the benefit of the LBR latency mode.
Right now, it performs no checking. If this is run on non-supported hardware, it will produce all zeroes for latency.
Differential Revision: https://reviews.llvm.org/D85254
This is the one more patch for https://bugs.llvm.org/show_bug.cgi?id=47581
It fixes how we print an information for the Generic model. With this patch
we are able to read values from `.ARM.extab` and dump proper personality routines names/addresses.
Differential revision: https://reviews.llvm.org/D88478
- Fix a memory leak accidentally introduced yesterday by using CodeGen's
existing mangling context instead of creating a new context afresh.
- Move GNU-runtime ObjC method mangling into the AST mangler; this will
eventually be necessary to support direct methods there, but is also
just the right architecture.
- Make the Apple-runtime method mangling work properly when given an
interface declaration, fixing a bug (which had solidified into a test)
where mangling a category method from the interface could cause it to
be mangled as if the category name was a class name. (Category names
are namespaced within their class and have no global meaning.)
- Fix a code cross-reference in dsymutil.
Based on a patch by Ellis Hoag.
@feat.00 is a bitfield read by Microsoft-style linkers, and is required to signal (e.g.) /safeseh support on 32-bit systems.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D88451
Add support for .radix directive, and radix specifiers [yY] (binary), [oOqQ] (octal), and [tT] (decimal).
Also, when lexing MASM integers, require radix specifier; MASM requires that all literals without a radix specifier be treated as in the default radix. (e.g., 0100 = 100)
Relanding D87400, now with fewer ms-inline-asm tests broken!
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D88337
This is a part of https://bugs.llvm.org/show_bug.cgi?id=47581.
We have the following computation:
```
(1) uint64_t Location = Address & 0x7fffffff;
(2) if (Location & 0x04000000)
(3) Location |= (uint64_t) ~0x7fffffff;
(4) return Location + Place;
```
At line 2 there is a mistype. The constant should be `0x40000000`,
not `0x04000000`, because the intention here is to sign extend the `Location`,
which is the 31 bit signed value.
Differential revision: https://reviews.llvm.org/D88407
Currently we are always recognizing the `SHT_MIPS_ABIFLAGS` section,
even on non-MIPS targets.
The problem of doing this is briefly discussed in D88228 which does the same for `SHT_ARM_EXIDX`:
"The problem is that `SHT_ARM_EXIDX` shares the value with `SHT_X86_64_UNWIND (0x70000001U)`.
We might have other machine specific conflicts, e.g.
`SHT_ARM_ATTRIBUTES` vs `SHT_MSP430_ATTRIBUTES` vs `SHT_RISCV_ATTRIBUTES (0x70000003U)`."
I think we should only recognize target specific sections when the machine type
matches. I.e. `SHT_MIPS_*` should be recognized only on `MIPS`, `SHT_ARM_*`
only on `ARM` etc.
This patch stops recognizing `SHT_MIPS_ABIFLAGS` on `non-MIPS` targets.
Note: I had to update `ScalarEnumerationTraits<ELFYAML::MIPS_ISA>::enumeration`, because
otherwise test crashes, calling `llvm_unreachable`.
Differential revision: https://reviews.llvm.org/D88294
Remove usages of special error reporting functions(error(),
reportError()). This patch is extracted from D87987.
Errors are reported as Expected<>/Error returning values.
This part is for COFF subfolder of llvm-objcopy.
Testing: check-all.
Differential Revision: https://reviews.llvm.org/D88213
It is not a good idea to expose raw constants in the LLVM C API. Replace this with an explicit getter.
Differential Revision: https://reviews.llvm.org/D88367
This patch performs a minor cleanup of the class Slice:
static methods and constructors which take a pointer but assume that
it's not null now take the argument by reference.
NFC.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D88320
This commit fixes a regression (from LLVM 10 to LLVM 11 RC3) in the LLVM
C API.
Previously, commit 1ee6ec2bf removed the mask operand from the
ShuffleVector instruction, storing the mask data separately in the
instruction instead; this reduced the number of operands of
ShuffleVector from 3 to 2. AFAICT, this change unintentionally caused
a regression in the LLVM C API. Specifically, it is no longer possible
to get the mask of a ShuffleVector instruction through the C API. This
patch introduces new functions which together allow a C API user to get
the mask of a ShuffleVector instruction, restoring the functionality
which was previously available through LLVMGetOperand().
This patch also adds tests for this change to the llvm-c-test
executable, which involved adding support for InsertElement,
ExtractElement, and ShuffleVector itself (as well as constant vectors)
to echo.cpp. Previously, vector operations weren't tested at all in
echo.ll.
I also fixed some typos in comments and help-text nearby these changes,
which I happened to spot while developing this patch. Since the typo
fixes are technically unrelated other than being in the same files, I'm
happy to take them out if you'd rather they not be included in the patch.
Differential Revision: https://reviews.llvm.org/D88190
This is a similarity visualization tool that accepts a Module and
passes it to the IRSimilarityIdentifier. The resulting SimilarityGroups
are output in a JSON file.
Tests are found in test/tools/llvm-sim and check for the file not found,
a bad module, and that the JSON is created correctly.
Reviewers: paquette, jroelofs
Differential Revision: https://reviews.llvm.org/D86974
Remove usages of special error reporting functions(error(),
reportError()). This patch is extracted from D87987.
Errors are reported as Expected<>/Error returning values.
This part is for MachO subfolder of llvm-objcopy.
Testing: check-all.
Reviewed By: jhenderson, alexshap
Differential Revision: https://reviews.llvm.org/D88113
This is the first patch for https://bugs.llvm.org/show_bug.cgi?id=47581.
Currently -u does not compute function addresses correctly and
dumps broken addresses for non-relocatable objects.
ARM spec says:
"An index table entry consists of 2 words.
The first word contains a prel31 offset (see Relocations) to the start of a function, with bit 31 clear."
...
"The relocated 31 bits form a place-relative signed offset to the referenced entity.
For brevity, this document will refer to the results of these relocations as "prel31 offsets"."
(https://developer.arm.com/documentation/ihi0038/c/?lang=en#index-table-entries)
(https://developer.arm.com/documentation/ihi0038/c/?lang=en#relocations)
Currently we use an address of the SHT_ARM_EXIDX section instead of an address of an entry
in computations. As a result we compute an offset that is not really "place-relative",
but section relative, what is wrong.
The patch fixes this issue.
Differential revision: https://reviews.llvm.org/D88076
In a post review comments for D88097 it was mentioned that code
triggers bunch of warnings of the form:
llvm/tools/llvm-readobj/ELFDumper.cpp:5299:28: warning: loop variable 'Note' is always a copy because
the range of type 'iterator_range<llvm::object::ELFFile<llvm::object::ELFType<llvm::support::big, true> >::Elf_Note_Iterator>'
(aka 'iterator_range<Elf_Note_Iterator_Impl<ELFType<(llvm::support::endianness)0U, true> > >') does not return a reference [-Wrange-loop-analysis]
for (const Elf_Note &Note : this->Obj.notes(P, Err))
It happens because Elf_Note is always copied here:
Elf_Note_Impl<ELFT> operator*() const {
assert(Nhdr && "dereferenced ELF note end iterator");
return Elf_Note_Impl<ELFT>(*Nhdr);
}
This patch fixes the issue by removing a reference.
This diff fixes --add-section functionality and simplifies the tests organization.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D87497
This patch makes the 'ExtLen' field of extended opcodes optional. We
don't need to manually calculate it in the future.
Reviewed By: jhenderson, MaskRay
Differential Revision: https://reviews.llvm.org/D88136
This is in preparation for supporting -debugify-each, which adds a debug
info pass before and after each pass.
Switch VerifyEach to use this.
Reviewed By: ychen
Differential Revision: https://reviews.llvm.org/D88107
Recent refactoring introduced a symbol index argument for `getFullSymbolName` method,
which is only used for reporting error messages about invalid extended symbol indexes.
There are few issues in the implementation and we don't report correct symbol indices
when dumping MIPS GOT/PLT entries currently.
This patch adds test cases and fixes the issue.
Differential revision: https://reviews.llvm.org/D88089
Currently `--relocations` ignores section symbol names and always prints
section names for them. This is inconsistent with GNU readelf and with `--symbols`.
We have a code in `getFullSymbolName` (which is used for `--symbols`) which can be
reused for `getRelocationTarget` (used for `--relocations`).
With that the issue described is fixed and code becomes a bit shorter.
Also with this change we start to print more relocations (in situations when we just
showed warnings instead before) and also start to report more diagnostic warnings
(see reloc-zero-name-or-value.test).
Differential revision: https://reviews.llvm.org/D87613
This:
1) Replaces pointers with references in many places.
2) Adds few TODOs about fixing possible unhandled errors (in ARMEHABIPrinter.h).
3) Replaces `auto`s with actual types.
4) Removes excessive arguments.
5) Adds `const ELFFile<ELFT> &Obj;` member to `ELFDumper` to simplify the code.
Differential revision: https://reviews.llvm.org/D88097
We have an issue with `getFullSymbolName`: it assumes that the symbol passed is
always in the `.symtab`, what is wrong. We might calculate and report a wrong index currently.
I've added a test case revealing that.
This patch adds the "symbol index" argument to `getFullSymbolName` signature,
what fixes the issue.
Differential revision: https://reviews.llvm.org/D87899
We use `FirstSym` argument in `getExtendedSymbolTableIndex` to calculate
a symbol index:
```
&Sym - &FirstSym
```
Instead, we could pass the symbol index directly.
This is what this patch does, it allows to simplify another llvm-readobj API.
Differential revision: https://reviews.llvm.org/D88016
We have an issue with `ELFDumper<ELFT>::getSymbolSectionName`:
1) It is used deeply for both LLVM/GNU styles and might return LLVM-style only
values to describe symbols: "Undefined", "Processor Specific", "Absolute", etc.
2) `getSymbolSectionName` is used by `getFullSymbolName` and these special values
might appear instead of symbol names in many places.
This occurs for unnamed section symbols currently.
This patch extracts the LLVM specific logic to `LLVMStyle<ELFT>::printSymbolSection`,
which seems to be the only place where we want to print the special values mentioned.
It also adds a meaningful new warning that is reported when we are unable to get
a section index for a section symbol.
Differential revision: https://reviews.llvm.org/D87764
llvm-profdata `show` and `overlap` will crash in `getFuncName` on compact binary profile. This change fixed this by switching to use `getName`.
`getFuncName` is misused in llvm-profdata. As showed below, `GUIDToFuncNameMap` is only supported in compilation mode, there is no initialization in llvm-profdata. Compact profile whose MD5 is true would try to query `GUIDToFuncNameMap` then caused the crash. So fix this by switching to `getName`
Reviewed By: MaskRay, wmi, wenlei, weihe, hoy
Differential Revision: https://reviews.llvm.org/D87740
A build on `sparcv9-sun-solaris2.11` with `-DLLVM_ENABLE_PIC=Off` failed
linking `libRemarks.so`:
[27/2297] Linking CXX shared library lib/libRemarks.so.12git
FAILED: lib/libRemarks.so.12git
[...]
ld: fatal: relocation error: R_SPARC_H44: file lib/libLLVMRemarks.a(Remark.cpp.o): symbol _ZTVN4llvm18raw_string_ostreamE: invalid shared object relocation type: ABS44 code model unsupported
[...]
On Solaris/sparcv9 as on many other targets you cannot link non-PIC objects
into a shared object.
The following patch avoids this by not building the library with PIC. It
allowed the build to complete and `ninja check-all` showed no errors.
Differential Revision: https://reviews.llvm.org/D85626
This diff adds llvm-bitcode-strip driver to llvm-objcopy.
In the future this will enable us to build a replacement for the tool bitcode_strip.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D87212
The code which validates the value of -id is moved into the function parseInstallNameToolOptions.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D87855
Currently, -object takes a comma separated list of objects as an
argument, which prevents it working with path names that contain a
comma. Drop comma-separated support, which requires to set pass the
-object flag multiple times to set multiple objects.
Patch by Andrew Gallagher!
Differential Revision: https://reviews.llvm.org/D87003
When ELF header's `e_machine == 0`, we emit:
```
Machine: EM_NONE
```
We can avoid doing this, because yaml2obj sets the
`e_machine` field to `EM_NONE` by default.
Differential revision: https://reviews.llvm.org/D87829
Without this patch, obj2yaml decodes the content of only one ".stack_size" section. Other sections are dumped with their full contents.
Reviewed By: grimar, MaskRay
Differential Revision: https://reviews.llvm.org/D87727
Without this patch, obj2yaml decodes the content of only one ".stack_size" section. Other sections are dumped with their full contents.
Reviewed By: grimar, MaskRay
Differential Revision: https://reviews.llvm.org/D87727
'require<globals-aa>' is needed to make globals-aa work in NPM, since
globals-aa is a module analysis but function passes cannot run module
analyses on demand.
So don't skip translating alias analyses to 'require<>'.
Reviewed By: asbirlea
Differential Revision: https://reviews.llvm.org/D87743
This patch adds support for dumping the .debug_addr(v5) section to
obj2yaml.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D87601
This matches how such options are most commonly defined in other tools.
This was pointed out in an earlier review a few months ago, that
the llvm-rc td entries felt shouty.
The INCLUDE option is renamed to includepath, to avoid clashing with
the tablegen include directive.
Bugpoint has lots of assumptions and hacks around the legacy PM, put off migrating it to NPM until later.
Fixes tests under BugPoint under NPM.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D87655
Currently we might derive the dynamic symbol table size from the DT_HASH hash table (using its `nchain` field).
It is possible to crash dumpers with a broken relocation that refers to a symbol with an index
that is too large. To trigger it, the inferred size of the dynamic symbol table should go past the end of the object.
This patch adds a size validation + warning.
Differential revision: https://reviews.llvm.org/D86923
Our implementation of stack sizes section dumping heavily uses `ELFObjectFile<ELFT>`,
while the rest of the code uses `ELFFile<ELFT>`.
That APIs are very different. `ELFObjectFile<ELFT>` is very generic
and has `SectionRef`, `RelocationRef`, `SymbolRef` and other generic concepts.
The `ELFFile<ELFT>` class works directly with `Elf_Shdr`, `Elf_Rel[a]`, `Elf_Sym` etc,
what is probably much cleaner for ELF dumper.
Also, `ELFObjectFile<ELFT>` API does not always provide a way to check
for possible errors. E.g. the implementation of `symbol_end()` does not verify the `sh_size`:
```
template <class ELFT>
basic_symbol_iterator ELFObjectFile<ELFT>::symbol_end() const {
const Elf_Shdr *SymTab = DotSymtabSec;
if (!SymTab)
return symbol_begin();
DataRefImpl Sym = toDRI(SymTab, SymTab->sh_size / sizeof(Elf_Sym));
return basic_symbol_iterator(SymbolRef(Sym, this));
}
```
There are many other examples which makes me thing we might win from
switching to `ELFFile<ELFT>` API, where we heavily validate an input data already.
This patch is the first step in this direction. I've converted the large portion of the code
to use `ELFFile<ELFT>`.
Differential revision: https://reviews.llvm.org/D87362
`ELFFile<ELFT>` has many methods that take pointers,
though they assume that arguments are never null and
hence could take references instead.
This patch performs such clean-up.
Differential revision: https://reviews.llvm.org/D87385
In addition to printing the individual fields, synthesize and
print the corresponding prolog for the unwind info (in reverse
order, to match how it's printed for non-packed unwind info).
Differential Revision: https://reviews.llvm.org/D87370
This changes messages reported to stop using dynamic section names (use `describe()` instead).
This allows to avoid `unwrapOrError` and improves diagnostics.
Differential revision: https://reviews.llvm.org/D87503
It has following issues:
1) `getStaticSymbolName` returns `std::string`, but the code
assigns a result to `Expected<std::string>`.
2) The code uses `unwrapOrError` and never tests the error reported.
This patch fixes these issues.
Differential revision: https://reviews.llvm.org/D87507
There is some code that can be shared between GNU/LLVM styles.
Also, this fixes 2 inconsistencies related to dumping unknown note types:
1) For GNU style we printed "Unknown note type: (0x00000003)" in some cases, and
"Unknown note type (0x00000003)" (no colon) in other cases.
GNU readelf always prints `:`. This patch removes the related code
duplication and does the same.
2) For LLVM style in some cases we printed "Unknown note type (0x00000003)",
but sometimes just "Unknown (0x00000003)". The latter is the right form, which
is consistent with other unknowns that are printed in LLVM style.
Rebased on top of D87453.
Differential revision: https://reviews.llvm.org/D87454
The current organization of FileInfo and its referenced utility functions of
(GCOVFile, GCOVFunction, GCOVBlock) is messy. Some members of FileInfo are just
copied from GCOVFile. FileInfo::print (.gcov output and --intermediate output)
is interleaved with branch statistics and computation of line execution counts.
--intermediate has to do redundant .gcov output to gather branch statistics.
This patch deletes lots of code and introduces a clearer work flow:
```
fn collectFunction
for each block b
for each line lineNum
let line be LineInfo of the file on lineNum
line.exists = 1
increment function's lines & linesExec if necessary
increment line.count
line.blocks.push_back(&b)
fn collectSourceLine
compute cycle counts
count = incoming_counts + cycle_counts
if line.exists
++summary->lines
if line.count
++summary->linesExec
fn collectSource
for each line
call collectSourceLine
fn main
for each function
call collectFunction
print function summary
for each source file
call collectSource
print file summary
annotate the source file with line execution counts
if -i
print intermediate file
```
The output order of functions and files now follows the original order in
.gcno files.
In MinGW world, UNIX like lib prefix is preferred for the libraries.
This patch adjusts CMake files to do that.
Differential Revision: https://reviews.llvm.org/D87517
This patch adds support for dumping the .debug_ranges section to
elf2yaml.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D87429
This matches how e.g. stp/ldp and other opcodes are printed differently
for epilogues.
Also add a missing --strict-whitespace in an existing test that
was added explicitly for testing vertical alignment, and change to
using temp files for the generated object files.
Differential Revision: https://reviews.llvm.org/D87363
This diff adds -V alias for --version to make llvm-install-name-tool
consistent with other tools (llvm-objcopy, llvm-strip, etc).
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D87264
If the debug section's name isn't recognized, it should be
dumped as a raw content section.
Reviewed By: jhenderson, grimar
Differential Revision: https://reviews.llvm.org/D87346
This patch makes the debug_ranges section optional. When we specify an
empty debug_ranges section, yaml2obj only emits the section header.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D87263
LLVM style code can be simplified to avoid the duplication of logic
related to printing dynamic relocations.
Differential revision: https://reviews.llvm.org/D87089
Currently we have 2 large `printDynamicRelocations` methods that
have a very similar code for GNU/LLVM styles.
This patch removes the duplication and renames them to `printDynamicReloc`
for consistency.
Differential revision: https://reviews.llvm.org/D87087
It removes templating for Elf_Rel[a] handling that we
introduced earlier and introduces a helper class instead.
It was briefly discussed in D87087, which showed,
why having templates is probably not ideal for the generalization
of dumpers code.
Differential revision: https://reviews.llvm.org/D87141
TPCDynamicLibrarySearchGenerator was generating errors on missing
symbols, but that doesn't fit the DefinitionGenerator contract: A symbol
that isn't generated by a particular generator should not cause an
error.
This commit fixes the error by using SymbolLookupFlags::WeaklyReferencedSymbol
for all elements of the lookup, and switches llvm-jitlink to use
TPCDynamicLibrarySearchGenerator.
I recently came across a MachO with multiple sections of the same name but
different segments. We should emit the segment name alongside the section name
for MachO's.
Differential Revision: https://reviews.llvm.org/D87119
We have the `RelSymbol<ELFT>` struct and can use it instead
of `std::pair<const Elf_Sym *, std::string>` in a few methods.
This is a bit cleaner.
Differential revision: https://reviews.llvm.org/D87092
Instead of referring to stack sizes sections only by name, we can add
section indexes and types to warnings reported.
Differential revision: https://reviews.llvm.org/D86934
We have 2 DumpStyles currently:
`class GNUStyle : public DumpStyle<ELFT>` and `class LLVMStyle : public DumpStyle<ELFT>`.
The problem of `DumpStyle` interface is that almost for each method
we provide `const ELFFile<ELFT> *` as argument. But in fact each of
dump styles keeps `ELFDumper<ELFT> *Dumper` which can be used to get an object from.
But since we use the `Obj` too often, I've decided to introduce a one more reference member
instead of reading it from the `Dumper` each time:
`const ELFFile<ELFT> &Obj;` This is kind of similar to `FileName` member which we have already:
it is also used to store a the file name which can be read from `Dumper->getElfObject()->getFileName()`.
I had to adjust the code which previously worked with a pointer to an object
and now works with a reference.
In a follow-up I am going to try to get rid of `const ELFObjectFile<ELFT>` arguments
which are still passed to a set of functions.
Differential revision: https://reviews.llvm.org/D87040
Add support in llvm-readobj for displaying them and support in the
asm parsser, AArch64TargetStreamer and MCWin64EH for emitting them.
The directives for the remaining basic opcodes have names that
match the opcode in the documentation.
The directives for custom stack cases, that are named
MSFT_OP_TRAP_FRAME, MSFT_OP_MACHINE_FRAME, MSFT_OP_CONTEXT
and MSFT_OP_CLEAR_UNWOUND_TO_CALL, are given matching assembler
directive names that fit into the rest of the opcode naming;
.seh_trap_frame, .seh_context, .seh_clear_unwound_to_call
The opcode MSFT_OP_MACHINE_FRAME is mapped to the existing
opecode enum UOP_PushMachFrame that is used on x86_64, and also
uses the corresponding existing x86_64 directive name
.seh_pushframe.
Differential Revision: https://reviews.llvm.org/D86889
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
This replaces `reportError` calls with `reportUniqueWarning` and improves testing
for the code that is related to stack sizes dumping.
Differential revision: https://reviews.llvm.org/D86783
This patch makes the debug_str section optional. When the debug_str
section exists but doesn't contain anything, yaml2obj will emit a
section header for it.
Reviewed By: grimar
Differential Revision: https://reviews.llvm.org/D86860
Currently replaceBranchTerminator/removeUninterestingBBsFromSwitch
always creates `ret void` instructions if no successor is in the chunk.
This results in invalid IR for functions with non-void return types,
which makes those reductions unfeasible. Instead, create `ret ty undef`
for functions with non-void return types.
Reviewed By: lebedev.ri
Differential Revision: https://reviews.llvm.org/D86849
Imagine we have an archive that has 3 objects in the following order:
<valid known object>,<unknown object> and <valid known object>.
Currently llvm-readelf/obj report an error and stops dumping in the middle.
This patch changes the error reported to warning.
Differential revision: https://reviews.llvm.org/D86771
althought the interstingness test should usually fail when the module is invalid
this changes reduces the frequency at which llvm-reduce generate invalid IR.
Reviewed By: lebedev.ri
Differential Revision: https://reviews.llvm.org/D86404
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
Some reduction passes may create invalid IR. I am not aware of any use
case where we would like to proceed reducing invalid IR. Various utils
used here, including CloneModule, assume the module to clone is valid
and crash otherwise.
Ideally, no reduction pass would create invalid IR, but some currently
do. ReduceInstructions can be fixed relatively easily (D86210), but
others are harder. For example, ReduceBasicBlocks may remove result in
invalid PHI nodes.
For now, skip the chunks. If we get to the point where all reduction
passes result in valid IR, we may want to turn this into an assertion.
Reviewed By: lebedev.ri
Differential Revision: https://reviews.llvm.org/D86212
This patch optionally replaces the CRT allocator (i.e., malloc and free) with rpmalloc (mixed public domain licence/MIT licence) or snmalloc (MIT licence) or mimalloc (MIT licence). Please note that the source code for these allocators must be available outside of LLVM's tree.
To enable, use `cmake ... -DLLVM_INTEGRATED_CRT_ALLOC=D:/git/rpmalloc -DLLVM_USE_CRT_RELEASE=MT` where `D:/git/rpmalloc` has already been git clone'd from `https://github.com/mjansson/rpmalloc`. The same applies to snmalloc and mimalloc.
When enabled, the allocator will be embeded (statically linked) into the LLVM tools & libraries. This currently only works with the static CRT (/MT), although using the dynamic CRT (/MD) could potentially work as well in the future.
When enabled, this changes the memory stack from:
new/delete -> MS VC++ CRT malloc/free -> HeapAlloc -> VirtualAlloc
to:
new/delete -> {rpmalloc|snmalloc|mimalloc} -> VirtualAlloc
The goal of this patch is to bypass the application's global heap - which is thread-safe thus inducing locking - and instead take advantage of a modern lock-free, thread cache, allocator. On a 6-core Xeon Skylake we observe a 2.5x decrease in execution time when linking a large scale application with LLD and ThinLTO (12 min 20 sec -> 5 min 34 sec), when all hardware threads are being used (using LLD's flag /opt:lldltojobs=all). On a dual 36-core Xeon Skylake with all hardware threads used, we observe a 24x decrease in execution time (1 h 2 min -> 2 min 38 sec) when linking a large application with LLD and ThinLTO. Clang build times also see a decrease in the range 5-10% depending on the configuration.
Differential Revision: https://reviews.llvm.org/D71786
For `ld64` which uses legacy LTOCodeGenerator, it relies on
writeMergedModule to perform `ld -r` (generates a linked object file).
If all the inputs to `ld -r` is fullLTO bitcode, `ld64` will linked the
bitcode module, internalize all the symbols and write out another
fullLTO bitcode object file. This bitcode file doesn't have all the
bitcode inputs and it should not have LTOPostLink module flag. It will
also cause error when this bitcode object file is linked with other LTO
object file.
Fix the issue by not applying LTOPostLink flag during writeMergedModule
function. The flag should only be added when all the bitcode are linked
and ready to be optimized.
rdar://problem/58462798
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D84789
This patch makes the unit_length and header_length fields of line tables
optional. yaml2obj is able to infer them for us.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D86590
We have no tests for OS/ABI values specific to
EM_TI_C6000, ELFOSABI_AMDGPU_MESA3D and ELFOSABI_ARM machines.
Also, related arrays in the code are not grouped together.
(That is why such testing was missed I guess).
The patch fixes that all.
Differential revision: https://reviews.llvm.org/D86341
This removes Error.cpp/.h files from obj2yaml.
These files are not needed because we are
using `Error`s instead of error codes widely and do
not need a logic related to obj2yaml specific
error codes anymore.
I had to adjust just a few lines of tool's code
to remove remaining dependencies.
Differential revision: https://reviews.llvm.org/D86536
llvm-readobj crashes when `-S --section-symbols` is used
on an object that has no symbol table.
The patch fixes it.
Differential revision: https://reviews.llvm.org/D86520
A Mach-O universal binary may contain bitcode as a slice.
This diff adds proper handling of such binaries to llvm-lipo.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D85740
including printing them.
Reviewers: andreadb, lebedev.ri
Differential Review: https://reviews.llvm.org/D86390
Introduces a new base class "InstructionView" that such views derive from.
Other views still use the "View" base class.
Currently, when a program header type is unknown, we dont print anything:
```
ProgramHeader {
Type: (0x60000000)
```
With this patch the output will be:
```
ProgramHeader {
Type: Unknown (0x60000000)
```
It was discussed in D85526 and consistent with what we print for
'--sections' already, e.g.:
```
Section {
Name: .sec
Type: Unknown (0x7FFFFFFF)
}
```
Differential revision: https://reviews.llvm.org/D86213
This allows to get rid of "Invalid data was encountered while parsing the file"
error reported in cases when sh_size/sh_offset of sections are broken.
Differential revision: https://reviews.llvm.org/D86451
Fixes PR46575.
Bump statistics version to 6.
Without this patch, for a variable described with a location list the stat
'sum_all_variables(#bytes in parent scope covered by DW_AT_location)' is
calculated by summing all bytes covered by the location ranges in the list and
capping the result to the number of bytes in the parent scope. With the patch,
only bytes which overlap with the parent DIE scope address ranges contribute to
the stat. A new stat 'sum_all_variables(#bytes in any scope covered by
DW_AT_location)' has been added which displays the total bytes covered when
ignoring scopes.
The -V option in cctools' libtool prints out the version number and
performs any specified operation. Add this option to LLVM's version.
cctools is more forgiving of invalid command lines when -V is specified,
but I think it's better to give errors instead of silently producing no
output.
Unfortunately, when -V is present, options that would otherwise be
required aren't anymore, so we need to perform some manual argument
validation.
Reviewed By: alexshap
Differential Revision: https://reviews.llvm.org/D86359
Removing terminators will result in invalid IR, making further
reductions pointless. I do not think there is any valid use case where
we actually want to create invalid IR as part of a reduction.
Reviewed By: lebedev.ri
Differential Revision: https://reviews.llvm.org/D86210
so that the user does not have to pipe the output to `jq` or `python -m json.tool`.
This change makes testing more convenient because `-NEXT` patterns can be used.
The "prettify by default" is a good tradeoff to make. The output size increases a bit.
Differential Revision: https://reviews.llvm.org/D86318
This helps with both debugging llvm-reduce and sometimes getting usefull result even if llvm-reduce crashes
Reviewed By: lebedev.ri
Differential Revision: https://reviews.llvm.org/D85996
The legacy PM alias analysis pipeline by default includes basic-aa.
When running `opt -foo-pass` under the NPM and -disable-basic-aa is not
specified, use basic-aa.
This decreases the number of check-llvm failures under NPM from 913 to 752.
Reviewed By: ychen, asbirlea
Differential Revision: https://reviews.llvm.org/D86167
The code that reports "PT_DYNAMIC segment offset + size exceeds the size of the file"
has an issue: it is possible to bypass the validation by overflowing the size + offset result.
Differential revision: https://reviews.llvm.org/D85519
The original commit (7ff0ace96db9164dcde232c36cab6519ea4fce8) was causing
build failure and was reverted in 6d242a7326
==================== Original Commit Message ====================
This patch adds support for referencing different abbrev tables. We use
'ID' to distinguish abbrev tables and use 'AbbrevTableID' to explicitly
assign an abbrev table to compilation units.
The syntax is:
```
debug_abbrev:
- ID: 0
Table:
...
- ID: 1
Table:
...
debug_info:
- ...
AbbrevTableID: 1 ## Reference the second abbrev table.
- ...
AbbrevTableID: 0 ## Reference the first abbrev table.
```
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D83116
Currently we have `checkDRI` and two `createDRIFrom` methods which
are used to create `DynRegionInfo` objects.
And we have an issue: constructions like:
`ObjF->getELFFile()->base() + P->p_offset`
that are used in `createDRIFrom` functions might overflow.
I had to revert `D85519` which triggered such UBSan failure.
This NFC, simplifies and generalizes how we create `DynRegionInfo` objects.
It will allow us to introduce more/better validation checks in a single place.
It also will allow to change `createDRI` to return `Expected<>` so
that we will be able to stop using the `reportError`, which
is used inside currently, and have a warning instead.
Differential revision: https://reviews.llvm.org/D86297
This patch adds support for referencing different abbrev tables. We use
'ID' to distinguish abbrev tables and use 'AbbrevTableID' to explicitly
assign an abbrev table to compilation units.
The syntax is:
```
debug_abbrev:
- ID: 0
Table:
...
- ID: 1
Table:
...
debug_info:
- ...
AbbrevTableID: 1 ## Reference the second abbrev table.
- ...
AbbrevTableID: 0 ## Reference the first abbrev table.
```
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D83116
This patch adds support for emitting multiple abbrev tables. Currently,
compilation units will always reference the first abbrev table.
Reviewed By: jhenderson, labath
Differential Revision: https://reviews.llvm.org/D86194
Then it is trivial to make the output indented (the second parameter of
json::OStream::OStream specifies the indentation).
Reviewed By: jhenderson, echristo
Differential Revision: https://reviews.llvm.org/D86045
This reverts commit 455d5a8a06.
It broke UBSan:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-ubsan/builds/21386/steps/check-llvm%20ubsan/logs/stdio
/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/llvm/test/tools/llvm-readobj/ELF/malformed-pt-dynamic.test:62:10: error: WARN3: expected string not found in input
# WARN3: error: '[[FILE]]': Invalid data was encountered while parsing the file
^
<stdin>:2:1: note: scanning from here
/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/llvm/tools/llvm-readobj/ELFDumper.cpp:1956:46: runtime error: addition of unsigned offset to 0x0000020c5b30 overflowed to 0x0000020c5b2f
^
<stdin>:2:1: note: with "FILE" equal to "/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/test/tools/llvm-readobj/ELF/Output/malformed-pt-dynamic\\.test\\.tmp3"
/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/llvm/tools/llvm-readobj/ELFDumper.cpp:1956:46: runtime error: addition of unsigned offset to 0x0000020c5b30 overflowed to 0x0000020c5b2f
^
<stdin>:2:117: note: possible intended match here
/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/llvm/tools/llvm-readobj/ELFDumper.cpp:1956:46: runtime error: addition of unsigned offset to 0x0000020c5b30 overflowed to 0x0000020c5b2f
^
Input file: <stdin>
Check file: /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/llvm/test/tools/llvm-readobj/ELF/malformed-pt-dynamic.test
The code that reports "PT_DYNAMIC segment offset + size exceeds the size of the file"
has an issue: it is possible to bypass the validation by overflowing the size + offset result.
Differential revision: https://reviews.llvm.org/D85519
Currently we have to set 'Machine' to something in our
YAML descriptions. Usually we use 'EM_X86_64' for 64-bit targets
and 'EM_386' for 32-bit targets. At the same time, in fact, in most
cases our tests do not need a machine type and we can use
'EM_NONE'.
This is cleaner, because avoids the need of using a particular machine.
In this patch I've made the 'Machine' key optional (the default value,
when it is not specified is `EM_NONE`) and removed it (where possible)
from yaml2obj, obj2yaml and llvm-readobj tests.
There are few tests left where I decided not to remove it, because
I didn't want to touch CHECK lines or doing anything more complex
than a removing a "Machine: *" line and formatting lines around.
Differential revision: https://reviews.llvm.org/D86202
It's good to reuse the DWARF parser in lib/DebugInfo so that we don't
need to maintain a separate parser in client side (obj2yaml). Besides,
A test case is added whose length field is a very huge value which makes
obj2yaml stuck when parsing the section.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D86192
AMDGPU ISA isn't backwards compatible and hence -mcpu must always be specified during disassembly.
However, the AMDGPU target CPU is stored in e_flags in the ELF object.
This patch allows targets to implement CPU string detection, and also implements it for AMDGPU by looking at e_flags.
Reviewed By: scott.linder
Differential Revision: https://reviews.llvm.org/D84519
When diffing disassembly dump of two binaries, I see lots of noises from mismatched jump target addresses and global data references, which unnecessarily causes diffs on every function, making it impractical. I'm trying to symbolize the raw binary addresses to minimize the diff noise.
In this change, a local branch target is modeled as a label and the branch target operand will simply be printed as a label. Local labels are collected by a separate pre-decoding pass beforehand. A global data memory operand will be printed as a global symbol instead of the raw data address. Unfortunately, due to the way the disassembler is set up and to be less intrusive, a global symbol is always printed as the last operand of a memory access instruction. This is less than ideal but is probably acceptable from checking code quality point of view since on most targets an instruction can have at most one memory operand.
So far only the X86 disassemblers are supported.
Test Plan:
llvm-objdump -d --x86-asm-syntax=intel --no-show-raw-insn --no-leading-addr :
```
Disassembly of section .text:
<_start>:
push rax
mov dword ptr [rsp + 4], 0
mov dword ptr [rsp], 0
mov eax, dword ptr [rsp]
cmp eax, dword ptr [rip + 4112] # 202182 <g>
jge 0x20117e <_start+0x25>
call 0x201158 <foo>
inc dword ptr [rsp]
jmp 0x201169 <_start+0x10>
xor eax, eax
pop rcx
ret
```
llvm-objdump -d **--symbolize-operands** --x86-asm-syntax=intel --no-show-raw-insn --no-leading-addr :
```
Disassembly of section .text:
<_start>:
push rax
mov dword ptr [rsp + 4], 0
mov dword ptr [rsp], 0
<L1>:
mov eax, dword ptr [rsp]
cmp eax, dword ptr <g>
jge <L0>
call <foo>
inc dword ptr [rsp]
jmp <L1>
<L0>:
xor eax, eax
pop rcx
ret
```
Note that the jump instructions like `jge 0x20117e <_start+0x25>` without this work is printed as a real target address and an offset from the leading symbol. With a change in the optimizer that adds/deletes an instruction, the address and offset may shift for targets placed after the instruction. This will be a problem when diffing the disassembly from two optimizers where there are unnecessary false positives due to such branch target address changes. With `--symbolize-operand`, a label is printed for a branch target instead to reduce the false positives. Similarly, the disassemble of PC-relative global variable references is also prone to instruction insertion/deletion.
Reviewed By: jhenderson, MaskRay
Differential Revision: https://reviews.llvm.org/D84191
This fixes existent FIXMEs: we should not error out when unable to
find the number of relocations.
Differential revision: https://reviews.llvm.org/D85891
Splitted out from D85519.
Currently we report "PT_DYNAMIC segment offset + size exceeds the size of the file",
this changes it to
"PT_DYNAMIC segment offset (0x1234) + file size (0x5678) exceeds the size of the file (0x68ab)"
Differential revision: https://reviews.llvm.org/D85654
Add support for passing in libraries via `-l` and `-L` options to
`llvm-libtool-darwin`.
Reviewed by jhenderson, smeenai
Differential Revision: https://reviews.llvm.org/D85540
Add support for producing universal binaries containing archives when
`llvm-libtool-darwin` is given inputs of multiple architectures.
Reviewed by jhenderson, smeenai
Differential Revision: https://reviews.llvm.org/D85334
This reapplies commit e137b55058 with
fixes for the broken test case: Non-global symbols should only be
skipped after checking that they're not referenced by the harness.
This change moves elfabi related code to llvm/InterfaceStub library
so it can be shared by multiple llvm tools without causing cyclic
dependencies.
Differential Revision: https://reviews.llvm.org/D85678
Add support for -arch_only option for llvm-libtool-darwin. This diff
also adds support for accepting universal files as input and flattening
them to create the required static library. Supports input universal
files contaning both Mach-O object files or archives.
Differences from cctools' libtool:
- `-arch_only` can be specified multiple times
- archives containing universal files are considered invalid (libtool
allows such archives)
Reviewed by jhenderson, smeenai
Differential Revision: https://reviews.llvm.org/D84770
If the referenced symbol of a J[U]MP_SLOT is invalid (e.g. symbol index 0), llvm-objdump -d will bail out:
```
error: 'a': st_name (0x326600) is past the end of the string table of size 0x7
```
where 0x326600 is the st_name field of the first entry past the end of .symtab
Change it to a warning to continue dumping.
`X86/plt.test` uses a prebuilt executable, so I pick `ELF/AArch64/plt.test`
which has a YAML input and can be easily modified.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D85623
`getElfSegmentType` and `getElfPtType` are methods that are used for printing
segment types for LLVM and GNU styles accordingly.
This patch does a cleanup and simplification that allows to avoid
the code duplication and to get rid of one macro.
Differential revision: https://reviews.llvm.org/D85830
Specifying --headers is equivalent to setting --file-headers,
--program-headers and --section-headers at the same time.
The existent test case uses a precompiled object and doesn't test the
output properly. This patch fixes it.
Differential revision: https://reviews.llvm.org/D85832
This change replaces the InitialLength of pub-tables with Format and
Length. All the InitialLength fields have been removed.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D85880
This removes the last `unwrapOrError` call from the `printRelocationsHelper`.
There is a little additional complexity because of `SHT_RELR/SHT_ANDROID_RELR` sections.
Such sections contains only relative relocations and they do not have a
symbol table associated with them, hence we should not try to treat
their `sh_link` field as a reference to a symbol table.
Differential revision: https://reviews.llvm.org/D85430
where stdio.h ::remove() may set errno to EEXIST instead of ENOTEMPTY.
POSIX.1-2017 allows EEXIST for unlink() (which is called by remove()):
> [EEXIST] or [ENOTEMPTY]
> The flag parameter has the AT_REMOVEDIR bit set and the path argument names a directory that is not an empty directory, or there are hard links to the directory other than dot or a single entry in dot-dot.
Reviewed By: ro
Differential Revision: https://reviews.llvm.org/D85690
It removes all `unwrapOrError` calls except the first one, which
is is bit different and can be removed separately.
Differential revision: https://reviews.llvm.org/D85303
This patch refactors the DWARF section dumpers. When dumping a DWARF
section, if the DWARF parser fails to parse the section, we will dump it
as a raw content section. This patch also fixes a bug in
DWARFYAML::Data::isEmpty(). Finally, a test case that tests dumping the
__debug_aranges section is added.
Reviewed By: jhenderson, grimar
Differential Revision: https://reviews.llvm.org/D85506
The switch from llvm::cl to OptTable (D83530) dropped --version, which
is needed by some users.
This patch also adds a -v alias, which is available in GNU addr2line.
The version dumping is similar to llvm-objcopy --version (exotic):
```
llvm-symbolizer
LLVM (http://llvm.org/):
LLVM version 12.0.0git
Optimized build with assertions.
Default target: x86_64-unknown-linux-gnu
Host CPU: skylake-avx512
```
Reviewed By: dyung, jhenderson
Differential Revision: https://reviews.llvm.org/D85624
Although the DWARF specification states that .debug_aranges entries
can't have length zero, these can occur in the wild. There's no
particular reason to enforce this part of the spec, since functionally
they have no impact. The patch removes the error and introduces a new
warning for premature terminator entries which does not stop parsing.
This is a relanding of cb3a598c87, adding the missing obj2yaml part
that was needed.
Fixes https://bugs.llvm.org/show_bug.cgi?id=46805. See also
https://reviews.llvm.org/D71932 which originally introduced the error.
Reviewed by: ikudrin, dblaikie, Higuoxing
Differential Revision: https://reviews.llvm.org/D85313
It adds the proper warnings reporting and updates the mips-reginfo.test to
remove using of the precompiled binary.
Differential revision: https://reviews.llvm.org/D85511
Implemented the `llvm-profdata overlap` feature for sample profiles. It reports weighted //similarity// and unweighted //overlap// metrics at program and function level for two input profiles. Similarity metrics are symmetric with regards to the order of two input profiles. By default, the tool only reports program-level summary. Users can look into function-level details via additional options `--function`, `--similarity-cutoff`, and `--value-cutoff`.
The similarity metrics are designed as follows:
* Program-level summary
* Whole program profile similarity is an aggregate over function-level similarity `FS`: `PS = sum(FS(A) * avg_weight(A))` for all function `A`.
* Whole program sample overlap: `PSO = common_samples / total_samples`.
* Function overlap: `FO = #common_function / #total_function`.
* Hot-function overlap: `HFO = #common_hot_function / #total_hot_function`.
* Hot-block overlap: `HBO = #common_hot_block / #total_hot_block`.
* Function-level details
* Function-level similarity is an aggregate over line/block-level similarities `BS` of all sample lines/blocks in the function, weighted by the closeness of the function's weights in two profiles: `FS = sum(BS(i)) * (1 - weight_distance(A))`.
* Function-level sample overlap: `FSO = common_samples / total_samples` for samples in the function.
Reviewed By: wenlei, hoyFB, wmi
Differential Revision: https://reviews.llvm.org/D83852
It is not enough to replace all uses of users of the function with undef,
the users, we only drop instruction users, so they may stick around.
Let's try different approach - first drop bodies for all the functions
we will drop, which should take care of blockaddress issue the previous
rewrite was dealing with; then, after dropping *all* such bodies,
replace remaining uses with undef (thus all the uses are either
outside of functions, or are in kept functions)
and then finally drop functions.
This seems to work, and passes the *existing* test coverage,
but it is possible that a new issue will be discovered later :)
A new (previously crashing) test added.
Add support for `-D` and `-U` options for llvm-libtool-darwin. `-D`
allows for using zero for timestamps and UIDs/GIDs. `-U` allows for
using actual timestamps and UIDs/GIDs.
Reviewed by jhenderson, smeenai
Differential Revision: https://reviews.llvm.org/D84209
Add support for `-filelist` option for llvm-libtool-darwin. `-filelist`
option allows for passing in a file containing a list of filenames.
Reviewed by jhenderson, smeenai
Differential Revision: https://reviews.llvm.org/D84206
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
Georgii Rymar