Summary:
llvm-objdump -macho will no longer print "Contents of" headers when
disassembling section contents when -no-leading-headers is specified.
For historical reasons, this flag is independent of -no-leading-addr.
Reviewers: ab, pete, jhenderson
Reviewed By: jhenderson
Subscribers: rupprecht, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73574
Summary:
llvm-objdump started warning when asked to disassemble a section that
isn't present in the input files, in Yuanfang Chen's change:
d16c162c94. The problem is that the
logic was restricted only to the generic llvm-objdump parser, not to the
Mach-O-specific parser used for Apple toolchain compatibility. The
solution is to log section names from the Mach-O parser.
The macho-cstring-dump.test has been updated to fail if it encounters
this new warning in the future.
Reviewers: pete, ab, lhames, jhenderson, grimar, MaskRay, ychen
Reviewed By: jhenderson, grimar
Subscribers: rupprecht, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73586
Summary:
It turns out that CUR_DIRECTION is just an internal placeholder, not an actual
valid encoded value.
Reviewers: gchatelet
Subscribers: tschuett, mstojanovic, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73343
Disassembly of instructions can fail when llvm-objdump is not given the right set of
architecture features, for example when the source is compiled with:
clang -march=..+ext1+ext2
and disassembly is attempted with:
llvm-objdump -mattr=+ext1
This patch avoids further analysing unknown instructions (as was happening
before) when disassembly has failed.
Differential Revision: https://reviews.llvm.org/D73531
Currently when we dump dynamic relocation with use of
DT_RELA/DT_RELASZ/DT_RELAENT tags, we crash when a symbol index
is larger than the number of dynamic symbols or
when there is no dynamic symbol table.
This patch adds test cases and fixes the issues.
Differential revision: https://reviews.llvm.org/D73560
DynRegionInfo is a helper class used to create memory ranges.
It is used for many things and can report errors.
Errors reported currently do not provide a good diagnostic.
This patch fixes it and adds a test for each possible case.
Differential revision: https://reviews.llvm.org/D73484
The current implementation stops dumping in case of a single error
it handles, though we can continue dumping.
This patch refines it: it adds a few warnings and a few test cases.
Differential revision: https://reviews.llvm.org/D73269
Summary:
This patch makes sure that the field VFShape.VF is greater than zero
when demangling the vector function name of scalable vector functions
encoded in the "vector-function-abi-variant" attribute.
This change is required to be able to provide instances of VFShape
that can be used to query the VFDatabase for the vectorization passes,
as such passes always require a positive value for the Vectorization Factor (VF)
needed by the vectorization process.
It is not possible to extract the value of VFShape.VF from the mangled
name of scalable vector functions, because it is encoded as
`x`. Therefore, the VFABI demangling function has been modified to
extract such information from the IR declaration of the vector
function, under the assumption that _all_ vectors in the signature of
the vector function have the same number of lanes. Such assumption is
valid because it is also assumed by the Vector Function ABI
specifications supported by the demangling function (x86, AArch64, and
LLVM internal one).
The unit tests that demangle scalable names have been modified by
adding the IR module that carries the declaration of the vector
function name being demangled.
In particular, the demangling function fails in the following cases:
1. When the declaration of the scalable vector function is not
present in the module.
2. When the value of VFSHape.VF is not greater than 0.
Reviewers: jdoerfert, sdesmalen, andwar
Reviewed By: jdoerfert
Subscribers: mgorny, kristof.beyls, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73286
Currently only supports simple copying, other operations to follow.
Reviewers: sbc100, alexshap, jhenderson
Differential Revision: https://reviews.llvm.org/D70930
This is a reland of a928d127a with a one-line fix to ensure that
the wasm version number is written as little-endian (it's the only
field in all of the binary format that's not a single byte or an
LEB, but we may have to watch out more when we start handling the
linking section).
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
It isn't known how many times we've seen the same variable or member in
the global scope (unlike in functions), but there still can be some duplicates
among different CUs.
So, this patch proposes to count variables in the global scope just as a sum of
the number of vars, constant members and artificial entities.
Reviewed by: aprantl
Differential Revision: https://reviews.llvm.org/D73004
A few DW_TAG_formal_parameter's of the same function may have the same
name (e.g. variadic (template) functions) or don't have a name at all
(if the parameter isn't used inside the function body), but we still
need to be able to distinguish between them to get correct number of 'total vars'
and 'availability' metric.
Reviewed by: aprantl
Differential Revision: https://reviews.llvm.org/D73003
Here may be more than one out-of-line instance of the same function
among different CUs. All of them should be accounted for to get an accurate
total number of variables/parameters.
Reviewed by: aprantl
Differential Revision: https://reviews.llvm.org/D73002
DW_TAG_subroutine_type is not really useful for statistics purposes, as it never
has location information. But it may contain DW_TAG_formal_parameter
children that generate number of parameters w/o location and decrease
'availability' metric significantly.
Reviewed by: djtodoro
Differential Revision: https://reviews.llvm.org/D72983
Different variables and functions might have the same name in different CU.
To calculate 'Availability' metric more accurate (i.e. to avoid getting
availability above 100%), we need to have some additional logic to
distinguish between them.
The patch introduces a DIE identifier that consists of a function/variable name
and declaration information: a filename and a line number. This allows
distinguishing different functions/variables (different means declared in
different files/lines) with the same name, keeping duplicates counted
as duplicates.
Reviewed by: aprantl, djtodoro
Differential Revision: https://reviews.llvm.org/D72797
Currently only supports simple copying, other operations to follow.
Reviewers: sbc100, alexshap, jhenderson
Differential Revision: https://reviews.llvm.org/D70930
This restores 59733525d3 (D71913), along
with bot fix 19c76989bb.
The bot failure should be fixed by D73418, committed as
af954e441a.
I also added a fix for non-x86 bot failures by requiring x86 in new test
lld/test/ELF/lto/devirt_vcall_vis_public.ll.
The Version was used only to determine the size of an operand of
DW_OP_call_ref. The size was 4 for all versions apart from 2, but
the DW_OP_call_ref operation was introduced only in DWARF3. Thus,
the code may be simplified and using of Version may be eliminated.
Differential Revision: https://reviews.llvm.org/D73264
We have no good test for --needed-libs option.
The one we have as a part of Object/readobj-shared-object.test
is not complete.
In this patch I've did a minor NFC changes to the implementation and
added a test. This allowed to remove this piece from
Object/readobj-shared-object.test
Differential revision: https://reviews.llvm.org/D73174
Summary:
What we're redoing already exists in the X86 backend, it's called
`X86II::getOperandBias`.
Reviewers: gchatelet
Subscribers: tschuett, mstojanovic, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73340
We have a test/Object/no-section-header-string-table.test which checks
what happens when an object does not have a section header string table.
It does not check the full output though.
Currently our output is different from GNU readelf, because the latter prints
"<no-strings>" instead of a section name, while we print nothing.
This patch fixes this, adds a proper test case and removes the one from test/Object,
as it is not a right folder for llvm-readelf tests.
Differential revision: https://reviews.llvm.org/D73193
Summary:
Third part in series to support Safe Whole Program Devirtualization
Enablement, see RFC here:
http://lists.llvm.org/pipermail/llvm-dev/2019-December/137543.html
This patch adds type test metadata under -fwhole-program-vtables,
even for classes without hidden visibility. It then changes WPD to skip
devirtualization for a virtual function call when any of the compatible
vtables has public vcall visibility.
Additionally, internal LLVM options as well as lld and gold-plugin
options are added which enable upgrading all public vcall visibility
to linkage unit (hidden) visibility during LTO. This enables the more
aggressive WPD to kick in based on LTO time knowledge of the visibility
guarantees.
Support was added to all flavors of LTO WPD (regular, hybrid and
index-only), and to both the new and old LTO APIs.
Unfortunately it was not simple to split the first and second parts of
this part of the change (the unconditional emission of type tests and
the upgrading of the vcall visiblity) as I needed a way to upgrade the
public visibility on legacy WPD llvm assembly tests that don't include
linkage unit vcall visibility specifiers, to avoid a lot of test churn.
I also added a mechanism to LowerTypeTests that allows dropping type
test assume sequences we now aggressively insert when we invoke
distributed ThinLTO backends with null indexes, which is used in testing
mode, and which doesn't invoke the normal ThinLTO backend pipeline.
Depends on D71907 and D71911.
Reviewers: pcc, evgeny777, steven_wu, espindola
Subscribers: emaste, Prazek, inglorion, arichardson, hiraditya, MaskRay, dexonsmith, dang, davidxl, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D71913
Summary:
The primary goal of this refactoring is to separate DWARF optimizing part.
So that it could be reused by linker or by any other client.
There was a thread on llvm-dev discussing the necessity of such a refactoring:
http://lists.llvm.org/pipermail/llvm-dev/2019-September/135068.html.
This is a final part from series of patches for dsymutil.
Previous patches : D71068, D71839, D72476. This patch:
1. Creates lib/DWARFLinker interface :
void addObjectFile(DwarfLinkerObjFile &ObjFile);
bool link();
void setOptions;
1. Moves all linking logic from tools/dsymutil/DwarfLinkerForBinary
into lib/DWARFLinker.
2. Renames RelocationManager into AddressesManager.
3. Remarks creation logic moved from separate parallel execution
into object file loading routine.
Testing: it passes "check-all" lit testing. MD5 checksum for clang .dSYM bundle
matches for the dsymutil with/without that patch.
Reviewers: JDevlieghere, friss, dblaikie, aprantl, jdoerfert
Reviewed By: JDevlieghere
Subscribers: merge_guards_bot, hiraditya, jfb, llvm-commits, probinson, thegameg
Tags: #llvm, #debug-info
Differential Revision: https://reviews.llvm.org/D72915
Since some instruction types aren't allowed as the main instruction also
don't allow them for aliasing instructions.
Differential Revision: https://reviews.llvm.org/D73220
Summary:
... instead of crashing.
On typical exmaple is when there are no available registers.
Reviewers: gchatelet
Subscribers: tschuett, mstojanovic, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73196
This helps to detect and report parsing errors better.
The patch follows the ideas of LLDB's patches D59370 and D59381.
It adds tests for valid and some invalid cases. More checks and
tests to come. Note that the patch fixes validation of the Length
field because the value does not include the field itself.
The existing users are updated to show the error messages.
Differential Revision: https://reviews.llvm.org/D71875
Summary:
This flag was added for the json format to exclude functions from the
output. This mirrors that behavior in lcov (where it was previously
accepted but ignored). This makes the output file smaller which can be
beneficial depending on how you consume it, especially if you don't use
this data anyways.
Patch by Keith Smiley (@keith).
Reviewers: kastiglione, Dor1s, vsk, allevato
Reviewed By: Dor1s, allevato
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73160
Summary:
Right now when picking a back-to-back instruction at random, we might select
instructions that we do not know how to handle.
Add a ExegesisTarget hook to possibly filter instructions.
Reviewers: gchatelet
Subscribers: tschuett, mstojanovic, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73161
This commit adds a ManglingOptions struct to IRMaterializationUnit, and replaces
IRCompileLayer::CompileFunction with a new IRCompileLayer::IRCompiler class. The
ManglingOptions struct defines the emulated-TLS state (via a bool member,
EmulatedTLS, which is true if emulated-TLS is enabled and false otherwise). The
IRCompileLayer::IRCompiler class wraps an IRCompiler (the same way that the
CompileFunction typedef used to), but adds a method to return the
IRCompileLayer::ManglingOptions that the compiler will use.
These changes allow us to correctly determine the symbols that will be produced
when a thread local global variable defined at the IR level is compiled with or
without emulated TLS. This is required for ORCv2, where MaterializationUnits
must declare their interface up-front.
Most ORCv2 clients should not require any changes. Clients writing custom IR
compilers will need to wrap their compiler in an IRCompileLayer::IRCompiler,
rather than an IRCompileLayer::CompileFunction, however this should be a
straightforward change (see modifications to CompileUtils.* in this patch for an
example).
Summary:
Add unit test to show the issue: We must select an *aliasing* output
register, not the exact register.
Reviewers: gchatelet
Subscribers: tschuett, mstojanovic, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73095
This change is similar to one made for llvm-objdump in D72838.
llvm-readelf/llvm-readobj tools do not align the "Name/Value" column properly.
This patch adds a logic to calculate the size of indentation on fly
to fix such issues.
Differential revision: https://reviews.llvm.org/D72843
Georgii Rymar