Swithces from using the command line library to using TableGen. This will allow
llvm-strip to exist and allow refinements of the command line syntax.
Differential Revision: https://reviews.llvm.org/D44236
llvm-svn: 329863
These aren't the .def style files used in LLVM that require a macro
defined before their inclusion - they're just basic non-modular includes
to stamp out command line flag variables.
llvm-svn: 329840
This patch moves part of the logic that notifies dispatch stall events from the
DispatchUnit to the Scheduler.
The main goal of this patch is to remove (yet another) dependency between the
DispatchUnit and the Scheduler. Before this patch, the DispatchUnit had to know
about `Scheduler::Event` and how to classify stalls due to the lack of scheduling
resources. This patch removes that knowledge and simplifies the logic in
DispatchUnit::checkScheduler.
This is another change done in preparation for the work to fix PR36663.
No functional change intended.
llvm-svn: 329835
This patch moves the logic that collects and analyzes dispatch events to the
DispatchStatistics view.
Added flag -dispatch-stats to print statistics related to the dispatch logic.
llvm-svn: 329708
Summary:
Subtargets can define the libpfm counter names that can be used to
measure cycles and uops issued on ProcResUnits.
This allows making llvm-exegesis available on more targets.
Fixes PR36984.
Reviewers: gchatelet, RKSimon, andreadb, craig.topper
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D45360
llvm-svn: 329675
This patch teaches llvm-mca how to parse code comments in search for special
"markers" used to select regions of code.
Example:
# LLVM-MCA-BEGIN My Code Region
....
# LLVM-MCA-END
The MCAsmLexer now delegates to an object of class MCACommentParser (i.e. an
AsmCommentConsumer) the parsing of code comments to search for begin/end code
region markers.
A comment starting with substring "LLVM-MCA-BEGIN" marks the beginning of a new
region of code. A comment starting with substring "LLVM-MCA-END" marks the end
of the last region.
This implementation doesn't allow regions to overlap. Each region can have a
optional description; internally, each region is identified by a range of source
code locations (SMLoc).
MCInst objects are added to a region R only if the source location for the
MCInst is in the range of locations specified by R.
By default, the tool allocates an implicit "Default" code region which contains
every source location. See new tests llvm-mca-marker-*.s for a few examples.
A new Backend object is created for every region. So, the analysis is conducted
on every parsed code region. The final report is the union of the reports
generated for every code region. Note that empty regions are skipped.
Special "[#] Code Region - ..." strings are used in the report to mark the
portion which is specific to a code region only. For example, see
llvm-mca-markers-5.s.
Differential Revision: https://reviews.llvm.org/D45433
llvm-svn: 329590
Summary:
The option is helpful for large projects where it's not feasible to specify sources which
user would like to see in the report. Instead, it allows to black-list specific sources via
regular expressions (e.g. now it's possible to skip all files that have "test" in its name).
This also partially fixes https://bugs.llvm.org/show_bug.cgi?id=34277
Reviewers: vsk, morehouse, liaoyuke
Reviewed By: vsk
Subscribers: kcc, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D43907
llvm-svn: 329581
With the threading refactoring, loading of object files happens before
checking whether we're dealing with a swift AST. While that's not an
issue per se, it causes a warning to be printed:
warning: /path/to/a.swiftmodule: The file was not recognized as a valid object file
note: while processing /path/to/a.swiftmodule
This suppresses the warning by checking for a Swift AST before
attempting to load is as an object file.
rdar://39240444
llvm-svn: 329553
It was reported that this change measurably regressed -plugin-opt=O3
performance.
There is an ongoing discussion on llvm-dev about the correct way to
set the CG opt level, see thread "[llvm-dev] [RFC] Adding function
attributes to represent codegen optimization level".
llvm-svn: 329458
Summary:
- Add a missing getter for module-level inline assembly
- Add a missing append function for module-level inline assembly
- Deprecate LLVMSetModuleInlineAsm and replace it with LLVMSetModuleInlineAsm2 which takes an explicit length parameter
- Deprecate LLVMConstInlineAsm and replace it with LLVMGetInlineAsm, a function that allows passing a dialect and is not mis-classified as a constant operation
Reviewers: whitequark, deadalnix
Reviewed By: whitequark
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D45346
llvm-svn: 329369
Summary:
Previous code hangs indefinitely when trying to iterate through a
symbol link file that points to an non-exist directory. This change
fixes the bug to make the addCollectedPath function exit ealier and
print out correct warning messages.
Patch by Yuke Liao (@liaoyuke).
Reviewers: Dor1s, vsk
Reviewed By: vsk
Subscribers: bruno, mgrang, llvm-commits
Differential Revision: https://reviews.llvm.org/D44960
llvm-svn: 329338
These appear in a .debug$P section, which is exactly the same in
format as a .debug$T section. So we shouldn't ignore these when
dumping types.
llvm-svn: 329326
Scheduling models can now describe processor register files and retire control
units. This updates the existing documentation and the README file.
llvm-svn: 329311
This patch adds the ability to describe properties of the hardware retire
control unit.
Tablegen class RetireControlUnit has been added for this purpose (see
TargetSchedule.td).
A RetireControlUnit specifies the size of the reorder buffer, as well as the
maximum number of opcodes that can be retired every cycle.
A zero (or negative) value for the reorder buffer size means: "the size is
unknown". If the size is unknown, then llvm-mca defaults it to the value of
field SchedMachineModel::MicroOpBufferSize. A zero or negative number of
opcodes retired per cycle means: "there is no restriction on the number of
instructions that can be retired every cycle".
Models can optionally specify an instance of RetireControlUnit. There can only
be up-to one RetireControlUnit definition per scheduling model.
Information related to the RCU (RetireControlUnit) is stored in (two new fields
of) MCExtraProcessorInfo. llvm-mca loads that information when it initializes
the DispatchUnit / RetireControlUnit (see Dispatch.h/Dispatch.cpp).
This patch fixes PR36661.
Differential Revision: https://reviews.llvm.org/D45259
llvm-svn: 329304
This is done in preparation for D45259.
With D45259, models can specify the size of the reorder buffer, and the retire
throughput directly via tablegen.
llvm-svn: 329274
Summary:
Add a new plugin API. This closes the gap between pass registration and out-of-tree passes for the new PassManager.
Unlike with the existing API, interaction with a plugin is always
initiated from the tools perspective. I.e., when a plugin is loaded, it
resolves and calls a well-known symbol `llvmGetPassPluginInfo` to obtain
details about the plugin. The fundamental motivation is to get rid of as
many global constructors as possible. The API exposed by the plugin
info is kept intentionally minimal.
Reviewers: chandlerc
Reviewed By: chandlerc
Subscribers: bollu, grosser, lksbhm, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D35258
llvm-svn: 329273
Using this, you can use llvm-pdbutil to export the contents of a
stream to a binary file, then run explain on the binary file so
that it treats the offset as an offset into the stream instead
of an offset into a file. This makes it easy to compare the
contents of the same stream from two different files.
llvm-svn: 329207
Summary:
[llvm-exegesis][RFC] Automatic Measurement of Instruction Latency/Uops
This is the code corresponding to the RFC "llvm-exegesis Automatic Measurement of Instruction Latency/Uops".
The RFC is available on the LLVM mailing lists as well as the following document
for easier reading:
https://docs.google.com/document/d/1QidaJMJUyQdRrFKD66vE1_N55whe0coQ3h1GpFzz27M/edit?usp=sharing
Subscribers: mgorny, gchatelet, orwant, llvm-commits
Differential Revision: https://reviews.llvm.org/D44519
llvm-svn: 329156
The DwarfLinker can have some very deep recursion that can max out the
(significantly smaller) stack when using threads. We don't want this
limitation when we only have a single thread. We already have this
workaround for the architecture-related threading. This patch applies
the same workaround to the parallel analysis and cloning.
Differential revision: https://reviews.llvm.org/D45172
llvm-svn: 329093
Before this patch, the "BackendStatistics" view was responsible for printing the
register file usage (as well as many other statistics).
Now users can enable register file usage statistics using the command line flag
`-register-file-stats`. By default, the tool doesn't print register file
statistics.
llvm-svn: 329083
This patch allows the description of register files in processor scheduling
models. This addresses PR36662.
A new tablegen class named 'RegisterFile' has been added to TargetSchedule.td.
Targets can optionally describe register files for their processors using that
class. In particular, class RegisterFile allows to specify:
- The total number of physical registers.
- Which target registers are accessible through the register file.
- The cost of allocating a register at register renaming stage.
Example (from this patch - see file X86/X86ScheduleBtVer2.td)
def FpuPRF : RegisterFile<72, [VR64, VR128, VR256], [1, 1, 2]>
Here, FpuPRF describes a register file for MMX/XMM/YMM registers. On Jaguar
(btver2), a YMM register definition consumes 2 physical registers, while MMX/XMM
register definitions only cost 1 physical register.
The syntax allows to specify an empty set of register classes. An empty set of
register classes means: this register file models all the registers specified by
the Target. For each register class, users can specify an optional register
cost. By default, register costs default to 1. A value of 0 for the number of
physical registers means: "this register file has an unbounded number of
physical registers".
This patch is structured in two parts.
* Part 1 - MC/Tablegen *
A first part adds the tablegen definition of RegisterFile, and teaches the
SubtargetEmitter how to emit information related to register files.
Information about register files is accessible through an instance of
MCExtraProcessorInfo.
The idea behind this design is to logically partition the processor description
which is only used by external tools (like llvm-mca) from the processor
information used by the llvm machine schedulers.
I think that this design would make easier for targets to get rid of the extra
processor information if they don't want it.
* Part 2 - llvm-mca related *
The second part of this patch is related to changes to llvm-mca.
The main differences are:
1) class RegisterFile now needs to take into account the "cost of a register"
when allocating physical registers at register renaming stage.
2) Point 1. triggered a minor refactoring which lef to the removal of the
"maximum 32 register files" restriction.
3) The BackendStatistics view has been updated so that we can print out extra
details related to each register file implemented by the processor.
The effect of point 3. is also visible in tests register-files-[1..5].s.
Differential Revision: https://reviews.llvm.org/D44980
llvm-svn: 329067
This command can dump the binary contents of a stream to a file.
This is useful when you want to do side-by-side comparisons of
a specific stream from two PDBs to examine the differences between
them. You can export both of them to a file, then open them up
side by side in a hex editor (for example), so as to eliminate any
differences that might arise from the contents being on different
blocks in the PDB.
In subsequent patches I plan to improve the "explain" subcommand
so that you can explain the contents of a binary file that isn't
necessarily a full PDB, but one of these dumped streams, by telling
the subcommand how to interpret the contents.
llvm-svn: 329002
Before, the instruction builder incorrectly assumed that only explicit reads
could have been associated with ReadAdvance entries.
This patch fixes the issue and adds a test to verify it.
llvm-svn: 328972
When running dsymutil as part of your build system, it can be desirable
for warnings to be part of the end product, rather than just being
emitted to the output stream. This patch upstreams that functionality.
Differential revision: https://reviews.llvm.org/D44639
llvm-svn: 328965
This patch adds a set of unstable C API bindings to the DIBuilder interface for
creating structure, function, and aggregate types.
This patch also removes the existing implementations of these functions from
the Go bindings and updates the Go API to fit the new C APIs.
llvm-svn: 328953
Summary:
r327219 added wrappers to std::sort which randomly shuffle the container before sorting.
This will help in uncovering non-determinism caused due to undefined sorting
order of objects having the same key.
To make use of that infrastructure we need to invoke llvm::sort instead of std::sort.
Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort.
Refer the comments section in D44363 for a list of all the required patches.
Reviewers: JDevlieghere, zturner, echristo, dberris, friss
Reviewed By: echristo
Subscribers: gbedwell, llvm-commits
Differential Revision: https://reviews.llvm.org/D45141
llvm-svn: 328943
Summary:
Previous revision caused a leak in the echo test that got caught by the ASAN bots because of missing free of the handlers array and was reverted in r328759. Resubmitting the patch with that correction.
Add support for cleanupret, catchret, catchpad, cleanuppad and catchswitch and their associated accessors.
Test is modified from SimplifyCFG because it contains many diverse usages of these instructions.
Reviewers: whitequark, deadalnix
Reviewed By: whitequark
Subscribers: llvm-commits, vlad.tsyrklevich
Differential Revision: https://reviews.llvm.org/D45100
llvm-svn: 328883
This will show more detail when using `llvm-pdbutil explain` on an
offset in the DBI or PDB streams. Specifically, it will dig into
individual header fields and substreams to give a more precise
description of what the byte represents.
llvm-svn: 328878
As a further refinement on:
r328274 - For llvm-nm and Mach-O files also use function starts info in some cases when printing symbols
we want to special case a redacted LC_MAIN so it is easier to find.
rdar://38978929
llvm-svn: 328820
When we determine that a field belongs to an MSF super block or
the free page map, we wouldn't print any additional information.
With this patch, we now print the value of the field (for super
block fields) or the allocation status of the specified byte (in
the case of offsets in the FPM).
llvm-svn: 328808
DWARF v5 specifies that the root file (also given in the DW_AT_name
attribute of the compilation unit DIE) should be emitted explicitly to
the line table's list of files. This makes the line table more
independent of the .debug_info section.
We emit the new syntax only for DWARF v5 and later.
Fixes the bug found by asan. Also XFAIL the new test for Darwin, which
is stuck on DWARF v2, and fix up other tests so they stop failing on
Windows. Last but not least, don't break "clang -g" of an assembler
file that has .file directives in it.
Differential Revision: https://reviews.llvm.org/D44054
llvm-svn: 328805
We were trying to dig into the super block fields and print a
description of the field at the specified offset, but we were
printing the wrong field due to an off-by-one-field-error.
llvm-svn: 328804
When investigating various things, we often have a file offset
and what to know what's in the PDB at that address. For example
we may be doing a binary comparison of two LLD-generated PDBs
to look for sources of non-determinism, or we may wish to compare
an LLD-generated PDB with a Microsoft generated PDB for sources
of byte-for-byte incompatibility. In these cases, we can do a
binary diff of the two files, and once we find a mismatched byte
we can use explain to figure out what that byte is, immediately
honining in on the problem.
This patch implements this by trying to narrow the meaning of
a particular file offset down as much as possible.
Differential Revision: https://reviews.llvm.org/D44959
llvm-svn: 328799
The tool was passing the wrong operand index to method
MCSubtargetInfo::getReadAdvanceCycles(). That method requires a "UseIdx", and
not the operand index. This was found when testing X86 code where instructions
had a memory folded operand.
This patch fixes the issue and adds test read-advance-1.s to ensure that
the ReadAfterLd (a ReadAdvance of 3cy) information is correctly used.
llvm-svn: 328790
Summary:
As we are only doing X.0.Z releases (not using the minor version), there is no need to keep -X.Y in the version.
Like patch https://reviews.llvm.org/D41808, I propose that we rename libLLVM-7.0svn.so to libLLVM-7svn.so
This patch will also rename downstream libraries like liblldb-7.0 to liblldb-7
Reviewers: axw, beanz, dim, hans
Reviewed By: dim, hans
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D41869
llvm-svn: 328768
Summary:
Add support for cleanupret, catchret, catchpad, cleanuppad and catchswitch and their associated accessors.
Test is modified from SimplifyCFG because it contains many diverse usages of these instructions.
Reviewers: whitequark, deadalnix, echristo
Reviewed By: echristo
Subscribers: llvm-commits, harlanhaskins
Differential Revision: https://reviews.llvm.org/D44496
llvm-svn: 328759
This allows syntax like:
$ llvm-ar -c -r -u file.a file.o
This is in addition to the other formats that are already supported:
$ llvm-ar cru file.a file.o
$ llvm-ar -cru file.a file.o
Patch by Tom Anderson!
Differential Revision: https://reviews.llvm.org/D44452
llvm-svn: 328716
This reverts commit r328676.
Commit r328676 broke the -no-integrated-as flag necessary to build Linux kernel with Clang:
$ cat t.c
void foo() {}
$ clang -no-integrated-as -c t.c -g
/tmp/t-dcdec5.s: Assembler messages:
/tmp/t-dcdec5.s:8: Error: file number less than one
clang-7.0: error: assembler command failed with exit code 1 (use -v to see invocation)
llvm-svn: 328699
DWARF v5 specifies that the root file (also given in the DW_AT_name
attribute of the compilation unit DIE) should be emitted explicitly to
the line table's list of files. This makes the line table more
independent of the .debug_info section.
Fixes the bug found by asan. Also XFAIL the new test for Darwin, which
is stuck on DWARF v2, and fix up other tests so they stop failing on
Windows. Last but not least, don't break "clang -g" of an assembler
file that has .file directives in it.
Differential Revision: https://reviews.llvm.org/D44054
llvm-svn: 328676
We were incorrectly initializing the array of used registers in method checkRAT.
As a consequence, the number of register file stalls was misreported.
Added a test to cover this case.
llvm-svn: 328629
This has been made obsolete by the fact that almost all of the
things it previously checked for are no longer relevant since
we can just compare bytes in a lot of places.
llvm-svn: 328562
Summary:
llvm-objdump now disassembles unrecognised opcodes as data, using
the .long directive. We treat unrecognised opcodes as being 32 bit
values, so move along 4 bytes rather than the single byte which
previously resulted in a cascade of bogus disassembly following an
unrecognised opcode.
While no solution can always disassemble code that contains
embedded data correctly this provides a significant improvement.
The disassembler will now cope with an arbitrary length section
as it no longer truncates it to a multiple of 4 bytes, and will
use the .byte directive for trailing bytes.
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D44685
llvm-svn: 328553
The goal of this patch is to address most of PR36874. To fully fix PR36874 we
need to split the "InstructionInfo" view from the "SummaryView". That would make
easy to check the latency and rthroughput as well.
The patch reuses all the logic from ResourcePressureView to print out the
"instruction tables".
We have an entry for every instruction in the input sequence. Each entry reports
the theoretical resource pressure distribution. Resource pressure is uniformly
distributed across all the processor resource units of a group.
At the moment, the backend pipeline is not configurable, so the only way to fix
this is by creating a different driver that simply sends instruction events to
the resource pressure view. That means, we don't use the Backend interface.
Instead, it is simpler to just have a different code-path for when flag
-instruction-tables is specified.
Once Clement addresses bug 36663, then we can port the "instruction tables"
logic into a stage of our configurable pipeline.
Updated the BtVer2 test cases (thanks Simon for the help). Now we pass flag
-instruction-tables to each modified test.
Differential Revision: https://reviews.llvm.org/D44839
llvm-svn: 328487
When investigating bugs in PDB generation, the first step is
often to do the same link with link.exe and then compare PDBs.
But comparing PDBs is hard because two completely different byte
sequences can both be correct, so it hampers the investigation when
you also have to spend time figuring out not just which bytes are
different, but also if the difference is meaningful.
This patch fixes a couple of cases related to string table emission,
hash table emission, and the order in which we emit strings that
makes more of our bytes the same as the bytes generated by MS PDBs.
Differential Revision: https://reviews.llvm.org/D44810
llvm-svn: 328348
This is done in preparation for the fix for PR36874.
The number of cycles consumed for each pipe is now a double quantity. This
allows reuse of the resource pressure view to print out instruction tables.
llvm-svn: 328335
By default, the tool always enables the resource pressure view.
This flag lets user specify whether they want to add that view or not.
llvm-svn: 328305
cases when printing symbols. As an improvement to:
r305733 - Change llvm-nm for Mach-O files to use dyld info in some cases when printing symbols
it could be made a bit better if it also read the function starts and faked
up nlist entries to those address not already faked up by the other
dyld info. This would help with stripped static functions.
rdar://38761029
llvm-svn: 328274
Remove #include of Transforms/Scalar.h from Transform/Utils to fix layering.
Transforms depends on Transforms/Utils, not the other way around. So
remove the header and the "createStripGCRelocatesPass" function
declaration (& definition) that is unused and motivated this dependency.
Move Transforms/Utils/Local.h into Analysis because it's used by
Analysis/MemoryBuiltins.cpp.
llvm-svn: 328165
This diff adds support for SHT_GROUP sections to llvm-objcopy.
Some sections are interrelated and comprise a group.
For example, a definition of an inline function might require,
in addition to the section containing its instructions,
a read-only data section containing literals referenced inside the function.
A section of the type SHT_GROUP contains the indices of the group members,
therefore, it needs to be updated whenever the indices change.
Similarly, the fields sh_link, sh_info should be recalculated as well.
[Resubmit r328012 with the proper handling of endianness]
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D43996
llvm-svn: 328143
With this patch, the "instruction dispatched" event now provides information
related to the number of microarchitectural registers used in each register
file. Similarly, the "instruction retired" event is now able to tell how may
registers are freed in each register file.
Currently, the BackendStatistics view is the only consumer of register
usage/pressure information. BackendStatistics uses that info to print out a few
general statistics (i.e. max number of mappings used; total mapping created).
Before this patch, the BackendStatistics was forced to query the Backend to
obtain the register pressure information.
This helps removes that dependency. Now views are completely independent from
the Backend. As a consequence, it should be easier to address PR36663 and
further modularize the pipeline.
Added a couple of test cases in the BtVer2 specific directory.
llvm-svn: 328129
Summary:
I recently added a new dynamic tag to our fork of LLVM and when adding it
to llvm-readobj I noticed that not all DT_ values were being handled there.
Using macros in a .def file that can be included by both ELFDumper.cpp and
the ELF.h header ensures that the two don't get out of sync when new values
are added.
Reviewers: grimar, pcc, davide, espindola
Reviewed By: grimar, espindola
Subscribers: srhines, llvm-commits
Differential Revision: https://reviews.llvm.org/D44558
llvm-svn: 328099
term sections from .o files to look to see if the pointers have a relocation
entry and if so print the symbol name from the relocation entry. If not fall
back to the existing code and use the pointer value to look up that value
in the symbol table.
rdar://38337506
llvm-svn: 328037
This is still failing on a different bot this time due to some
issue related to hashing absolute paths. Reverting until I can
figure it out.
llvm-svn: 328014
This diff adds support for SHT_GROUP sections to llvm-objcopy.
Some sections are interrelated and comprise a group.
For example, a definition of an inline function might require,
in addition to the section containing its instructions,
a read-only data section containing literals referenced inside the function.
A section of the type SHT_GROUP contains the indices of the group members,
therefore, it needs to be updated whenever the indices change.
Similarly, the fields sh_link, sh_info should be recalculated as well.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D43996
llvm-svn: 328012
This patch introduces two new callbacks in the event listener interface to
handle the "buffered resource reserved" event and the "buffered resource
released" event. Every time a buffered resource is used, an event is generated.
Before this patch, the Scheduler (with the help of the ResourceManager) was
responsible for tracking the scheduler's queue usage. However, that design
forced the Scheduler to 'publish' scheduler's queue pressure information through
the Backend interface.
The goal of this patch is to break the dependency between the BackendStatistics
view, and the Backend. Now the Scheduler knows how to notify "buffer
reserved/released" events. The scheduler's queue usage analysis has been moved
to the BackendStatistics.
Differential Revision: https://reviews.llvm.org/D44686
llvm-svn: 328011
The issue causing this to fail in certain configurations
should be fixed.
It was due to the fact that DIA apparently expects there to be
a null string at ID 1 in the string table. I'm not sure why this
is important but it seems to make a difference, so set it.
llvm-svn: 328002
Function computeProcResourceMasks is used by the ResourceManager (owned by the
Scheduler) to compute resource masks for processor resources. Before this
refactoring, there was an implicit dependency between the Scheduler and the
InstrBuilder. That is because InstrBuilder has to know about resource masks when
computing the set of processor resources consumed by a new instruction.
With this patch, the functionality that computes resource masks has been
extracted from the ResourceManager, and moved to a separate file (Support.h).
This helps removing the dependency between the Scheduler and the InstrBuilder.
No functional change intended.
llvm-svn: 327973
Natvis is a debug language supported by Visual Studio for
specifying custom visualizers. The /NATVIS option is an
undocumented link.exe flag which will take a .natvis file
and "inject" it into the PDB. This way, you can ship the
debug visualizers for a program along with the PDB, which
is very useful for postmortem debugging.
This is implemented by adding a new "named stream" to the
PDB with a special name of /src/files/<natvis file name>
and simply copying the contents of the xml into this file.
Additionally, we need to emit a single stream named
/src/headerblock which contains a hash table of embedded
files to records describing them.
This patch adds this functionality, including the /NATVIS
option to lld-link.
Differential Revision: https://reviews.llvm.org/D44328
llvm-svn: 327895
This patch introduces a new class named HWStallEvent (see HWEventListener.h),
and updates the event listener interface. A HWStallEvent represents a pipeline
stall caused by the lack of hardware resources. Similarly to HWInstructionEvent,
the event type is an unsigned, and the exact meaning depends on the subtarget.
At the moment, HWStallEvent supports a few generic dispatch events.
The main goals of this patch is to remove the logic that counts dispatch stalls
from the DispatchUnit to the BackendStatistics view.
Previously, DispatchUnit was responsible for counting and classifying dispatch
stall events. With this patch, we delegate the task of counting and classifying
stall events to the listeners (i.e. in our case, it is view
"BackendStatistics"). So, the DispatchUnit doesn't have to do extra
(unnecessary) bookkeeping.
This patch also helps futher simplifying the Backend interface. Now class
BackendStatistics no longer has to query the Backend interface to obtain the
number of dispatch stalls. As a consequence, we can get rid of all the
'getNumXXX()' methods from class Backend.
The long term goal is to remove all the remaining dependencies between the
Backend and the BackendStatistics interface.
Differential Revision: https://reviews.llvm.org/D44621
llvm-svn: 327837
This is a refactoring in preparation for other two changes that will allow
scheduling models to define multiple register files. This is the first step
towards fixing PR36662.
class RegisterFile (in Dispatch.h) now can emulate multiple register files.
Internally, it tracks the number of available physical registers in each
register file (described by class RegisterFileInfo).
Each register file is associated to a list of MCRegisterClass indices. Knowing
the register class indices allows to map physical registers to register files.
The long term goal is to allow processor models to optionally specify how many
register files are implemented via tablegen.
Differential Revision: https://reviews.llvm.org/D44488
llvm-svn: 327798
Now that almost all functionality of Apple's dsymutil has been
upstreamed, the open source variant can be used as a drop in
replacement. Hence we feel it's no longer necessary to have the llvm
prefix.
Differential revision: https://reviews.llvm.org/D44527
llvm-svn: 327790
It previously only worked when the key and value types were
both 4 byte integers. We now have a use case for a non trivial
value type, so we need to extend it to support arbitrary value
types, which means templatizing it.
llvm-svn: 327647
Now both method DispatchUnit::checkRAT() and DispatchUnit::canDispatch take as
input an Instruction refrence instead of an instruction descriptor.
This was requested by Simon in D44488 to simplify the diff.
llvm-svn: 327640
This reverts commit r327566, it breaks
test/ExecutionEngine/OrcMCJIT/test-global-ctors.ll.
The test doesn't crash with a stack trace, unfortunately. It merely
returns 1 as the exit code.
ASan didn't produce a report, and I reproduced this on my Linux machine
and Windows box.
llvm-svn: 327576
Layer implementations typically mutate module state, and this is better
reflected by having layers own the Module they are operating on.
llvm-svn: 327566
Before this patch, the register file was always updated at instruction creation
time. That means, new read-after-write dependencies, and new temporary registers
were allocated at instruction creation time.
This patch refactors the code in InstrBuilder, and move all the logic that
updates the register file into the dispatch unit. We only want to update the
register file when instructions are effectively dispatched (not before).
This refactoring also helps removing a bad dependency between the InstrBuilder
and the DispatchUnit.
No functional change intended.
llvm-svn: 327514
Summary:
(Restores r327459 with handling for old plugin-api.h)
Utilize new gold plugin api interface for obtaining --wrap option
arguments, and LTO API handling (added for --wrap support in lld LTO),
to mark symbols so that LTO does not optimize them inappropriately.
Note the test cases will be in a new gold test subdirectory that
is dependent on the next release of gold which will contain the new
interfaces.
Reviewers: pcc, tmsriram
Subscribers: mehdi_amini, llvm-commits, inglorion
Differential Revision: https://reviews.llvm.org/D44235
llvm-svn: 327506
Summary:
This patch replaces the two switches which are deducing the size of
various forms with a single implementation. I have put the new
implementation into BinaryFormat, to avoid introducing dependencies
between the two independent libraries (DebugInfo and CodeGen) that need
this functionality.
Reviewers: aprantl, JDevlieghere, dblaikie
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D44418
llvm-svn: 327486
Make the architecture part of the warning in the DebugMapParser. This
makes things consistent with the Apple's internal version of dsymutil.
llvm-svn: 327485
Summary:
The old bindings should have used an enum instead of a boolean. This
deprecates LLVMHasUnnamedAddr and LLVMSetUnnamedAddr , replacing them
with LLVMGetUnnamedAddress and LLVMSetUnnamedAddress respectively that do.
Though it is unlikely LLVM will gain more supported global value linker
hints, the new API can scale to accommodate this.
Reviewers: deadalnix, whitequark
Reviewed By: whitequark
Subscribers: llvm-commits, harlanhaskins
Differential Revision: https://reviews.llvm.org/D43448
llvm-svn: 327479
Summary:
Utilize new gold plugin api interface for obtaining --wrap option
arguments, and LTO API handling (added for --wrap support in lld LTO),
to mark symbols so that LTO does not optimize them inappropriately.
Note the test cases will be in a new gold test subdirectory that
is dependent on the next release of gold which will contain the new
interfaces.
Reviewers: pcc, tmsriram
Subscribers: mehdi_amini, llvm-commits, inglorion
Differential Revision: https://reviews.llvm.org/D44235
llvm-svn: 327459
Injected sources are basically a way to add actual source file content
to your PDB. Presumably you could use this for shipping your source code
with your debug information, but in practice I can only find this being
used for embedding natvis files inside of PDBs.
In order to effectively test LLVM's natvis file injection, we need a way
to dump the injected sources of a PDB in a way that is authoritative
(i.e. based on Microsoft's understanding of the PDB format, and not
LLVM's). To this end, I've added support for dumping injected sources
via DIA. I made a PDB file that used the /natvis option to generate a
test case.
Differential Revision: https://reviews.llvm.org/D44405
llvm-svn: 327428
Since r327420, the tool can query the MCSchedModel interface to obtain the
reciprocal throughput information.
As a consequence, method `ResourceManager::getRThroughput`, and
method `Backend::getRThroughput` are no longer needed.
This patch simplifies the code by removing the custom RThroughput computation.
This patch also refactors class SummaryView by removing the dependency with
the Backend object.
No functional change intended.
llvm-svn: 327425
This is a follow-up to r327137 where we unified error handling for the
DwarfLinker. This replaces calls to errs() and outs() with the
appropriate ostream wrapper everywhere in dsymutil.
llvm-svn: 327411
This patch makes dsymutil perform analyzeContextInfo and CloneDIEs in
parallel. For the same object file, there is a dependency between the
two. However, we can do analyzeContextInfo for the next object file
while cloning DIEs for the current. This is exactly the approach taken
in this patch.
For WebCore, this leads to a performance improvement of 29% and for
clang we see similar results with at 32% improvement.
A big thanks to Pete Cooper who came up with the original idea and
the PoC.
Differential revision: https://reviews.llvm.org/D43945
llvm-svn: 327399
Summary: This is a first step towards making the pipeline configurable.
Subscribers: llvm-commits, andreadb
Differential Revision: https://reviews.llvm.org/D44309
llvm-svn: 327389
This patch introduces the LinkContext which is necessary to have
dsymutil perform analysis and cloning of DIEs in parallel. As requested
in D43945, I'm landing this as two separate commits.
llvm-svn: 327382
This diff extends the output of -elf-section-groups
(llvm style, gnu style is unchanged since it's meant to be
compatible with binutils readelf) with sh_link and sh_info.
This change will enable us to use llvm-readobj -elf-section-groups
for testing llvm-objcopy's support for .group sections.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D44280
llvm-svn: 327341
Clean up the parsing of notes in llvm-readobj, improve bounds checking, and
allow the parsing code to be reused.
Differential Revision: https://reviews.llvm.org/D43958
llvm-svn: 327320
This change removes method Backend::getProcResourceMasks() and simplifies some
logic in the Views. This effectively removes yet another dependency between the
views and the Backend.
No functional change intended.
llvm-svn: 327214
Summary:
Add a new option -df to llvm-objdump that takes function names
as arguments and instructs the disassembler to only dump those function
contents. Based on code originally written by Bill Nell.
Reviewers: espindola, JDevlieghere
Differential Revision: https://reviews.llvm.org/D44224
llvm-svn: 327164
We improved the handling of errors and warnings in dwarfdump's verifier
in rL314498. This patch does the same thing for dsymutil.
Differential revision: https://reviews.llvm.org/D44052
llvm-svn: 327137
lib/WindowsManifest/CMakeLists.txt adds it to LLVM_SYSTEM_LIBS on that
target, but it was never getting picked up in
tools/llvm-config/CMakeLists.txt.
Differential Revision: https://reviews.llvm.org/D44302
llvm-svn: 327135
Summary:
Even though the getDIEOffset offset function was common for the two
accelerator table implementations, it was doing two different things:
for the Apple tables, it was returning the die offset relative to the
start of the section, whereas for DWARF v5 tables, it was relative to
the start of the CU.
I resolve this by renaming the function to getDIESectionOffset to make
it obvious what the function returns, and change the DWARF
implementation to return the section offset. I also keep the CU-relative
accessor, but only in the DWARF implementation (there is no way to get
this information for the Apple tables). This was not caught by existing
tests because the hand-written inputs also erroneously used section
offsets instead of CU-relative ones.
While looking at this, I noticed that the Apple implementation was not
fully correct either -- the header contains a DIEOffsetBase field, which
should be added to offsets encoded with the DW_FORM_ref*** family, but
this was not being used. This went unnoticed because all current writers
set this field to zero anyway. I fix this as well and add a hand-written
test which demonstrates the issue.
Reviewers: JDevlieghere, dblaikie
Subscribers: aprantl, llvm-commits
Differential Revision: https://reviews.llvm.org/D44202
llvm-svn: 327116
from core files. I tested this against the couple of core files that were
getting errors about unknown thread flavors and it now produce the same output as
the Xcode otool-classic(1) tool. Since the core files are huge I didn’t include
them as test cases.
rdar://38216356
llvm-svn: 327077
This patch fixes a problem found when testing zero latency instructions on
target AArch64 -mcpu=exynos-m3 / -mcpu=exynos-m1.
On Exynos-m3/m1, direct branches are zero-latency instructions that don't consume
any processor resources. The DispatchUnit marks zero-latency instructions as
"executed", so that no scheduling is required. The event of instruction
executed is then notified to all the listeners, and the reorder buffer (managed
by the RetireControlUnit) is updated. In particular, the entry associated to the
zero-latency instruction in the reorder buffer is marked as executed.
Before this patch, the DispatchUnit forgot to assign a retire control unit token
(RCUToken) to the zero-latency instruction. As a consequence, the RCUToken was
used uninitialized. This was causing a crash in the RetireControlUnit logic.
Fixes PR36650.
llvm-svn: 327056
This allows the customization of the performance report.
Users can specify their own custom sequence of views.
Each view contributes a portion of the performance report generated by the
BackendPrinter.
Internally, class BackendPrinter keeps a sequence of views; views are printed
out in sequence when method 'printReport()' is called.
This patch addresses one of the two review comments from Clement in D43951.
llvm-svn: 327018
llvm-mca is an LLVM based performance analysis tool that can be used to
statically measure the performance of code, and to help triage potential
problems with target scheduling models.
llvm-mca uses information which is already available in LLVM (e.g. scheduling
models) to statically measure the performance of machine code in a specific cpu.
Performance is measured in terms of throughput as well as processor resource
consumption. The tool currently works for processors with an out-of-order
backend, for which there is a scheduling model available in LLVM.
The main goal of this tool is not just to predict the performance of the code
when run on the target, but also help with diagnosing potential performance
issues.
Given an assembly code sequence, llvm-mca estimates the IPC (instructions per
cycle), as well as hardware resources pressure. The analysis and reporting style
were mostly inspired by the IACA tool from Intel.
This patch is related to the RFC on llvm-dev visible at this link:
http://lists.llvm.org/pipermail/llvm-dev/2018-March/121490.html
Differential Revision: https://reviews.llvm.org/D43951
llvm-svn: 326998
Summary:
Original change was D43313 (r326932) and reverted by r326953 because it
broke an LLD test and a windows build. The LLD test was already fixed in
lld commit r326944 (thanks maskray). This is the original change with
the windows build fixed.
llvm-svn: 326970
Currently on Windows (_MSC_VER) LLVMSymbolizer supports only Microsoft mangling.
This fix just explicitly uses itaniumDemangle when mangled name starts with _Z.
Differential Revision: https://reviews.llvm.org/D44192
llvm-svn: 326959
Because of -ffunction-sections (and maybe other use cases I'm not aware of?) it
can occur that we need more than 0xfeff sections but ELF dosn't support that
many sections. To solve this problem SHN_XINDEX exists and with it come a whole
host of changes for section indexes everywhere. This change adds support for
those cases which should allow llvm-objcopy to copy binaries that have an
arbitrary number of sections.
Differential Revision: https://reviews.llvm.org/D42516
llvm-svn: 326940
This patch enhances DWARFDebugFrame with the capability of parsing and
printing DWARF expressions in CFI instructions. It also makes FDEs and
CIEs accessible to lib users, so they can process them in client tools
that rely on LLVM. To make it self-contained with a test case, it
teaches llvm-readobj to be able to dump EH frames and checks they are
correct in a unit test. The llvm-readobj code is Maksim Panchenko's work
(maksfb).
Reviewers: JDevlieghere, espindola
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D43313
llvm-svn: 326932
Summary: This avoids crashing when a user tries to dump a pdb with the `-native` option.
Reviewers: zturner, llvm-commits, rnk
Reviewed By: zturner
Subscribers: mgrang
Differential Revision: https://reviews.llvm.org/D44117
llvm-svn: 326863
Fixes the bug found by asan. Also XFAIL the new test for Darwin,
which is stuck on DWARF v2, and fix up other tests so they stop
failing on Windows.
llvm-svn: 326839
* Move printing from llvm-mc to the AsmToken class, so that it can be used elsewhere.
* Add 5 cases which were missed: BigNum, Comment, HashDirective, Space and
BackSlash, and remove the default case so that -Wswitch will catch this error
in future.
This is almost NFC, except for the fact that llvm-mc can now print those 5
tokens in -as-lex mode.
Differential revision: https://reviews.llvm.org/D43936
llvm-svn: 326794
DWARF v5 specifies that the root file (also given in the DW_AT_name
attribute of the compilation unit DIE) should be emitted explicitly to
the line table's list of files. This makes the line table more
independent of the .debug_info section.
Differential Revision: https://reviews.llvm.org/D44054
llvm-svn: 326758
- thinlto_codegen_set_cache_size_bytes to control the absolute size of cache directory.
- thinlto_codegen_set_cache_size_files the size and amount of files in cache directory.
These functions have been supported in C++ LTO API for a long time, but were absent in C LTO API.
Differential Revision: https://reviews.llvm.org/D42446
llvm-svn: 326537
The original BinaryEncoding.md document used to specify that
these values were `varint7`, but the official spec lists them
explicitly as single byte values and not LEB.
A similar change for wabt is in flight:
https://github.com/WebAssembly/wabt/pull/782
Differential Revision: https://reviews.llvm.org/D43921
llvm-svn: 326454
The DwarfLinker implementation is already relatively large with over 4k
LOC. This commit moves the implementation of NonRelocatableStringpool
into a separate cpp file.
llvm-svn: 326425
Summary:
Processing 2 GB XRay traces with "llvm-xray convert -symbolize" needs to
go over each trace record and symbolize the function name refered to by
its ID. Currently this happens by asking the LLVM symbolizer code every
single time. A simple cache can save around 30 minutes of processing of
that trace.
llvm-xray's resident memory usage increased negligibly with this cache.
Reviewers: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D43896
llvm-svn: 326407
Add a `LLVM_INSTALL_CCTOOLS_SYMLINKS` to mirror
`LLVM_INSTALL_BINUTILS_SYMLINKS`. For now, this allows us to create
symlinks for `dsymutil` to `llvm-dsymutil`. This option is off by
default, but the user can enable it.
llvm-svn: 326381
Neither the linker nor the runtime need this information
anymore. We were originally using this to model BSS size
but the plan is now to use the segment metadata to allow
for BSS segments.
Differential Revision: https://reviews.llvm.org/D41366
llvm-svn: 326267
Following DW_AT_sibling attributes completely defeats the pruning pass.
Although clang doesn't generate the DW_AT_sibling attribute we should
still handle it correctly.
Differential revision: https://reviews.llvm.org/D43439
llvm-svn: 326231
- an ambiguous reference to Optional<T> in llvm-dwarfdump.cpp (fixed
with an explicit prefix).
- a missing base class initialization in Entry copy constructor (fixed
by using the implicitly default constructor, which is possible after
some changes which were done during review).
llvm-svn: 326006
This diff fixes the name of the argument of
setSymTab and makes setSymTab/setStrTab private
(to make the public interface a bit cleaner).
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D43661
llvm-svn: 326005
Summary:
This patch implements the name lookup functionality of the .debug_names
accelerator table and hooks it up to "llvm-dwarfdump -find". To make the
interface of the two kinds of accelerator tables more consistent, I've
created an abstract "DWARFAcceleratorTable::Entry" class, which provides
a consistent interface to access the common functionality of the table
entries (such as getting the die offset, die tag, etc.). I've also
modified the apple table to vend entries conforming to this interface.
Reviewers: JDevlieghere, aprantl, probinson, dblaikie
Subscribers: vleschuk, clayborg, echristo, llvm-commits
Differential Revision: https://reviews.llvm.org/D43067
llvm-svn: 326003
In DWARF v5 the Line Number Program Header is extensible, allowing values with
new content types. In this extension a content type is added,
DW_LNCT_LLVM_source, which contains the embedded source code of the file.
Add new optional attribute for !DIFile IR metadata called source which contains
source text. Use this to output the source to the DWARF line table of code
objects. Analogously extend METADATA_FILE in Bitcode and .file directive in ASM
to support optional source.
Teach llvm-dwarfdump and llvm-objdump about the new values. Update the output
format of llvm-dwarfdump to make room for the new attribute on file_names
entries, and support embedded sources for the -source option in llvm-objdump.
Differential Revision: https://reviews.llvm.org/D42765
llvm-svn: 325970
This is combination of two patches by Nicholas Wilson:
1. https://reviews.llvm.org/D41954
2. https://reviews.llvm.org/D42495
Along with a few local modifications:
- One change I made was to add the UNDEFINED bit to the binary format
to avoid the extra byte used when writing data symbols. Although this
bit is redundant for other symbols types (i.e. undefined can be
implied if a function or global is a wasm import)
- I prefer to be explicit and consistent and not have derived flags.
- Some field renaming.
- Some reverting of unrelated minor changes.
- No test output differences.
Differential Revision: https://reviews.llvm.org/D43147
llvm-svn: 325860
Summary:
The built-in PDB types enum has been extended to include char16_t and char32_t.
llvm-pdbutil was hitting an llvm_unreachable because it didn't know about these
new values. The new values are not yet in the DIA documentation, but are
listed in the cvconst.h header that comes as part of the DIA SDK.
Reviewers: asmith, zturner, rnk
Subscribers: stella.stamenova, llvm-commits, sanjoy
Differential Revision: https://reviews.llvm.org/D43646
llvm-svn: 325838
Summary:
As pointed out in the review for D37993, for consistency with other
linkers, gold plugin should perform cache pruning whenever there is a
cache directory specified, which will use the default cache policy.
Reviewers: pcc
Subscribers: llvm-commits, inglorion
Differential Revision: https://reviews.llvm.org/D43389
llvm-svn: 325830
Summary:
ThinLTO indexing may decide to skip all objects. If we don't write something to
the list build system may consider this as failure or linker can reuse a file
from the previews build.
Reviewers: pcc, tejohnson
Subscribers: mehdi_amini, inglorion, eraman, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D43415
llvm-svn: 325819
Calling realpath is expensive but necessary to perform the uniqueing in
dsymutil. Although we already cached the results for every individual
file in the line table, we had reports of it taking 40 seconds of a 3.5
minute link.
This patch adds a second level of caching. When we do have to call
realpath, we cache its result for its parents path. We didn't replace
the existing caching, because it's fast (indexed) and saves us from
reading the line table for entries we've already seen.
For WebkitCore this results in a decrease of 11% in linking time: from
85.79 to 76.11 seconds (average over 3 runs).
Differential revision: https://reviews.llvm.org/D43511
llvm-svn: 325757
Summary:
With D43396, no clients use the Path parameter anymore.
Depends on D43396.
Reviewers: pcc
Subscribers: mehdi_amini, inglorion, llvm-commits
Differential Revision: https://reviews.llvm.org/D43400
llvm-svn: 325619
Summary:
This will avoid the race condition described in the review for D37993.
I believe that the Path parameter to AddBufferFn is no longer utilized.
I would prefer to remove that as a follow up clean up patch to reduce
the diffs in this patch.
Reviewers: pcc
Reviewed By: pcc
Subscribers: inglorion, llvm-commits
Differential Revision: https://reviews.llvm.org/D43396
llvm-svn: 325618
This patch contains logic for handling DW_TAG_label that's present in
darwin's dsymutil implementation, but not yet upstream.
Differential revision: https://reviews.llvm.org/D43438
llvm-svn: 325600
This is the second part of recommit of r325224. The previous part was
committed in r325426, which deals with C++ memory allocation. Solution
for C memory allocation involved functions `llvm::malloc` and similar.
This was a fragile solution because it caused ambiguity errors in some
cases. In this commit the new functions have names like `llvm::safe_malloc`.
The relevant part of original comment is below, updated for new function
names.
Analysis of fails in the case of out of memory errors can be tricky on
Windows. Such error emerges at the point where memory allocation function
fails, but manifests itself when null pointer is used. These two points
may be distant from each other. Besides, next runs may not exhibit
allocation error.
In some cases memory is allocated by a call to some of C allocation
functions, malloc, calloc and realloc. They are used for interoperability
with C code, when allocated object has variable size and when it is
necessary to avoid call of constructors. In many calls the result is not
checked for null pointer. To simplify checks, new functions are defined
in the namespace 'llvm': `safe_malloc`, `safe_calloc` and `safe_realloc`.
They behave as corresponding standard functions but produce fatal error if
allocation fails. This change replaces the standard functions like 'malloc'
in the cases when the result of the allocation function is not checked
for null pointer.
Finally, there are plain C code, that uses malloc and similar functions. If
the result is not checked, assert statement is added.
Differential Revision: https://reviews.llvm.org/D43010
llvm-svn: 325551
Summary:
The current implementation was writing the file name without the extension
whereas GNU objcopy writes the full filename. With this change GDB will now
load the .debug file instead of silently ignoring it.
Reviewers: jakehehrlich, jhenderson
Reviewed By: jakehehrlich
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D43474
llvm-svn: 325528
Summary:
This commit separates the abstract accelerator table data structure
from the code for writing out an on-disk representation of a specific
accelerator table format. The idea is that former (now called
AccelTable<T>) can be reused for the DWARF v5 accelerator tables
as-is, without any further customizations.
Some bits of the emission code (now living in the EmissionContext class)
can be reused for DWARF v5 as well, but the subtle differences in the
layout of various subtables mean the sharing is not always possible.
(Also, the individual emit*** functions are fairly simple so there's a
tradeoff between making a bigger general-purpose function, and two
smaller targeted functions.)
Another advantage of this setup is that more of the serialization logic
can be hidden in the .cpp file -- I have moved declarations of the
header and all the emission functions there.
Reviewers: JDevlieghere, aprantl, probinson, dblaikie
Subscribers: echristo, clayborg, vleschuk, llvm-commits
Differential Revision: https://reviews.llvm.org/D43285
llvm-svn: 325516
Summary:
Gold plugin does not add pass to ThinLTO modules without useful symbols.
In this case ThinLTO can't create corresponding index file and some features, like CFI,
cannot be processes by backed correctly without index.
Given that we don't need the backed output we can request it to avoid
processing the module. This is implemented by this patch using new
"SkipModuleByDistributedBackend" flag.
Reviewers: pcc, tejohnson
Subscribers: mehdi_amini, inglorion, eraman, cfe-commits
Differential Revision: https://reviews.llvm.org/D42995
llvm-svn: 325411
This was originally reported as a bug with the symptom being "cvdump
crashes when printing an LLD-linked PDB that has an S_FILESTATIC record
in it". After some additional investigation, I determined that this was
a symptom of a larger problem, and in fact the real problem was in the
way we emitted the global PDB string table. As evidence of this, you can
take any lld-generated PDB, run cvdump -stringtable on it, and it would
return no results.
My hypothesis was that cvdump could not *find* the string table to begin
with. Normally it would do this by looking in the "named stream map",
finding the string /names, and using its value as the stream index. If
this lookup fails, then cvdump would fail to load the string table.
To test this hypothesis, I looked at the name stream map generated by a
link.exe PDB, and I emitted exactly those bytes into an LLD-generated
PDB. Suddenly, cvdump could read our string table!
This code has always been hacky and we knew there was something we
didn't understand. After all, there were some comments to the effect of
"we have to emit strings in a specific order, otherwise things don't
work". The key to fixing this was finally understanding this.
The way it works is that it makes use of a generic serializable hash map
that maps integers to other integers. In this case, the "key" is the
offset into a buffer, and the value is the stream number. If you index
into the buffer at the offset specified by a given key, you find the
name. The underlying cause of all these problems is that we were using
the identity function for the hash. i.e. if a string's offset in the
buffer was 12, the hash value was 12. Instead, we need to hash the
string *at that offset*. There is an additional catch, in that we have
to compute the hash as a uint32 and then truncate it to uint16.
Making this work is a little bit annoying, because we use the same hash
table in other places as well, and normally just using the identity
function for the hash function is actually what's desired. I'm not
totally happy with the template goo I came up with, but it works in any
case.
The reason we never found this bug through our own testing is because we
were building a /parallel/ hash table (in the form of an
llvm::StringMap<>) and doing all of our lookups and "real" hash table
work against that. I deleted all of that code and now everything goes
through the real hash table. Then, to test it, I added a unit test which
adds 7 strings and queries the associated values. I test every possible
insertion order permutation of these 7 strings, to verify that it really
does work as expected.
Differential Revision: https://reviews.llvm.org/D43326
llvm-svn: 325386
Analysis of fails in the case of out of memory errors can be tricky on
Windows. Such error emerges at the point where memory allocation function
fails, but manifests itself when null pointer is used. These two points
may be distant from each other. Besides, next runs may not exhibit
allocation error.
Usual programming practice does not require checking result of 'operator
new' because it throws 'std::bad_alloc' in the case of allocation error.
However, LLVM is usually built with exceptions turned off, so 'new' can
return null pointer. This change installs custom new handler, which causes
fatal error in the case of out of memory. The handler is installed
automatically prior to call to 'main' during construction of a static
object defined in 'lib/Support/ErrorHandling.cpp'. If the application does
not use this file, the handler may be installed manually by a call to
'llvm::install_out_of_memory_new_handler', declared in
'include/llvm/Support/ErrorHandling.h".
There are calls to C allocation functions, malloc, calloc and realloc.
They are used for interoperability with C code, when allocated object has
variable size and when it is necessary to avoid call of constructors. In
many calls the result is not checked against null pointer. To simplify
checks, new functions are defined in the namespace 'llvm' with the
same names as these C function. These functions produce fatal error if
allocation fails. User should use 'llvm::malloc' instead of 'std::malloc'
in order to use the safe variant. This change replaces 'std::malloc'
in the cases when the result of allocation function is not checked against
null pointer.
Finally, there are plain C code, that uses malloc and similar functions. If
the result is not checked, assert statements are added.
Differential Revision: https://reviews.llvm.org/D43010
llvm-svn: 325224
Some ELF files produced by lld may have zero-size segment placeholders as shown
below. Since GNU_STACK Offset is 0, the current code makes it the lowest used
offset, and relocates all the segments over the ELF header. The resulting
binary is total garbage.
This change fixes how llvm-objcopy handles PT_PHDR properlly by treating ELF
headers and the program header table as segments to allow the layout algorithm
decide where those should go.
Author: vit9696
Differential Revision: https://reviews.llvm.org/D42872
llvm-svn: 325189
Summary:
TypeID summaries are used by CFI and need to be serialized by ThinLTO
indexing for later use by LTO Backend.
Reviewers: tejohnson, pcc
Subscribers: mehdi_amini, inglorion, eraman, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D42611
llvm-svn: 325182
While there, change a bunch of helper functions to take references to
avoid adding calls to get().
This should conclude the bugpoint yak shaving.
llvm-svn: 325177
The change implements constructor of DisassembleInfo to avoid duplication
of initialization code and gets rid of malloc/free where possible.
Differential Revision: https://reviews.llvm.org/D43003
llvm-svn: 325098
Summary:
This protects calls to longjmp from transferring control to arbitrary
program points. Instead, longjmp calls are limited to the set of
registered setjmp return addresses.
This also implements /guard:nolongjmp to allow users to link in object
files that call setjmp that weren't compiled with /guard:cf. In this
case, the linker will approximate the set of address taken functions,
but it will leave longjmp unprotected.
I used the following program to test, compiling it with different -guard
flags:
$ cl -c t.c -guard:cf
$ lld-link t.obj -guard:cf
#include <setjmp.h>
#include <stdio.h>
jmp_buf buf;
void g() {
printf("before longjmp\n");
fflush(stdout);
longjmp(buf, 1);
}
void f() {
if (setjmp(buf)) {
printf("setjmp returned non-zero\n");
return;
}
g();
}
int main() {
f();
printf("hello world\n");
}
In particular, the program aborts when the code is compiled *without*
-guard:cf and linked with -guard:cf. That indicates that longjmps are
protected.
Reviewers: ruiu, inglorion, amccarth
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D43217
llvm-svn: 325047
If a function doesn't have an exact definition, don't apply debugify
metadata as it triggers a DIVerifier failure.
The issue is that it's invalid to have DILocations inside a DISubprogram
which isn't a definition ("scope points into the type hierarchy!").
llvm-svn: 325036
If the output file is not specified make the modifications in-place
(like binutils objcopy does). In particular, this fixes
the behavior of Clang -gsplit-dwarf (if Clang is configured to use llvm-objcopy),
previously it was creating .dwo files, but still leaving *dwo* sections in
the original binary.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D42873
llvm-svn: 324783
from the value stored in swift_version bits in the flags field in the
objc_image_info struct. ABI version 3 thru 6 were previously added but this
code was not updated to print the Swift version.
rdar://35624067
llvm-svn: 324767
Bugpoint will keep going even if the opt binary it's given doesn't
exist. It should at least alert the user, so it's clear why reductions
are failing.
llvm-svn: 324713
Handles were returned by addModule and used as keys for removeModule,
findSymbolIn, and emitAndFinalize. Their job is now subsumed by VModuleKeys,
which simplify resource management by providing a consistent handle across all
layers.
llvm-svn: 324700
Fix the comments, use early exits, use unique_ptr, and use ranged for
loops.
This is in preparation for a global *variable* reducer, which, with any
luck will help us clean up test cases.
Differential Revision: https://reviews.llvm.org/D43084
llvm-svn: 324649
When processing a dSYM bundle, use llvm::sys::path to join the different
path components instead of using a string with hard coded forward
slashes as separators.
llvm-svn: 324622
Before this patch, llvm-dwarfdump would reject `bundel.dSYM/` as input,
while `bundel.dSYM` was accepted. The reason is that `path::extension()`
returns an empty string for the former, leading to the argument not
being recognized as a dSYM bundle.
llvm-svn: 324621
This commit attempts to re-land the r324480 which was reverted in
r324493 because it broke the Windows bots. For now I disabled the two
update tests on Windows until I'm able to debug this.
Differential revision: https://reviews.llvm.org/D42880
llvm-svn: 324592
The LTO opt level should not affect the codegen opt level, and indeed
it does not affect it in lld. Ideally the codegen opt level should
be controlled by an IR-level attribute based on the compile-time opt
level, but that hasn't been implemented yet.
Differential Revision: https://reviews.llvm.org/D43040
llvm-svn: 324557
Now that dsymutil can generate accelerator tables, we can upstream the
update logic that, as the name implies, updates the accelerator tables
in an existing dSYM bundle. In combination with `-minimize` this can be
used to remove redundant .debug_(inlines|pubtypes|pubnames).
Differential revision: https://reviews.llvm.org/D42880
llvm-svn: 324480
Summary:
A recent fix to drop dead symbols (r323633) did not work for ThinLTO
distributed backends because we lose the WithGlobalValueDeadStripping
set on the index during the thin link. This patch adds a new flags
record to the bitcode format for the index, and serializes this flag
for the combined index (it would always be 0 for the per-module index
generated by the compile step, so no need to serialize the new flags
record there until/unless we add another flag that applies to the
per-module indexes).
Generally this flag should always be set for the distributed backends,
which are necessarily performed after the thin link. However, if we were
to simply set this flag on the index applied to the distributed backends
(invoked via clang), we would lose the ability to disable dead stripping
via -compute-dead=false for debugging purposes.
Reviewers: grimar, pcc
Subscribers: mehdi_amini, inglorion, eraman, llvm-commits
Differential Revision: https://reviews.llvm.org/D42799
llvm-svn: 324444
In particular this patch switches RTDyldObjectLinkingLayer to use
orc::SymbolResolver and threads the requried changse (ExecutionSession
references and VModuleKeys) through the existing layer APIs.
The purpose of the new resolver interface is to improve query performance and
better support parallelism, both in JIT'd code and within the compiler itself.
The most visibile change is switch of the <Layer>::addModule signatures from:
Expected<Handle> addModule(std::shared_ptr<ModuleType> Mod,
std::shared_ptr<JITSymbolResolver> Resolver)
to:
Expected<Handle> addModule(VModuleKey K, std::shared_ptr<ModuleType> Mod);
Typical usage of addModule will now look like:
auto K = ES.allocateVModuleKey();
Resolvers[K] = createSymbolResolver(...);
Layer.addModule(K, std::move(Mod));
See the BuildingAJIT tutorial code for example usage.
llvm-svn: 324405
Summary:
This update now allows users to specify `--blame-context` and `--blame-context-all` to print source file blame information for the source of the blame.
Also updates the inline printing to correctly identify the top of the inlining stack for blame information.
Patch by Mitch Phillips!
Reviewers: vlad.tsyrklevich
Subscribers: llvm-commits, kcc, pcc
Differential Revision: https://reviews.llvm.org/D40111
llvm-svn: 324035
Summary: Existing version doesn't work on Windows as it always prints 0.00.
Reviewers: Dor1s
Reviewed By: Dor1s
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42767
llvm-svn: 323923
For now, we are not using wasm globals, except for modeling of
the stack points.
Alos, factor out common struct WasmGlobalType, which matches the
name for that tuple in the Wasm spec and rename methods
to "isBindingGlobal", "isTypeGlobal" to avoid ambiguity.
Patch by Nicholas Wilson!
Differential Revision: https://reviews.llvm.org/D42750
llvm-svn: 323901
When a the Apple link editor builds a kext bundle file type and the
value of the -miphoneos-version-min argument is significantly current
(like 11.0) then the (__TEXT,__text) section is changed to the
(__TEXT_EXEC,__text) section. So it would be nice for llvm-nm to
show symbols in that section with a type of T instead of the generic
type of S for some section other than text, data, etc.
rdar://36262205
llvm-svn: 323836
Sometimes users do not specify data layout in LLVM assembly and let llc set the
data layout by target triple after loading the LLVM assembly.
Currently the parser checks alloca address space no matter whether the LLVM
assembly contains data layout definition, which causes false alarm since the
default data layout does not contain the correct alloca address space.
The parser also calls verifier to check debug info and updating invalid debug
info. Currently there is no way to let the verifier to check debug info only.
If the verifier finds non-debug-info issues the parser will fail.
For llc, the fix is to remove the check of alloca addr space in the parser and
disable updating debug info, and defer the updating of debug info and
verification to be after setting data layout of the IR by target.
For other llvm tools, since they do not override data layout by target but
instead can override data layout by a command line option, an argument for
overriding data layout is added to the parser. In cases where data layout
overriding is necessary for the parser, the data layout can be provided by
command line.
Differential Revision: https://reviews.llvm.org/D41832
llvm-svn: 323826
Summary: ThinLTO may skip object for other reasons, e.g. if there is no summary.
Reviewers: pcc, eugenis
Subscribers: mehdi_amini, inglorion, eraman, llvm-commits
Differential Revision: https://reviews.llvm.org/D42514
llvm-svn: 323818
Passing -minimize to dsymutil prevents the emission of .debug_inlines,
.debug_pubnames, and .debug_pubtypes in favor of the Apple accelerator
tables.
The actual check in the DWARF linker was added in r323655. This patch
simply enables it.
Differential revision: https://reviews.llvm.org/D42688
llvm-svn: 323812
Summary:
It was a copy-paste typo, sorting only to the 90th percentile twice.
Now, it only sorts the array prefix once, and extracts what we need.
Reviewers: dberris, kpw, eizan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42690
llvm-svn: 323800
Introduce an extension to support passing linker options to the linker.
These would be ignored by older linkers, but newer linkers which support
this feature would be able to process the linker.
Emit a special discarded section `.linker-option`. The content of this
section is a pair of strings (key, value). The key is a type identifier for
the parameter. This allows for an argument free parameter that will be
processed by the linker with the value being the parameter. As an example,
`lib` identifies a library to be linked against, traditionally the `-l`
argument for Unix-based linkers with the parameter being the library name.
Thanks to James Henderson, Cary Coutant, Rafael Espinolda, Sean Silva
for the valuable discussion on the design of this feature.
llvm-svn: 323783
r323476 added support for DW_FORM_line_strp, and incorrectly made that
depend on having a DWARFUnit available. We shouldn't be tracking
.debug_line_str in DWARFUnit after all. After this patch, I can do an
NFC follow up and undo a bunch of the "plumbing" part of r323476.
Differential Revision: https://reviews.llvm.org/D42609
llvm-svn: 323691
This patch adds support for generating accelerator tables in dsymutil.
This feature was already present in our internal repository but not yet
upstreamed because it requires changes to the Apple accelerator table
implementation.
Differential revision: https://reviews.llvm.org/D42501
llvm-svn: 323655
Summary:
This commit renames DWARFAcceleratorTable to AppleAcceleratorTable to free up
the first name as an interface for the different accelerator tables.
Then I add a DWARFDebugNames class for the dwarf5 table.
Presently, the only common functionality of the two classes is the dump()
method, because this is the only method that was necessary to implement
dwarfdump -debug-names; and because the rest of the
AppleAcceleratorTable interface does not directly transfer to the dwarf5
tables (the main reason for that is that the present interface assumes
the tables are homogeneous, but the dwarf5 tables can have different
keys associated with each entry).
I expect to make the common interface richer as I add more functionality
to the new class (and invent a way to represent it in generic way).
In terms of sharing the implementation, I found the format of the two
tables sufficiently different to frustrate any attempts to have common
parsing or dumping code, so presently the implementations share just low
level code for formatting dwarf constants.
Reviewers: vleschuk, JDevlieghere, clayborg, aprantl, probinson, echristo, dblaikie
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42297
llvm-svn: 323638
Tests were working on my system because the old correct files were left over
and the new bug was that the output files were not being output at all.
Consequently the test work on my system but fail on any other system.
This reverts commit r323484.
llvm-svn: 323486
While writing code for input and output formats in llvm-objcopy it became
apparent that there was a code health problem. This change attempts to solve
that problem by refactoring the code to use Reader and Writer objects that can
read in different objects in different formats, convert them to a single shared
internal representation, and then write them to any other representation.
New classes:
Reader: the base class used to construct instances of the internal
representation
Writer: the base class used to write out instances of the internal
representation
ELFBuilder: a helper class for ELFWriter that takes an ELFFile and converts it
to a Object
SectionVisitor: it became necessary to remove writeSection from SectionBase
because, under the new Reader/Writer scheme, it's possible to convert between
ELF Types such as ELF32LE and ELF32BE. This isn't possible with writeSection
because it (dynamically) depends on the underlying section type *and*
(statically) depends on the ELF type. Bad things would happen if the underlying
sections for ELF32LE were used for writing to ELF64BE. To avoid this code smell
(which would have compiled, run, and output some nonsesnse) I decoupled writing
of sections from a class.
SectionWriter: This is just the ELFT templated implementation of
SectionVisitor. Many classes now have this class as a friend so that the
writing methods in this class can write out private data.
ELFWriter: This is the Writer that outputs to ELF
BinaryWriter: This is the Writer that outputs to Binary
ElfType: Because the ELF Type is not a part of the Object anymore we need a way
to construct the correct default Writer based on properties of the Reader. This
enum just keeps track of the ELF type of the input so it can be used as the
default output type as well.
Object has correspondingly undergone some serious changes as well. It now has
more generic methods for building and manipulating ELF binaries. This interface
makes ELFBuilder easy enough to use and will make the BinaryReader/Builder easy
to create as well. Most changes in this diff are cosmetic and deal with the
fact that a method has been moved from one class to another or a change from a
pointer to a reference. Almost no changes should result in a functional
difference (this is after all a refactor). One minor functional change was made
and the result can be seen in remove-shstrtab-error.test. The fact that it
fails hasn't changed but the error message has changed because that failure is
detected at a later point in the code now (because WriteSectionHeaders is a
property of the ElfWriter *not* a property of the Object). I'd say roughly
80-90% of this code is cosmetically different, 10-19% is different but
functionally the same, and 1-5% is functionally different despite not causing a
change in tests.
Differential Revision: https://reviews.llvm.org/D42222
llvm-svn: 323480
It was reverted after buildbot regressions.
Original commit message:
This allows relative block frequency of call edges to be passed
to the thinlink stage where it will be used to compute synthetic
entry counts of functions.
llvm-svn: 323460
Summary:
This allows relative block frequency of call edges to be passed to the
thinlink stage where it will be used to compute synthetic entry counts
of functions.
Reviewers: tejohnson, pcc
Subscribers: mehdi_amini, llvm-commits, inglorion
Differential Revision: https://reviews.llvm.org/D42212
llvm-svn: 323349
This is needed in order to use our StringPool entries in the Apple
accelerator tables.
As this is NFC we rely on the existing tests for correctness.
llvm-svn: 323339
Combine expression patterns to form expressions with fewer, simple instructions.
This pass does not modify the CFG.
For example, this pass reduce width of expressions post-dominated by TruncInst
into smaller width when applicable.
It differs from instcombine pass in that it contains pattern optimization that
requires higher complexity than the O(1), thus, it should run fewer times than
instcombine pass.
Differential Revision: https://reviews.llvm.org/D38313
llvm-svn: 323321
Summary:
Currently, there is no way to extract a basic block from a function easily. This patch
extends llvm-extract to extract the specified basic block(s).
Reviewers: loladiro, rafael, bogner
Reviewed By: bogner
Subscribers: hintonda, mgorny, qcolombet, llvm-commits
Differential Revision: https://reviews.llvm.org/D41638
llvm-svn: 323266
Opt's "-enable-debugify" mode adds an instance of Debugify at the
beginning of the pass pipeline, and an instance of CheckDebugify at the
end.
You can enable this mode with lit using: -Dopt="opt -enable-debugify".
Note that running test suites in this mode will result in many failures
due to strict FileCheck commands, etc.
It can be more useful to look for assertion failures which arise only
when Debugify is enabled, e.g to prove that we have (or do not have)
test coverage for some code path with debug info present.
Differential Revision: https://reviews.llvm.org/D41793
llvm-svn: 323256
We were a bit too trusting about the offsets encoded in MachO compact unwind
sections, so this passes every access through a bounds check just in case. It
prevents a few segfaults on malformed object files, if one should ever come
along.
Mostly to silence fuzzers in the vague hope they might be able to produce
something useful without the noise.
llvm-svn: 323198
This applies to most pipelines except the LTO and ThinLTO backend
actions - it is for use at the beginning of the overall pipeline.
This extension point will be used to add the GCOV pass when enabled in
Clang.
llvm-svn: 323166
Summary:
First, we need to explain the core of the vulnerability. Note that this
is a very incomplete description, please see the Project Zero blog post
for details:
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
The basis for branch target injection is to direct speculative execution
of the processor to some "gadget" of executable code by poisoning the
prediction of indirect branches with the address of that gadget. The
gadget in turn contains an operation that provides a side channel for
reading data. Most commonly, this will look like a load of secret data
followed by a branch on the loaded value and then a load of some
predictable cache line. The attacker then uses timing of the processors
cache to determine which direction the branch took *in the speculative
execution*, and in turn what one bit of the loaded value was. Due to the
nature of these timing side channels and the branch predictor on Intel
processors, this allows an attacker to leak data only accessible to
a privileged domain (like the kernel) back into an unprivileged domain.
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In many
cases, the compiler can simply use directed conditional branches and
a small search tree. LLVM already has support for lowering switches in
this way and the first step of this patch is to disable jump-table
lowering of switches and introduce a pass to rewrite explicit indirectbr
sequences into a switch over integers.
However, there is no fully general alternative to indirect calls. We
introduce a new construct we call a "retpoline" to implement indirect
calls in a non-speculatable way. It can be thought of loosely as
a trampoline for indirect calls which uses the RET instruction on x86.
Further, we arrange for a specific call->ret sequence which ensures the
processor predicts the return to go to a controlled, known location. The
retpoline then "smashes" the return address pushed onto the stack by the
call with the desired target of the original indirect call. The result
is a predicted return to the next instruction after a call (which can be
used to trap speculative execution within an infinite loop) and an
actual indirect branch to an arbitrary address.
On 64-bit x86 ABIs, this is especially easily done in the compiler by
using a guaranteed scratch register to pass the target into this device.
For 32-bit ABIs there isn't a guaranteed scratch register and so several
different retpoline variants are introduced to use a scratch register if
one is available in the calling convention and to otherwise use direct
stack push/pop sequences to pass the target address.
This "retpoline" mitigation is fully described in the following blog
post: https://support.google.com/faqs/answer/7625886
We also support a target feature that disables emission of the retpoline
thunk by the compiler to allow for custom thunks if users want them.
These are particularly useful in environments like kernels that
routinely do hot-patching on boot and want to hot-patch their thunk to
different code sequences. They can write this custom thunk and use
`-mretpoline-external-thunk` *in addition* to `-mretpoline`. In this
case, on x86-64 thu thunk names must be:
```
__llvm_external_retpoline_r11
```
or on 32-bit:
```
__llvm_external_retpoline_eax
__llvm_external_retpoline_ecx
__llvm_external_retpoline_edx
__llvm_external_retpoline_push
```
And the target of the retpoline is passed in the named register, or in
the case of the `push` suffix on the top of the stack via a `pushl`
instruction.
There is one other important source of indirect branches in x86 ELF
binaries: the PLT. These patches also include support for LLD to
generate PLT entries that perform a retpoline-style indirection.
The only other indirect branches remaining that we are aware of are from
precompiled runtimes (such as crt0.o and similar). The ones we have
found are not really attackable, and so we have not focused on them
here, but eventually these runtimes should also be replicated for
retpoline-ed configurations for completeness.
For kernels or other freestanding or fully static executables, the
compiler switch `-mretpoline` is sufficient to fully mitigate this
particular attack. For dynamic executables, you must compile *all*
libraries with `-mretpoline` and additionally link the dynamic
executable and all shared libraries with LLD and pass `-z retpolineplt`
(or use similar functionality from some other linker). We strongly
recommend also using `-z now` as non-lazy binding allows the
retpoline-mitigated PLT to be substantially smaller.
When manually apply similar transformations to `-mretpoline` to the
Linux kernel we observed very small performance hits to applications
running typical workloads, and relatively minor hits (approximately 2%)
even for extremely syscall-heavy applications. This is largely due to
the small number of indirect branches that occur in performance
sensitive paths of the kernel.
When using these patches on statically linked applications, especially
C++ applications, you should expect to see a much more dramatic
performance hit. For microbenchmarks that are switch, indirect-, or
virtual-call heavy we have seen overheads ranging from 10% to 50%.
However, real-world workloads exhibit substantially lower performance
impact. Notably, techniques such as PGO and ThinLTO dramatically reduce
the impact of hot indirect calls (by speculatively promoting them to
direct calls) and allow optimized search trees to be used to lower
switches. If you need to deploy these techniques in C++ applications, we
*strongly* recommend that you ensure all hot call targets are statically
linked (avoiding PLT indirection) and use both PGO and ThinLTO. Well
tuned servers using all of these techniques saw 5% - 10% overhead from
the use of retpoline.
We will add detailed documentation covering these components in
subsequent patches, but wanted to make the core functionality available
as soon as possible. Happy for more code review, but we'd really like to
get these patches landed and backported ASAP for obvious reasons. We're
planning to backport this to both 6.0 and 5.0 release streams and get
a 5.0 release with just this cherry picked ASAP for distros and vendors.
This patch is the work of a number of people over the past month: Eric, Reid,
Rui, and myself. I'm mailing it out as a single commit due to the time
sensitive nature of landing this and the need to backport it. Huge thanks to
everyone who helped out here, and everyone at Intel who helped out in
discussions about how to craft this. Also, credit goes to Paul Turner (at
Google, but not an LLVM contributor) for much of the underlying retpoline
design.
Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer
Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D41723
llvm-svn: 323155
For sections with different virtual and physical addresses, alignment and
placement in the output binary should be based on the physical address.
Ran into this problem with a bare metal ARM project where llvm-objcopy added a
lot of zero-padding before the .data section that had differing addresses. GNU
objcopy did not add the padding, and after this fix, neither does llvm-objcopy.
Update a test case so a section has different physical and virtual addresses.
Fixes B35708
Authored By: Owen Shaw (owenpshaw)
Differential Revision: https://reviews.llvm.org/D41619
llvm-svn: 323144
This frees up the first name to be used as an base class for the
apple table and the dwarf5 .debug_names accel table. The rename was
split off from D42297 (adding of debug_names support), which is still
under review.
llvm-svn: 323113
Summary:
Rename LLVM_CONFIG_EXE to LLVM_CONFIG_PATH, and avoid building it if
passed in by user. This is the same way CLANG_TABLEGEN and
LLVM_TABLEGEN are handled, e.g., when -DLLVM_OPTIMIZED_TABLEGEN=ON is
passed.
Differential Revision: https://reviews.llvm.org/D41806
llvm-svn: 323053
ExternalSymbolMap now stores the string key (rather than using a StringRef),
as the object file backing the key may be removed at any time.
llvm-svn: 323001
Bulk queries reduce IPC/RPC overhead for cross-process JITing and expose
opportunities for parallel compilation.
The two new query methods are lookupFlags, which finds the flags for each of a
set of symbols; and lookup, which finds the address and flags for each of a
set of symbols. (See doxygen comments for more details.)
The existing JITSymbolResolver class is renamed LegacyJITSymbolResolver, and
modified to extend the new JITSymbolResolver class using the following scheme:
- lookupFlags is implemented by calling findSymbolInLogicalDylib for each of the
symbols, then returning the result of calling getFlags() on each of these
symbols. (Importantly: lookupFlags does NOT call getAddress on the returned
symbols, so lookupFlags will never trigger materialization, and lookupFlags will
never call findSymbol, so only symbols that are part of the logical dylib will
return results.)
- lookup is implemented by calling findSymbolInLogicalDylib for each symbol and
falling back to findSymbol if findSymbolInLogicalDylib returns a null result.
Assuming a symbol is found its getAddress method is called to materialize it and
the result (if getAddress succeeds) is stored in the result map, or the error
(if getAddress fails) is returned immediately from lookup. If any symbol is not
found then lookup returns immediately with an error.
This change will break any out-of-tree derivatives of JITSymbolResolver. This
can be fixed by updating those classes to derive from LegacyJITSymbolResolver
instead.
llvm-svn: 322913
Get rid of DEBUG_FUNCTION_NAME symbols. When we actually debug
data, maybe we'll want somewhere to put it... but having a symbol
that just stores the name of another symbol seems odd.
It means you have multiple Symbols with the same name, one
containing the actual function and another containing the name!
Store the names in a vector on the WasmObjectFile when reading
them in. Also stash them on the WasmFunctions themselves.
The names are //not// "symbol names" or aliases or anything,
they're just the name that a debugger should show against the
function body itself. NB. The WasmObjectFile stores them so that
they can be exported in the YAML losslessly, and hence the tests
can be precise.
Enforce that the CODE section has been read in before reading
the "names" section. Requires minor adjustment to some tests.
Patch by Nicholas Wilson!
Differential Revision: https://reviews.llvm.org/D42075
llvm-svn: 322741
Summary:
- Fix a bug in PrettyBuiltinDumper that returns "void" as the name for
an unspecified builtin type. Since the unspecified param of a variadic
function is considered a builtin of unspecified type in PDBs, we set
"..." for its name.
- Provide a method to determine if a PDBSymbolFunc is variadic in
PrettyFunctionDumper since PDBSymbolFunc::getArgument() doesn't return the
last unspecified-type param.
- Add a pretty-func-dumper.test to test pretty dumping of variadic
functions.
Reviewers: zturner, llvm-commits
Reviewed By: zturner
Differential Revision: https://reviews.llvm.org/D41801
llvm-svn: 322608
Summary:
This speeds up export "summary-only" execution by an order of magnitude or two,
depending on number of threads used for prepareFileReports execution.
Also includes minor refactoring for splitting render of summary and detailed data
in two independent methods.
Reviewers: vsk, morehouse
Reviewed By: vsk
Subscribers: llvm-commits, kcc
Differential Revision: https://reviews.llvm.org/D42000
llvm-svn: 322397
There were a few places where outs() was being used
directly rather than the ScopedPrinter object.
Differential Revision: https://reviews.llvm.org/D41370
llvm-svn: 322141
These indexes are useful because they are not always zero based and
functions and globals are referenced elsewhere by their index.
This matches what we already do for the type index space.
Differential Revision: https://reviews.llvm.org/D41877
llvm-svn: 322121
llc, opt, and clang can all autodetect the CPU and supported features. lli cannot as far as I could tell.
This patch uses the getCPUStr() and introduces a new getCPUFeatureList() and uses those in lli in place of MCPU and MAttrs.
Ideally, we would merge getCPUFeatureList and getCPUFeatureStr, but opt and llc need a string and lli wanted a list. Maybe we should just return the SubtargetFeature object and let the caller decide what it needs?
Differential Revision: https://reviews.llvm.org/D41833
llvm-svn: 322100
This change adds support in llvm-objcopy for GNU objcopy's --localize-hidden
option. This option changes every hidden or internal symbol into a local symbol.
llvm-svn: 321884
This is not a record type that clang currently generates,
but it is a record that is encountered in object files generated
by cl. This record is unusual in that it refers directly to
the string table instead of indirectly to the string table via
the FileChecksums table. Because of this, it was previously
overlooked and we weren't remapping the string indices at all.
This would lead to crashes in MSVC when trying to display a
variable whose debug info involved an S_FILESTATIC.
Original bug report by Alexander Ganea
Differential Revision: https://reviews.llvm.org/D41718
llvm-svn: 321883
Summary:
Add a method `OptTable::findNearest`, which allows users of OptTable to
check user input for misspelled options. In addition, have llvm-mt
check for misspelled options. For example, if a user invokes
`llvm-mt /oyt:foo`, the error message will indicate that while an
option named `/oyt:` does not exist, `/out:` does.
The method ports the functionality of the `LookupNearestOption` method
from LLVM CommandLine to libLLVMOption. This allows tools like Clang
and Swift, which do not use CommandLine, to use this functionality to
suggest similarly spelled options.
As room for future improvement, the new method as-is cannot yet properly suggest
nearby "joined" options -- that is, for an option string "-FozBar", where
"-Foo" is the correct option name and "Bar" is the value being passed along
with the misspelled option, this method will calculate an edit distance of 4,
by deleting "Bar" and changing "z" to "o". It should instead calculate an edit
distance of just 1, by changing "z" to "o" and recognizing "Bar" as a
value. This commit includes a disabled test that expresses this limitation.
Test Plan: `check-llvm`
Reviewers: yamaguchi, v.g.vassilev, teemperor, ruiu, jroelofs
Reviewed By: jroelofs
Subscribers: jroelofs, llvm-commits
Differential Revision: https://reviews.llvm.org/D41732
llvm-svn: 321877
Summary:
Local testing has demonstrated a great speed improvement, compare the following:
1) Existing version:
```
$ time llvm-cov show -format=html -output-dir=report -instr-profile=... ...
The tool has been launched: 00:00:00
Loading coverage data: 00:00:00
Get unique source files: 00:00:33
Creating an index out of the source files: 00:00:34
Going into prepareFileReports: 00:00:34
Going to emit summary information for each file: 00:28:55 <-- 28:21 min!
Going to emit links to files with no function: 00:28:55
Launching 32 threads for generating HTML files: 00:28:55
real 37m43.651s
user 112m5.540s
sys 7m39.872s
```
2) Multi-threaded version with 32 CPUs:
```
$ time llvm-cov show -format=html -output-dir=report -instr-profile=... ...
The tool has been launched: 00:00:00
Loading coverage data: 00:00:00
Get unique source files: 00:00:38
Creating an index out of the source files: 00:00:40
Going into prepareFileReports: 00:00:40
Preparing file reports using 32 threads: 00:00:40
# Creating thread tasks for the following number of files: 16422
Going to emit summary information for each file: 00:01:57 <-- 1:17 min!
Going to emit links to files with no function: 00:01:58
Launching 32 threads for generating HTML files: 00:01:58
real 11m2.044s
user 134m48.124s
sys 7m53.388s
```
Reviewers: vsk, morehouse
Reviewed By: vsk
Subscribers: Dor1s, llvm-commits, kcc
Differential Revision: https://reviews.llvm.org/D41206
llvm-svn: 321871
Currently it's not possible to access MCSubtargetInfo from a TgtMCAsmBackend.
D20830 threaded an MCSubtargetInfo reference through
MCAsmBackend::relaxInstruction, but this isn't the only function that would
benefit from access. This patch removes the Triple and CPUString arguments
from createMCAsmBackend and replaces them with MCSubtargetInfo.
This patch just changes the interface without making any intentional
functional changes. Once in, several cleanups are possible:
* Get rid of the awkward MCSubtargetInfo handling in ARMAsmBackend
* Support 16-bit instructions when valid in MipsAsmBackend::writeNopData
* Get rid of the CPU string parsing in X86AsmBackend and just use a SubtargetFeature for HasNopl
* Emit 16-bit nops in RISCVAsmBackend::writeNopData if the compressed instruction set extension is enabled (see D41221)
This change initially exposed PR35686, which has since been resolved in r321026.
Differential Revision: https://reviews.llvm.org/D41349
llvm-svn: 321692
I have no clue how this was missed when symbol table support was added. This
change ensures that the visibility of symbols is preserved by default.
llvm-svn: 321681
This patch replaces a block of logic that was implemented using
CoreFoundations calls with functionally equivalent logic that makes use
of LLVM libraries.
llvm-svn: 321522
This change adds `printMipsGOT` and `printMipsPLT` methods to the
`DumpStyle` class and overrides them in the `GNUStyle` and `LLVMStyle`
descendants. To pass information about GOT/PLT layout into these
methods, the `MipsGOTParser` class has been extended to hold all
necessary data.
llvm-svn: 321253
borked by: rL284966 (see: https://reviews.llvm.org/D25730).
Previously, Interval was unsigned (see: CachePruning.h), replacing the type with std::chrono::seconds (which is signed) causes a regression in behaviour because the c-api intends negative values to translate to large positive intervals to *effectively* disable the pruning (see comments on: setCachePruningInterval()).
Differential Revision: https://reviews.llvm.org/D41231
llvm-svn: 321077
Before this patch, dwarfdump's lookup parameter only accepts unsigned.
Given that for many current platforms the load address already exceeds
unsigned (e.g. arm64 w/ 0x100000000), dwarfdump needs an unsigned long
long parameter.
Patch by: Dr. Michael 'Mickey' Lauer <mickey@vanille-media.de>
llvm-svn: 321064
This change adds support for adding progbits sections with contents from a file
Differential Revision: https://reviews.llvm.org/D41212
llvm-svn: 321047
LLVM IR function names which disable mangling start with '\01'
(https://www.llvm.org/docs/LangRef.html#identifiers).
When an identifier like "\01@abc@" gets dumped to MIR, it is quoted, but
only with single quotes.
http://www.yaml.org/spec/1.2/spec.html#id2770814:
"The allowed character range explicitly excludes the C0 control block
allowed), the surrogate block #xD800-#xDFFF, #xFFFE, and #xFFFF."
http://www.yaml.org/spec/1.2/spec.html#id2776092:
"All non-printable characters must be escaped.
[...]
Note that escape sequences are only interpreted in double-quoted scalars."
This patch adds support for printing escaped non-printable characters
between double quotes if needed.
Should also fix PR31743.
Differential Revision: https://reviews.llvm.org/D41290
llvm-svn: 320996
Overtime some non-clang formatted code has creeped into llvm-objcopy. This
patch fixes all of that.
Differential Revision: https://reviews.llvm.org/D41262
llvm-svn: 320856
Summary:
llvm-objdump's Mach-O parser was updated in r306037 to display external
relocations for MH_KEXT_BUNDLE file types. This change extends the Macho-O
parser to display local relocations for MH_PRELOAD files. When used with
the -macho option relocations will be displayed in a historical format.
All tests are passing for llvm, clang, and lld. llvm-objdump builds without
compiler warnings.
rdar://35778019
Reviewers: enderby
Reviewed By: enderby
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41199
llvm-svn: 320832
This is a special code that indicates that it's a function id.
While I'm still not certain how to interpret these, we definitely
should *not* be using these values as indices into an array directly.
For now, when we encounter one of these, just print the numeric value.
llvm-svn: 320775
This is a Swift feature. The output stream for the index page and the source
HTML page is utf-8 now.
The next patch will add the HTML magic to properly render these characters in
the browser.
llvm-svn: 320725
Threading was disabled in r317263 because it broke a test in combination
with `-DLLVM_ENABLE_THREADS=OFF`. This was because a ThreadPool warning
was piped to llvm-dwarfdump which was expecting to read an object from
stdin.
This patch re-enables threading and fixes the offending test.
Unfortunately this required more than just moving the ThreadPool out of
the for loop because of the TempFile refactoring that took place in the
meantime.
Differential revision: https://reviews.llvm.org/D41180
llvm-svn: 320601
Summary:
llvm-objdump's Mach-O parser was updated in r306037 to display external
relocations for MH_KEXT_BUNDLE file types. This change extends the Macho-O
parser to display local relocations for MH_PRELOAD files. When used with
the -macho option relocations will be displayed in a historical format.
rdar://35778019
Reviewers: enderby
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41061
llvm-svn: 320532
This patch removes the hard-coded check for DWARFv2 line tables. Now
dsymutil accepts line tables for DWARF versions 2 to 5 (inclusive).
Differential revision: https://reviews.llvm.org/D41084
rdar://35968319
llvm-svn: 320469
Summary:
That allows to get the same data as produced by "llvm-cov report",
but in JSON format, which is better for further processing by end users.
Reviewers: vsk
Reviewed By: vsk
Differential Revision: https://reviews.llvm.org/D41085
llvm-svn: 320435
The Debugify pass synthesizes debug info for IR. It's paired with a
CheckDebugify pass which determines how much of the original debug info
is preserved. These passes make it easier to create targeted tests for
debug info preservation.
Here is the Debugify algorithm:
NextLine = 1
for (Instruction &I : M)
attach DebugLoc(NextLine++) to I
NextVar = 1
for (Instruction &I : M)
if (canAttachDebugValue(I))
attach dbg.value(NextVar++) to I
The CheckDebugify pass expects contiguous ranges of DILocations and
DILocalVariables. If it fails to find all of the expected debug info, it
prints a specific error to stderr which can be FileChecked.
This was discussed on llvm-dev in the thread:
"Passes to add/validate synthetic debug info"
Differential Revision: https://reviews.llvm.org/D40512
llvm-svn: 320202
Summary:
llvm-objdump's Mach-O parser was updated in r306037 to display external
relocations for MH_KEXT_BUNDLE file types. This change extends the Macho-O
parser to display local relocations for MH_PRELOAD files. When used with
the -macho option relocations will be displayed in a historical format.
rdar://35778019
Reviewers: enderby
Reviewed By: enderby
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40867
llvm-svn: 320166
This patch adds support for running the DWARF verifier on the linked
debug info files. If the -verify options is specified and verification
fails, dsymutil exists with abort with non-zero exit code. This behavior
is *not* enabled by default.
Differential revision: https://reviews.llvm.org/D40777
llvm-svn: 320033
Most likely, this is not how we want to handle this in the long term. This
code should probably be in the Swift repo and somehow plugged into the
opt-viewer. This is still however very experimental at this point so I don't
want to over-engineer it at this point.
llvm-svn: 319902
We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.
Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.
Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).
Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.
Differential Revision: https://reviews.llvm.org/D40823
llvm-svn: 319840
If a linked binary file contains a dynamic section, the GOT layout
defined by the dynamic section entries. In a statically linked file
the GOT is just a series of entries. This change teaches `llvm-readobj`
to print the GOT in that case. That provides a feature parity with GNU
`readelf`.
llvm-svn: 319616
CMake's generated installation scripts support `CMAKE_INSTALL_DO_STRIP`
to enable stripping the installed binaries. LLVM's build system doesn't
expose this option to the `install-` targets, but it's useful in
conjunction with `install-distribution`.
Add a new function to create the install targets, which creates both the
regular install target and a second install target that strips during
installation. Change the creation of all installation targets to use
this new function. Stripping doesn't make a whole lot of sense for some
installation targets (e.g. the LLVM headers), but consistency doesn't
hurt.
I'll make other repositories (e.g. clang, compiler-rt) use this in a
follow-up, and then add an `install-distribution-stripped` target to
actually accomplish the end goal of creating a stripped distribution. I
don't want to do that step yet because the creation of that target would
depend on the presence of the `install-*-stripped` target for each
distribution component, and the distribution components from other
repositories will be missing that target right now.
Differential Revision: https://reviews.llvm.org/D40620
llvm-svn: 319480
This change adds support for the --only-keep option and the -j alias as well.
A common use case for these being used together is to dump a specific section's
data. Additionally the --keep option is added (GNU objcopy doesn't have this)
to avoid removing a bunch of things. This allows people to err on the side of
stripping aggressively and then to keep the specific bits that they need for
their application.
Differential Revision: https://reviews.llvm.org/D39021
llvm-svn: 319467
This patch implements `getBundleInfo`, which uses CoreFoundation to
obtain information about the CFBundle. This information is needed to
populate the Plist in the dSYM bundle.
This change only applies to darwin and is an NFC as far as other
platforms are concerned.
Differential revision: https://reviews.llvm.org/D40244
llvm-svn: 319416
A couple of places in LLD were passing references to
TypeTableCollections around, which makes it hard to change the
implementation at runtime. However, these cases only needed to
iterate over the types in the collection, and TypeCollection
already provides a handy abstract interface for this purpose.
By implementing this interface, we can get rid of the need to
pass TypeTableBuilder references around, which should allow us
to swap the implementation at runtime in subsequent patches.
llvm-svn: 319345
Detects whether we have the Python modules (pygments, yaml) required by
opt-viewer and hooks this up to REQUIRES.
This fixes https://bugs.llvm.org/show_bug.cgi?id=34129 (the lack of opt-viewer
testing).
It's also related to https://github.com/apple/swift/pull/12938 and the idea is
to expose LLVM_HAVE_OPT_VIEWER_MODULES to the Swift cmake.
Differential Revision: https://reviews.llvm.org/D40202
Fixes since the first commit:
1. Disable syntax highlighting as different versions of pygments generate
different HTML
2. Use llvm-cxxfilt from the build
llvm-svn: 319324
The motivation behind this patch is that future directions require us to
be able to compute the hash value of records independently of actually
using them for de-duplication.
The current structure of TypeSerializer / TypeTableBuilder being a
single entry point that takes an unserialized type record, and then
hashes and de-duplicates it is not flexible enough to allow this.
At the same time, the existing TypeSerializer is already extremely
complex for this very reason -- it tries to be too many things. In
addition to serializing, hashing, and de-duplicating, ti also supports
splitting up field list records and adding continuations. All of this
functionality crammed into this one class makes it very complicated to
work with and hard to maintain.
To solve all of these problems, I've re-written everything from scratch
and split the functionality into separate pieces that can easily be
reused. The end result is that one class TypeSerializer is turned into 3
new classes SimpleTypeSerializer, ContinuationRecordBuilder, and
TypeTableBuilder, each of which in isolation is simple and
straightforward.
A quick summary of these new classes and their responsibilities are:
- SimpleTypeSerializer : Turns a non-FieldList leaf type into a series of
bytes. Does not do any hashing. Every time you call it, it will
re-serialize and return bytes again. The same instance can be re-used
over and over to avoid re-allocations, and in exchange for this
optimization the bytes returned by the serializer only live until the
caller attempts to serialize a new record.
- ContinuationRecordBuilder : Turns a FieldList-like record into a series
of fragments. Does not do any hashing. Like SimpleTypeSerializer,
returns references to privately owned bytes, so the storage is
invalidated as soon as the caller tries to re-use the instance. Works
equally well for LF_FIELDLIST as it does for LF_METHODLIST, solving a
long-standing theoretical limitation of the previous implementation.
- TypeTableBuilder : Accepts sequences of bytes that the user has already
serialized, and inserts them by de-duplicating with a hash table. For
the sake of convenience and efficiency, this class internally stores a
SimpleTypeSerializer so that it can accept unserialized records. The
same is not true of ContinuationRecordBuilder. The user is required to
create their own instance of ContinuationRecordBuilder.
Differential Revision: https://reviews.llvm.org/D40518
llvm-svn: 319198
Since this isn't a real header - it includes static functions and had
external linkage variables (though this change makes them static, since
that's what they should be) so can't be included more than once in a
program.
llvm-svn: 319082
GNU's --strip-all doesn't strip as aggressively as it could in general.
Currently llvm-objcopy copies the exact behavoir of GNU's --strip-all.
eu-strip is used as a drop in replacement for GNU strip/objcopy in many many
places without issue. eu-strip removes non-allocated sections and keeps
.gnu.warning* sections. Because --strip-all will likely be the most widely
used stripping option we should make --strip-all as aggressive as it can safely
be. Since we have evidence from eu-strip that this is a safe option we should
allow it. For those that might still have an issue afterwards I've added
--strip-all-gnu as an exact drop in replacement for GNU's --strip-all as well.
llvm-svn: 319071
The refactoring in r318407 transiently includes abi-breaking.h
which defines EnableABIBreakingChecks. This breaks my Debug
build because this fuzzer did not link in Support with the symbol.
Differential Revision: https://reviews.llvm.org/D40190
llvm-svn: 318553
All these headers already depend on CodeGen headers so moving them into
CodeGen fixes the layering (since CodeGen depends on Target, not the
other way around).
llvm-svn: 318490
It turns out this #include isn't used from Host.h anyway,
but by having it it causes circular include dependencies.
This issues only surfaced while I was working on a separate
patch, so I'm submitting this first so that it's independent
of the other, unrelated patch.
llvm-svn: 318489
Removes AllocateRWX, setWritable and setExecutable from sys::Memory and
standardizes on allocateMappedMemory / protectMappedMemory. The
allocateMappedMemory method is updated to request full permissions for memory
blocks so that they can be marked executable later.
llvm-svn: 318464
Summary:
This change introduces a `DynamicSymbols` field to the ELF specific YAML
supported by `yaml2obj` and `obj2yaml`. This grouping of symbols provides a way
to represent ELF dynamic symbols. The `DynamicSymbols` structure is identical to
the existing `Symbols`.
Reviewers: compnerd, jakehehrlich, silvas
Reviewed By: silvas
Subscribers: silvas, jakehehrlich, llvm-commits
Differential Revision: https://reviews.llvm.org/D39582
llvm-svn: 318433
This moves the file handling out of DwarfLinker.cpp.
This fixes what is at least an oddity if not a bug. DwarfLinker.cpp
was using ToolOutputFile, which uses RemoveFileOnSignal. The issue is
that dsymutil.cpp uses that too. It is now clear from the interface
that only dsymutil.cpp is responsible for creating and deleting files.
llvm-svn: 318334
The original -O binary implementation just copied segment data from the
object and dumped it into a file. This doesn't take into account any
operations performed on objects such as section removal. GNU objcopy has
some specific behavior that we'd also like to respect. For instance
using -O binary and -j <some_section> will dump <some_section> to a
file. This change implements GNU objcopy style -O binary to as close of
an approximation as I can determine.
Differential Revision: https://reviews.llvm.org/D39713
llvm-svn: 318324
Summary:
This patch adds another failure mode for `validateCFIProtection(..)`, wherein any register that affects the indirect control flow instruction is clobbered to between the CFI-check and the instruction's execution.
Also includes a modification to make MCInstrDesc::hasDefOfPhysReg public.
Reviewers: vlad.tsyrklevich
Reviewed By: vlad.tsyrklevich
Subscribers: llvm-commits, pcc, kcc
Differential Revision: https://reviews.llvm.org/D39820
llvm-svn: 318238
Allows users to view GraphResult objects in a DOT directed-graph format. This feature can be turned on through the --print-graphs flag.
Also enabled pretty-printing of instructions in output. Together these features make analysis of unprotected CF instructions much easier by providing a visual control flow graph.
Reviewers: pcc
Subscribers: llvm-commits, kcc, vlad.tsyrklevich
Differential Revision: https://reviews.llvm.org/D39819
llvm-svn: 318211
Clang implements the -finstrument-functions flag inherited from GCC, which
inserts calls to __cyg_profile_func_{enter,exit} on function entry and exit.
This is useful for getting a trace of how the functions in a program are
executed. Normally, the calls remain even if a function is inlined into another
function, but it is useful to be able to turn this off for users who are
interested in a lower-level trace, i.e. one that reflects what functions are
called post-inlining. (We use this to generate link order files for Chromium.)
LLVM already has a pass for inserting similar instrumentation calls to
mcount(), which it does after inlining. This patch renames and extends that
pass to handle calls both to mcount and the cygprofile functions, before and/or
after inlining as controlled by function attributes.
Differential Revision: https://reviews.llvm.org/D39287
llvm-svn: 318195
I was being inconsistent with the way I was capitalizing help messages
for command line options. Additionally --remove-section wasn't using
value_desc even though it benefited from it.
Differential Revision: https://reviews.llvm.org/D39978
llvm-svn: 318190
They don't actually change nay behaviour, as llvm-strings currently
checks the whole object without looking at individual sections anyway.
This allows using llvm-strings in a context that explicitly passes
the -a option.
Differential Revision: https://reviews.llvm.org/D40020
llvm-svn: 318185
This change adds a new flag not present in GNU objcopy that we call
--strip-non-alloc.
Differential Revision: https://reviews.llvm.org/D39926
llvm-svn: 318168
We haven't been supporting anything but ELF64LE since the start. Luckily
this was always accounted for and the change is pretty trivial. B35281
requests this change for ELF32LE. This change adds support for ELF32LE,
ELF64BE, and ELF32BE with all supported features that already existed
for ELF64LE.
Differential Revision: https://reviews.llvm.org/D39977
llvm-svn: 318166
Many projects use this option. There are two ways to use it. You can
either a) Just use --strip-debug and keep the old file with debug
content or b) you can use --strip-debug, --only-keep-debug, and
--add-gnu-debuglink all in conjunction to create two separate files, the
stripped file and the debug file. --only-keep-debug is more complicated
than --strip-debug because it keeps the section headers without keeping
section contents. That's not really supported by llvm-objcopy at the
moment but I plan on adding it. So this change just supports a) and
options to support b) will come soon.
Differential Revision: https://reviews.llvm.org/D39919
llvm-svn: 318094
This change adds a slightly less extreme form of stripping. It should
remove any section that starts with ".debug" and should remove any
symbol table or relocations. In general this strips out most of the
stuff you don't need to execute but leaves a number of things around.
This behavior has been designed to be compatible with GNU strip/objcopy
--strip-all so that anywhere you currently use --strip-all you should be
able to use llvm-objcopy as a drop in replacement.
Differential Revision: https://reviews.llvm.org/D39769
llvm-svn: 318092
Also change some default cases into llvm_unreachable in
WindowsResourceCOFFWriter, to make it easier to find if they
are triggerd from within e.g. lld, which supported ARM64 earlier
than llvm-cvtres did.
Differential Revision: https://reviews.llvm.org/D39892
llvm-svn: 317942
Refactors the behaviour of building graphs out of FileAnalysis, allowing for analysis of the GraphResult by the callee without having to rebuild the graph. Means when we want to analyse the constructed graph (planned for later revisions), we don't do repeated work.
Also makes CFI verification in FileAnalysis now return an enum that allows us to differentiate why something failed, not just that it did/didn't fail.
Reviewers: vlad.tsyrklevich
Subscribers: kcc, pcc, llvm-commits
Differential Revision: https://reviews.llvm.org/D39764
llvm-svn: 317927
This change adds generic fuzzing tools capable of running libFuzzer tests on
any optimization pass or combination of them.
Differential Revision: https://reviews.llvm.org/D39555
llvm-svn: 317883
Summary:
This change allows yaml input to control the order of implicitly added sections
(`.symtab`, `.strtab`, `.shstrtab`). The order is controlled by adding a
placeholder section of the given name to the Sections field.
This change is to support changes in D39582, where it is desirable to control
the location of the `.dynsym` section.
This reapplied version fixes:
1. use of a function call within an assert
2. failing lld test which has an unnamed section
3. incorrect section count when given an unnamed section
Additionally, one more test to cover the unnamed section failure.
Reviewers: compnerd, jakehehrlich
Reviewed By: jakehehrlich
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39749
llvm-svn: 317789
We've worked around bugs in the frontend by ignoring the count from
wrapped segments when a line has at least one region entry segment.
Those frontend bugs are now fixed, so it's time to regenerate the
checked-in covmapping files and remove the workaround.
llvm-svn: 317761
Adds the blacklist behaviour to llvm-cfi-verify. Now will calculate which lines caused expected failures in the blacklist and reports the number of affected indirect CF instructions for each blacklist entry.
Also moved DWARF checking after instruction analysis to improve performance significantly - unrolling the inlining stack is expensive.
Reviewers: vlad.tsyrklevich
Subscribers: aprantl, pcc, kcc, llvm-commits
Differential Revision: https://reviews.llvm.org/D39750
llvm-svn: 317743
Summary:
This change allows yaml input to control the order of implicitly added sections
(`.symtab`, `.strtab`, `.shstrtab`). The order is controlled by adding a
placeholder section of the given name to the Sections field.
This change is to support changes in D39582, where it is desirable to control
the location of the `.dynsym` section.
This reapplied version fixes:
1. use of a function call within an assert
2. failing lld test which has an unnamed section
Additionally, one more test to cover the unnamed section failure.
Reviewers: compnerd, jakehehrlich
Reviewed By: jakehehrlich
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39749
llvm-svn: 317646
Summary:
This change allows yaml input to control the order of implicitly added sections
(`.symtab`, `.strtab`, `.shstrtab`). The order is controlled by adding a
placeholder section of the given name to the Sections field.
This change is to support changes in D39582, where it is desirable to control
the location of the `.dynsym` section.
Reviewers: compnerd, jakehehrlich
Reviewed By: jakehehrlich
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39749
llvm-svn: 317622
Minimal tool to convert xray traces to Chrome's Trace Event Format.
Summary:
Make use of Chrome Trace Event format's Duration events and stack frame dict to
produce Json files that chrome://tracing can visualize from xray function call
traces. Trace Event format is more robust and has several features like
argument logging, function categorization, multi process traces, etc. that we
can add as needed. Duration events cover an important base case.
Part of this change is rearranging the code so that the TrieNode data structure
can be used from multiple tools and can carry parameterized baggage on the
nodes. I put the actual behavior changes in llvm-xray convert exclusively.
Exploring the trace of instrumented llc was pretty nifty if overwhelming.
I can envision this being very useful for analyzing contention scenarios or
tuning parameters like batch sizes in a producer consumer queue. For more
targeted traces likemthis, let's talk about how we want to approach trace
pruning.
Reviewers: dberris, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39362
llvm-svn: 317531
This class was split between libIR and libSupport, which breaks under
modular code generation. Move it into the one library that uses it,
ProfileData, to resolve this issue.
llvm-svn: 317366
Adds blacklist parsing behaviour for filtering results into four categories:
- Expected Protected: Things that are not in the blacklist and are protected.
- Unexpected Protected: Things that are in the blacklist and are protected.
- Expected Unprotected: Things that are in the blacklist and are unprotected.
- Unexpected Unprotected: Things that are not in the blacklist and are unprotected.
now can optionally be invoked with a second command line argument, which specifies the blacklist file that the binary was built with.
Current statistics for chromium:
Reviewers: vlad.tsyrklevich
Subscribers: mgorny, llvm-commits, pcc, kcc
Differential Revision: https://reviews.llvm.org/D39525
llvm-svn: 317364
GNU binutils nm doesn't error out on this, and some projects' build
systems can end up doing that in some cases. Allowing that seems like
a better target than trying to avoid user projects passing multiple
-g parameters to $NM.
Differential Revision: https://reviews.llvm.org/D39539
llvm-svn: 317301
The character gets uppercased into 'I' when it's a global symbol.
In GNU binutils, nm prints 'I' for symbols classified by
bfd_is_ind_section - which probably isn't exactly/only import
tables.
When building for win32, (some incarnations of?) libtool has got
rules that try to inspect linked libraries, and in order to
be sure that it is linking to a DLL import library as opposed to
a static library, it expects to find the string " I " in the output
of $NM when run on such an import library.
GNU binutils nm also flags all of the .idata$X chunks as 'i' (while
this patch only makes it set on .idata$2 and .idata$6) and also
flags __imp__function as 'I'.
Differential Revision: https://reviews.llvm.org/D39540
llvm-svn: 317300
Just aligning segment offsets to segment alignment is incorrect and also
wastes more space than is needed. The requirement is that p_offset ==
p_addr modulo p_align *not* that p_offset == 0 modulo p_align. Generally
speaking we've been using p_addr == 0 modulo p_align. In fact yaml2obj
can't even produce a valid situation which causes llvm-objcopy to
produce incorrect results because alignment and offset were both
inherited from the sections the program header covers. This change fixes
this bad behavior in llvm-objcopy.
Differential Revision: https://reviews.llvm.org/D39132
llvm-svn: 317284
The LLVM tools can be used as a replacement for binutils, in which case
it's convenient to create symlinks with the binutils names. Add support
for these symlinks in the build system. As with any other llvm tool
symlinks, the user can limit the installed symlinks by only adding the
desired ones to `LLVM_TOOLCHAIN_TOOLS`.
Differential Revision: https://reviews.llvm.org/D39530
llvm-svn: 317272
Sometimes program headers have larger alignments than any of the
sections they contain. Currently yaml2obj can't produce such files. A
bug recently appeared in llvm-objcopy that failed in such a case. I'd
like to be able to add tests to llvm-objcopy for such cases.
This change adds an optional alignment parameter to program headers that
will be used instead of calculating the alignment.
Differential Revision: https://reviews.llvm.org/D39130
llvm-svn: 317139
These include:
* Several functions for creating an LLVMDIBuilder,
* LLVMDIBuilderCreateCompileUnit,
* LLVMDIBuilderCreateFile,
* LLVMDIBuilderCreateDebugLocation.
Patch by Harlan Haskins.
Differential Revision: https://reviews.llvm.org/D32368
llvm-svn: 317135
This makes the command line options consistent with llvm-cov and
llvm-profdata, which both use `-num-threads` and `-j`.
This also addresses the conflict reported after landing D39355.
Differential revision: https://reviews.llvm.org/D39496
llvm-svn: 317104
Summary: Help differentiate code and data by parsing DWARF information. This will reduce false positive rates where data is placed in executable sections and is mistakenly parsed as code, resulting in an inflation in the number of indirect CF instructions (and hence an inflation of the number of unprotected).
Also prints the DWARF line data around the region of each indirect CF instruction.
Reviewers: pcc
Subscribers: probinson, llvm-commits, vlad.tsyrklevich, mgorny, aprantl, kcc
Differential Revision: https://reviews.llvm.org/D38654
llvm-svn: 317050
This patch adds the --threads option to dsymutil to process
architectures in parallel. The feature is already present in the version
distributed with Xcode, but was not yet upstreamed.
This is NFC as far as the linking behavior is concerned. As threads are
used automatically, the current tests cover the change in
implementation.
Differential revision: https://reviews.llvm.org/D39355
llvm-svn: 316999
The Android relocation packing format is a more compact
format for dynamic relocations in executables and DSOs
that is based on delta encoding and SLEBs. An overview
of the format can be found in the Android source code:
https://android.googlesource.com/platform/bionic/+/refs/heads/master/tools/relocation_packer/src/delta_encoder.h
This patch implements relocation packing using that format.
This implementation uses a more intelligent algorithm for compressing
relative relocations than Android's own relocation packer. As a
result it can generally create smaller relocation sections than
that packer. If I link Chromium for Android targeting ARM32 I get a
.rel.dyn of size 174693 bytes, as compared to 371832 bytes with gold
and the Android packer.
Differential Revision: https://reviews.llvm.org/D39152
llvm-svn: 316775
Patch by Robert Widmann.
Expose getters for MetadataType and TokenType publicly in the C API.
Discovered a need for these while trying to wrap the intrinsics API.
Differential Revision: https://reviews.llvm.org/D38809
llvm-svn: 316762
Summary:
This upstreams a patch from the osxcross [1] toolchain.
It appears that llvm-dsymutil crashes at this place during GCC
bootstrap. Adding the check here seems reasonable, since it operates
on arbitrary input DWARF, not necessarily generated by the LLVM
toolchain, and it seems the un-mangled name need not necessarily exist.
Patch by Thomas Pöchtrager
[1] https://github.com/tpoechtrager/osxcross
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D39336
llvm-svn: 316678
Add the option to lookup an address in the debug information and print
out the file, function, block and line table details.
Differential revision: https://reviews.llvm.org/D38409
llvm-svn: 316619
Add a CFI protection check that is implemented by building a graph and inspecting the output to deduce if the indirect CF instruction is CFI protected. Also added the output of this instruction to printIndirectInstructions().
Reviewers: vlad.tsyrklevich
Subscribers: llvm-commits, kcc, pcc, mgorny
Differential Revision: https://reviews.llvm.org/D38428
llvm-svn: 316610
This is in preparation for testing lld's upcoming relocation packing
feature (D39152). I have verified that this implementation correctly
unpacks the relocations from a Chromium DSO built with gold and the
Android relocation packer for ARM32 and ARM64.
Differential Revision: https://reviews.llvm.org/D39272
llvm-svn: 316543
We need to use a stable sort on instantiation and expansion sub-views to
produce consistent output. Fortunately, we've gotten lucky and the tests
have checks for the stable order.
This is needed to unblock D39245. Once that lands, we'll have better
test coverage for sort non-determinism.
llvm-svn: 316490
Probably due to a change of how some pass initializes its dependencies,
the -write-bitcode pass (Bitcode/Writer/BitcodeWriterPass.cpp) is not
initialized in opt anymore and therefore not usable with
opt -write-bitcode
Explicitly call initializeWriteBitcodePassPass() to make it available
in opt again.
Differential Revision: https://reviews.llvm.org/D39223
llvm-svn: 316464
The type index is from the TPI stream, not the IPI stream. Fix the
dumper, fix type index discovery, and add a test in LLD.
Also improve the log message we emit when we fail to rewrite type
indices in LLD. That's how I found this bug.
llvm-svn: 316461
Implement a localised graph builder for indirect control flow
instructions. Main interface is through GraphBuilder::buildFlowGraph,
which will build a flow graph around an indirect CF instruction. Various
modifications to FileVerifier are also made to const-expose some members
needed for machine code analysis done by the graph builder.
Reviewers: vlad.tsyrklevich
Reviewed By: vlad.tsyrklevich
Subscribers: llvm-commits, kcc, pcc
Differential Revision: https://reviews.llvm.org/D38427
llvm-svn: 316372
LineCoverageIterator makes it easy for clients of coverage data to
determine line execution counts for a file or function. The coverage
iteration logic is tricky enough that it really pays not to have
multiple copies of it. Hopefully having just one implementation in LLVM
will make the iteration logic easier to test, reuse, and update.
This commit is NFC but I've added a unit test to go along with it just
because it's easy to do now.
llvm-svn: 316141
llvm-cov tends to highlight too many regions because its policy is to
highlight all region entry segments. This can look confusing to users:
not all region entry segments are interesting and deserve highlighting.
Emitting these highlights only when the region count differs from the
line count is a more user-friendly policy.
llvm-svn: 316109
Instead of copying around the wrapped segment and the list of line
segments, just pass a reference to a LineCoverageStats object. This
simplifies the interface. It also makes an upcoming change to suppress
distracting highlights possible.
llvm-svn: 316108
llvm-cov typically doesn't highlight gap segments, but it should if the
gap occurs after an uncovered region in order to preserve continuity.
llvm-svn: 316107
Summary:
llvm-cfi-verify (D38379) introduced a potential build failure when compiling with `-DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON`. Specific versions of cmake seem to treat the `add_subdirectory()` rule differently. It seems as if old versions of cmake BFS these rules, adding them to the fringe for expansion later. Newer versions of cmake seem to immediately execute CMakeFiles that are present in this subdirectory.
If the subdirectory is expanded through the fringe, the globbing resultant from `llvm_add_implicit_projects()` from `cmake/modules/AddLLVM.cmake:1012` means that `tools/llvm-shlib/CMakeFile.txt` gets executed before `tools/llvm-cfi-verify/lib/CMakeFile.txt`. As the latter CMakeFile adds a new library, this expansion order means that the library files required the unit tests in `unittests/tools/llvm-cfi-verify/` are not present in the dynamic library. This causes unit tests to fail as the required functions can't be found.
This change now ensures that the libraries created by `llvm-cfi-verify` are statically linked into the unit tests. As `tools/llvm-cfi-verify/lib` no longer adds anything to `llvm-shlib`, there should be no concern about the order-of-compilation.
Reviewers: skatkov, pcc
Reviewed By: skatkov, pcc
Subscribers: llvm-commits, kcc, pcc, aheejin, vlad.tsyrklevich, mgorny
Differential Revision: https://reviews.llvm.org/D39020
llvm-svn: 316059
In r315960, I accidentally assumed that the first line segment is
guaranteed to be the non-gap region entry segment (given that one is
present). It can actually be any segment on the line, and the test I
checked in demonstrates that.
llvm-svn: 315963
Gap areas make it possible to correctly determine when to use counts
from deferred regions. Before gap areas were introduced, llvm-cov needed
to use a heuristic to do this: it ignored counts from segments that
start, but do not end, on a line. This heuristic breaks down on a simple
example (see PR34962).
This patch removes the heuristic and picks counts from any region entry
segment which isn't a gap area.
llvm-svn: 315960
There were two copies of the logic needed to construct a line stats
object for each line in a range: this patch brings it down to one. In
the future, this will make it easier for IDE clients to display coverage
in-line in source editors. To do that, we just need to move the new
LineCoverageIterator class to libCoverage.
llvm-svn: 315789
Summary:
Documentation says that user can specify sources for both "show" and
"report" commands. "Show" command respects specified sources, but "report" does
not. It is useful to have both "show" and "report" generated for specified
sources. Also added tests to for both commands with sources specified.
Reviewers: vsk, kcc
Reviewed By: vsk
Differential Revision: https://reviews.llvm.org/D38860
llvm-svn: 315685
This patch adds timestamp verification for swiftmodule files. A new flag
is provided to allows us to disable this check in order to allow testing
of this feature.
Differential revision: https://reviews.llvm.org/D38686
llvm-svn: 315684
Reverting to investigate layering effects of MCJIT not linking
libCodeGen but using TargetMachine::getNameWithPrefix() breaking the
lldb bots.
This reverts commit r315633.
llvm-svn: 315637
Summary:
As the first step to allow analysis and visualization of xray collected data,
allow using the llvm-xray stacks tool to emit a complete listing of stacks in
the format consumable by a flamegraph tool.
Possible follow up formats include chrome trace viewer format and sql load
files.
As a POC, I'm able to generate flamegraphs of an xray instrumented llc compiling
hello world.
Reviewers: dberris, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38650
llvm-svn: 315635
Merge LLVMTargetMachine into TargetMachine.
- There is no in-tree target anymore that just implements TargetMachine
but not LLVMTargetMachine.
- It should still be possible to stub out all the various functions in
case a target does not want to use lib/CodeGen
- This simplifies the code and avoids methods ending up in the wrong
interface.
Differential Revision: https://reviews.llvm.org/D38489
llvm-svn: 315633
Here we add a secondary option parser to llvm-isel-fuzzer (and provide
it for use with other fuzzers). With this, you can copy the fuzzer to
a name like llvm-isel-fuzzer=aarch64-gisel for a fuzzer that fuzzer
AArch64 with GlobalISel enabled, or fuzzer=x86_64 to fuzz x86, with no
flags required. This should be useful for running these in OSS-Fuzz.
Note that this handrolls a subset of cl::opts to recognize, rather
than embedding a complete command parser for argv[0]. If we find we
really need the flexibility of handling arbitrary options at some
point we can rethink this.
This re-applies 315545 using "=" instead of ":" as a separator for
arguments.
llvm-svn: 315557
It broke some tests on Windows:
Failing Tests (4):
LLVM :: tools/llvm-isel-fuzzer/execname-options.ll
LLVM :: tools/llvm-isel-fuzzer/missing-triple.ll
LLVM :: tools/llvm-isel-fuzzer/x86-empty-bc.ll
LLVM :: tools/llvm-isel-fuzzer/x86-empty.ll
> llvm-isel-fuzzer: Handle a subset of backend flags in the executable name
>
> Here we add a secondary option parser to llvm-isel-fuzzer (and provide
> it for use with other fuzzers). With this, you can copy the fuzzer to
> a name like llvm-isel-fuzzer:aarch64-gisel for a fuzzer that fuzzer
> AArch64 with GlobalISel enabled, or fuzzer:x86_64 to fuzz x86, with no
> flags required. This should be useful for running these in OSS-Fuzz.
>
> Note that this handrolls a subset of cl::opts to recognize, rather
> than embedding a complete command parser for argv[0]. If we find we
> really need the flexibility of handling arbitrary options at some
> point we can rethink this.
llvm-svn: 315554
Here we add a secondary option parser to llvm-isel-fuzzer (and provide
it for use with other fuzzers). With this, you can copy the fuzzer to
a name like llvm-isel-fuzzer:aarch64-gisel for a fuzzer that fuzzer
AArch64 with GlobalISel enabled, or fuzzer:x86_64 to fuzz x86, with no
flags required. This should be useful for running these in OSS-Fuzz.
Note that this handrolls a subset of cl::opts to recognize, rather
than embedding a complete command parser for argv[0]. If we find we
really need the flexibility of handling arbitrary options at some
point we can rethink this.
llvm-svn: 315545
This reverts commit 4e4ee1c507e2707bb3c208e1e1b6551c3015cbf5.
This is failing due to some code that isn't built on MSVC
so I didn't catch. Not immediately obvious how to fix this
at first glance, so I'm reverting for now.
llvm-svn: 315536
MCObjectStreamer owns its MCCodeEmitter -- this fixes the types to reflect that,
and allows us to remove the last instance of MCObjectStreamer's weird "holding
ownership via someone else's reference" trick.
llvm-svn: 315531
There's a lot of misuse of Twine scattered around LLVM. This
ranges in severity from benign (returning a Twine from a function
by value that is just a string literal) to pretty sketchy (storing
a Twine by value in a class). While there are some uses for
copying Twines, most of the very compelling ones are confined
to the Twine class implementation itself, and other uses are
either dubious or easily worked around.
This patch makes Twine's copy constructor private, and fixes up
all callsites.
Differential Revision: https://reviews.llvm.org/D38767
llvm-svn: 315530
Summary: Move llvm-cfi-verify into a class in preparation for CFI analysis to come.
Reviewers: vlad.tsyrklevich
Reviewed By: vlad.tsyrklevich
Subscribers: mgorny, llvm-commits, pcc, kcc
Differential Revision: https://reviews.llvm.org/D38379
llvm-svn: 315504
Previously we would only look in the current directory for a
resource, which might not be the same as the directory of the
rc file. Furthermore, MSVC rc supports a /I option, and can
also look in the system environment. This patch adds support
for this search algorithm.
Differential Revision: https://reviews.llvm.org/D38740
llvm-svn: 315499
ubsan caught an issue I made where I was converting a null pointer to a
reference.
elf utils implements a particularly extreme form of stripping that I'd
like to support. eu-strip has an option called "strip-sections" that
removes all section headers and leaves only program headers and the
segment data. I have implemented this option partly as a test but mainly
because in Fuchsia we would like to use this option to minimize the size
of our executables. The other strip options that are on my list include
--strip-all and --strip-debug. This is a preliminary implementation that
I'd like to start using in Fuchsia builds if possible. This change
implements such a stripping option for llvm-objcopy
Differential Revision: https://reviews.llvm.org/D38335
llvm-svn: 315484
This patch adds timestamp verification for swiftmodule files.
- A new flag is provided to allows us to continue testing of the code
for embedding the__swift_ast. (git doesn't maintain timestamps)
- Adds a new test for fat (arm) binaries.
Differential revision: https://reviews.llvm.org/D38686
llvm-svn: 315456
elf utils implements a particularly extreme form of stripping that I'd
like to support. eu-strip has an option called "strip-sections" that
removes all section headers and leaves only program headers and the
segment data. I have implemented this option partly as a test but mainly
because in Fuchsia we would like to use this option to minimize the size
of our executables. The other strip options that are on my list include
--strip-all and --strip-debug. This is a preliminary implementation that
I'd like to start using in Fuchsia builds if possible. This change
implements such a stripping option for llvm-objcopy
Differential Revision: https://reviews.llvm.org/D38335
llvm-svn: 315412
MCObjectStreamer owns its MCAsmBackend -- this fixes the types to reflect that,
and allows us to remove another instance of MCObjectStreamer's weird "holding
ownership via someone else's reference" trick.
llvm-svn: 315410
This change adds the ability to use the "-R"/"-remove-section" option
multiple times.
Differential Revision: https://reviews.llvm.org/D38332
llvm-svn: 315385
If a Section had Type SHT_STRTAB (which could happen if you had a
.dynstr section) it was possible to cast Section to StringTableSection
and get away with any operation that was supported by SectionBase
without it being noticed. This change makes this bug easier to notice
and fixes it where it occurred. It also made me realize that there was
some duplication of efforts in the loop that calls ::initialize. These
issues are all fixed by this change.
Differential Revision: https://reviews.llvm.org/D38329
llvm-svn: 315372
This reverts commit r315363. It has a simple build failure, but more
importantly I want to confirm that unit tests run in check-all to make
sure that they don't silently break in the future.
llvm-svn: 315370
Summary: Move llvm-cfi-verify into a class in preparation for CFI analysis to come.
Reviewers: vlad.tsyrklevich
Reviewed By: vlad.tsyrklevich
Subscribers: mgorny, llvm-commits, pcc, kcc
Differential Revision: https://reviews.llvm.org/D38379
llvm-svn: 315363
Summary:
D36624 added some python3 compatibility. But that fix has a problem..
With python2 (which is specified by `#!/usr/bin/env python2.7`), if the env variables do not specify the UTF8,
and the source file is UTF8 (contains non-ASCII symbols), then the `.decode('utf-8')` causes the following exception:
```
Reading YAML files...
Rendering HTML files...
8 of 41Traceback (most recent call last):
File "/build/llvm/tools/opt-viewer/opt-viewer.py", line 277, in <module>
print_progress)
File "/build/llvm/tools/opt-viewer/opt-viewer.py", line 213, in generate_report
should_print_progress)
File "/build/llvm/tools/opt-viewer/optpmap.py", line 45, in pmap
result = map(_wrapped_func, func_and_args, *args, **kwargs)
File "/build/llvm/tools/opt-viewer/optpmap.py", line 25, in _wrapped_func
return func(argument)
File "/build/llvm/tools/opt-viewer/opt-viewer.py", line 174, in _render_file
SourceFileRenderer(source_dir, output_dir, filename).render(remarks)
File "/build/llvm/tools/opt-viewer/opt-viewer.py", line 125, in render
self.render_source_lines(self.source_stream, line_remarks)
File "/build/llvm/tools/opt-viewer/opt-viewer.py", line 79, in render_source_lines
</tr>'''.format(**locals()), file=self.stream)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xf4' in position 47: ordinal not in range(128)
```
This is similar to https://bugs.llvm.org/show_bug.cgi?id=33548, which was fixed by https://reviews.llvm.org/D37661
Unlike that fix, here, *removing* `.decode('utf-8')` actually fixes it.
Since i assume that the original fix is needed, i simply made
that fix conditional, since for python2 it actually breaks things.
Reviewers: modocache, anemet
Reviewed By: anemet
Subscribers: fhahn, llvm-commits
Differential Revision: https://reviews.llvm.org/D38289
llvm-svn: 315350
This change adds support for removing sections using the -R field (as
GNU objcopy does as well). This change should let us add many helpful
tests and is a proper stepping stone for adding more general kinds of
stripping.
Differential Revision: https://reviews.llvm.org/D38260
llvm-svn: 315346
Some functions were taking Twine's not by const&, these are all
fixed to take by const&. We also had a case where some functions
were overloaded to accept by const& and &&. Now there is only
one version which accepts by value and move's the value.
llvm-svn: 315229
Summary:
swiftc emits symbols without flags set, which led dsymutil to ignore
them when searching for global symbols, causing dwarf location data
to be omitted. Xcode's dsymutil handles this case correctly, and emits
valid location data. Add this functionality to llvm-dsymutil by
allowing parsing of symbols with no flags set.
Reviewers: aprantl, friss, JDevlieghere
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38587
llvm-svn: 315218
This allows rc files to have comments. Eventually we should
just use clang's c preprocessor, but that's a bit larger
effort for minimal gain, and this is straightforward.
Differential Revision: https://reviews.llvm.org/D38651
llvm-svn: 315207
This allows the escape sequences (\a, \n, \r, \t, \\, \x[0-9a-f]*,
\[0-7]*, "") to appear in .rc scripts. These are parsed and output in
the same way as it's done in original MS implementation.
The way these sequences are processed depends on the type of the
resource it resides in, and on whether the user declared the string to
be "wide" or "narrow".
I tried to maintain the maximum compatibility with the original tool
(and fail in some erroneous situations that are accepted by .rc).
However, there are some (extremely rare) cases where Microsoft tool
outputs nonsense. I found it infeasible to detect such casses.
Patch by Marek Sokolowski
Differential Revision: https://reviews.llvm.org/D38426
llvm-svn: 315118
This allows rc to serialize user-defined resources, as
documented at:
msdn.microsoft.com/en-us/library/windows/desktop/aa381054.aspx
Escape sequences are yet unavailable, and are to be added in one of
child patches.
Patch by: Marek Sokolowski
Differential Revision: https://reviews.llvm.org/D38423
llvm-svn: 315117
This allows llvm-rc to serialize STRINGTABLE resources.
These are output in an unusual way: we locate them at the end of the
file, and strings are merged into bundles of max 16 strings, depending
on their IDs, language, and characteristics.
Ref: msdn.microsoft.com/en-us/library/windows/desktop/aa381050.aspx
Patch by: Marek Sokolowski
Differential Revision: https://reviews.llvm.org/D38420
llvm-svn: 315112
This is now able to dump VERSIONINFO resources.
Ref: msdn.microsoft.com/en-us/library/windows/desktop/aa381058.aspx
Differential Revision: https://reviews.llvm.org/D38410
Patch by: Marek Sokolowski
llvm-svn: 315110
This is part 6 of llvm-rc serialization.
This adds ability to output cursors and icons as resources.
Unfortunately, we can't just copy .cur or .ico files to output - as each
file might contain multiple images, each of them needs to be unpacked
and stored as a separate resource. This forces us to parse cursor and
icon contents. (Fortunately, these formats are pretty similar and can be
processed by mostly common code).
As test files are binary, here is a short explanation of .cur and .ico
files stored:
cursor.cur, cursor-8.cur, cursor-32.cur are sample correct cursor files,
differing in their bit depth.
icon-old.ico, icon-new.ico are sample correct icon files;
icon-png.ico is a sample correct icon file in PNG format (instead of
usual BMP);
cursor-eof.cur is an incorrect cursor file - this is cursor.cur with
some of its final bytes removed.
cursor-bad-offset.cur is an incorrect cursor file - image header states
that image data begins at offset 0xFFFFFFFF.
Sample correct cursors and icons were created by Nico Weber.
Patch by Marek Sokolowski
Differential Revision: https://reviews.llvm.org/D37878
llvm-svn: 315109
This is part 5 of llvm-rc serialization support.
This allows DIALOG and DIALOGEX to serialize if dialog-specific optional
statements are provided. These are (as of now): CAPTION, FONT, and
STYLE.
Notably, FONT statement can take more than two arguments when describing
DIALOGEX resources (as in
msdn.microsoft.com/en-us/library/windows/desktop/aa381013.aspx). I made
some changes to the parser to reflect this fact.
Patch by Marek Sokolowski
Differential Revision: https://reviews.llvm.org/D37864
llvm-svn: 315104
At the last LLVM dev meeting we had a debug info for optimized code
BoF session. In that session I presented some graphs that showed how
the quality of the debug info produced by LLVM changed over the last
couple of years. This is a cleaned up version of the patch I used to
collect the this data. It is implemented as an extension of
llvm-dwarfdump, adding a new --statistics option. The intended
use-case is to automatically run this on the debug info produced by,
e.g., our bots, to identify eyebrow-raising changes or regressions
introduced by new transformations that we could act on.
In the current form, two kinds of data are being collected:
- The number of variables that have a debug location versus the number
of variables in total (this takes into account inlined instances of
the same function, so if a variable is completely missing form only
one instance it will be found).
- The PC range covered by variable location descriptions versus the PC
range of all variables' containing lexical scopes.
The output format is versioned and extensible, so I'm looking forward
to both bug fixes and ideas for other data that would be interesting
to track.
Differential Revision: https://reviews.llvm.org/D36627
llvm-svn: 315101
Summary:
swiftc emits symbols without flags set, which led dsymutil to ignore
them when searching for global symbols, causing dwarf location data
to be omitted. Xcode's dsymutil handles this case correctly, and emits
valid location data. Add this functionality to llvm-dsymutil by
allowing parsing of symbols with no flags set.
Reviewers: aprantl, friss, JDevlieghere
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38587
llvm-svn: 315082
Summary:
xar_open and xar_iter_new require manual calls to close/free functions
to deallocate resources. This makes it easy to introduce memory leaks,
so add RAII struct wrappers for these resources.
Reviewers: enderby, rafael, compnerd, lhames, dblaikie
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38598
llvm-svn: 315069
Summary:
Xcode's dsymutil emits a __swift_ast DWARF section, which is required for debugging,
and which contains a byte-for-byte dump of the swiftmodule file.
Add this feature to llvm-dsymutil.
Tested with `gobjdump --dwarf=info -s`, by verifying that the contents of
`__DWARF.__swift_ast` match between Xcode's dsymutil and llvm-dsymutil
(Xcode's dwarfdump and llvm-dwarfdump don't currently recognize the
__swift_ast section).
Reviewers: aprantl, friss
Subscribers: llvm-commits, JDevlieghere
Differential Revision: https://reviews.llvm.org/D38504
llvm-svn: 315066
Summary:
Xcode's dsymutil emits a __swift_ast DWARF section, which is required for debugging,
and which contains a byte-for-byte dump of the swiftmodule file.
Add this feature to llvm-dsymutil.
Tested with `gobjdump --dwarf=info -s`, by verifying that the contents of
`__DWARF.__swift_ast` match between Xcode's dsymutil and llvm-dsymutil
(Xcode's dwarfdump and llvm-dwarfdump don't currently recognize the
__swift_ast section).
Reviewers: aprantl, friss
Subscribers: llvm-commits, JDevlieghere
Differential Revision: https://reviews.llvm.org/D38504
llvm-svn: 315014
Summary:
Xcode's dsymutil emits a __swift_ast DWARF section, which is required for debugging,
and which contains a byte-for-byte dump of the swiftmodule file.
Add this feature to llvm-dsymutil.
Tested with `gobjdump --dwarf=info -s`, by verifying that the contents of
`__DWARF.__swift_ast` match between Xcode's dsymutil and llvm-dsymutil
(Xcode's dwarfdump and llvm-dwarfdump don't currently recognize the
__swift_ast section).
Reviewers: aprantl, friss
Subscribers: llvm-commits, JDevlieghere
Differential Revision: https://reviews.llvm.org/D38504
llvm-svn: 315004
Adds the option 'new-pass-manager' to the gold pluggin to enable using the
new pass manager during the lto/thinlto link step.
Patch by Graham Yiu.
Differential Revision: https://reviews.llvm.org/D38517
llvm-svn: 314963
But now include a check for CPU_COUNT so we still build on 10 year old
versions of glibc.
Original message:
Use sched_getaffinity instead of std:🧵:hardware_concurrency.
The issue with std:🧵:hardware_concurrency is that it forwards
to libc and some implementations (like glibc) don't take thread
affinity into consideration.
With this change a llvm program that can execute in only 2 cores will
use 2 threads, even if the machine has 32 cores.
This makes benchmarking a lot easier, but should also help if someone
doesn't want to use all cores for compilation for example.
llvm-svn: 314931
This is a follow-up to https://reviews.llvm.org/D38138.
I fixed the capitalization of some functions because we're changing those
lines anyway and that helped verify that we weren't accidentally dropping
any options by using default param values.
llvm-svn: 314930
Summary:
This reverts D38481. The change breaks systems with older versions of glibc. It
injects a use of CPU_COUNT() from sched.h without checking to ensure that the
function exists first.
Reviewers:
Subscribers:
llvm-svn: 314922
Somehow a few massive errors slipped though the cracks of testing.
1. The code in Segment::finalize was left over from the old layout
algorithm. In certain situations this would cause very strange issues
with segment layout. For instance in the shift-segments.test case it
would cause the second segment to have the same offset as the first.
2. In debugging this I discovered another issue. Namely section alignment
was not being computed based on Section->Align but instead
Section->Offset which is bizarre and makes no sense. I have no clue how
it worked in the first place. This issue is also fixed
3. Fixing #2 exposed a bug where things were not being written past the end
of the file that technically should have been. This was because in
certain cases (like overlapping-segments) the end of the file wouldn't
always be bumped if the offset could be chosen relative to an existing
segment that already had it's offset chosen. For fully nested segments
this is fine but for overlapping segments this leaves the end of the
file short. So I changed how the offset is bumped when looping though
segments.
Differential Revision: https://reviews.llvm.org/D38436
llvm-svn: 314918
The test fails on Linux; see follow-up email on the llvm-commits list.
> Add the option to lookup an address in the debug information and print
> out the file, function, block and line table details.
>
> Differential revision: https://reviews.llvm.org/D38409
This also reverts the follow-up r314818:
> [test] Fix llvm-dwarfdump/cmdline.test
>
> Fixes test/tools/llvm-dwarfdump/cmdline.test
llvm-svn: 314825
The list of register ids was previously written out in a couple of dirrent
places. This puts it in a .def file and also adds a few more registers (e.g.
the x87 regs) which should lead to more readable dumps, but I didn't include
the whole list since that seems unnecessary.
X86_MC::initLLVMToSEHAndCVRegMapping is pretty ugly, but at least it's not
relying on magic constants anymore. The TODO of using tablegen still stands.
Differential revision: https://reviews.llvm.org/D38480
llvm-svn: 314821
Add the option to lookup an address in the debug information and print
out the file, function, block and line table details.
Differential revision: https://reviews.llvm.org/D38409
llvm-svn: 314817
The issue with std:🧵:hardware_concurrency is that it forwards
to libc and some implementations (like glibc) don't take thread
affinity into consideration.
With this change a llvm program that can execute in only 2 cores will
use 2 threads, even if the machine has 32 cores.
This makes benchmarking a lot easier, but should also help if someone
doesn't want to use all cores for compilation for example.
llvm-svn: 314809
This came out of a recent discussion on llvm-dev
(https://reviews.llvm.org/D38042). Currently the Verifier will strip
the debug info metadata from a module if it finds the dbeug info to be
malformed. This feature is very valuable since it allows us to improve
the Verifier by making it stricter without breaking bcompatibility,
but arguable the Verifier pass should not be modifying the IR. This
patch moves the stripping of broken debug info into AutoUpgrade
(UpgradeDebugInfo to be precise), which is a much better location for
this since the stripping of malformed (i.e., produced by older, buggy
versions of Clang) is a (harsh) form of AutoUpgrade.
This change is mostly NFC in nature, the one big difference is the
behavior when LLVM module passes are introducing malformed debug
info. Prior to this patch, a NoAsserts build would have printed a
warning and stripped the debug info, after this patch the Verifier
will report a fatal error. I believe this behavior is actually more
desirable anyway.
Differential Revision: https://reviews.llvm.org/D38184
llvm-svn: 314699
Sam Clegg