between the linker's TLS optimizations and Clang's TLS code generation.
For now, Clang has been changed to disable linker TLS optimizations
until it (and LLVM more generally) are emitting TLS code sequences
compatible with the old bugs found in the linkers. That's a better fix
to handle bootstrapping on that platform.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227511 91177308-0d34-0410-b5e6-96231b3b80d8
to get a powerpc64 host so that I can reproduce and test this, but it
only impacts that platform so trying the only other realistic option.
According to Ulrich, who debugged this initially, initial-exec is likely
to be sufficient for our needs and not subject to this bug. Will watch
the build bots to see.
If this doesn't work, I'll be forced to cut a really ugly pthread-based
approach into the primary user (our stack trace printing) as that user
cannot use the ThreadLocal implementation due to lifetime issues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227414 91177308-0d34-0410-b5e6-96231b3b80d8
entirely when threads are not enabled. This should allow anyone who
needs to bootstrap or cope with a host loader without TLS support to
limp along without threading support.
There is still some bug in the PPC TLS stuff that is not worked around.
I'm getting access to a machine to reproduce and debug this further.
There is some chance that I'll have to add a terrible workaround for
PPC.
There is also some problem with iOS, but I have no ability to really
evaluate what the issue is there. I'm leaving it to folks maintaining
that platform to suggest a path forward -- personally I don't see any
useful path forward that supports threading in LLVM but does so without
support for *very basic* TLS. Note that we don't need more than some
pointers, and we don't need constructors, destructors, or any of the
other fanciness which remains widely unimplemented.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227411 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The primary goal of this patch is to remove the need for MarkOptionsChanged(). That goal is accomplished by having addOption and removeOption properly sort the options.
This patch puts the new add and remove functionality on a CommandLineParser class that is a placeholder. Some of the functionality in this class will need to be merged into the OptionRegistry, and other bits can hopefully be in a better abstraction.
This patch also removes the RegisteredOptionList global, and the need for cl::Option objects to be linked list nodes.
The changes in CommandLineTest.cpp are required because these changes shift when we validate that options are not duplicated. Before this change duplicate options were only found during certain cl API calls (like cl::ParseCommandLine). With this change duplicate options are found during option construction.
Reviewers: dexonsmith, chandlerc, pete
Reviewed By: pete
Subscribers: pete, majnemer, llvm-commits
Differential Revision: http://reviews.llvm.org/D7132
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227345 91177308-0d34-0410-b5e6-96231b3b80d8
This contains the changes from r227148 & r227154, and also fixes to the test case to properly clean up the stack options.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227255 91177308-0d34-0410-b5e6-96231b3b80d8
r227148 added test CommandLineTest.HideUnrelatedOptionsMulti which repeatedly
outputs two following lines:
-tool: CommandLine Error: Option 'test-option-1' registered more than once!
-tool: CommandLine Error: Option 'test-option-2' registered more than once!
r227154 depends on changes from r227148
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227167 91177308-0d34-0410-b5e6-96231b3b80d8
Need a new API for clang-modernize that allows specifying a list of option categories to remain visible. This will allow clang-modernize to move off getRegisteredOptions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227140 91177308-0d34-0410-b5e6-96231b3b80d8
This can also be used instead of the WindowsSupport.h ConvertUTF8ToUTF16
helpers, but that will require massaging some character types. The
Windows support routines want wchar_t output, but wchar_t is often 32
bits on non-Windows OSs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227122 91177308-0d34-0410-b5e6-96231b3b80d8
Previously using format_hex() would always print a 0x prior to the
hex characters. This allows this to be optional, so that one can
choose to print (e.g.) 255 as either 0xFF or just FF.
Differential Revision: http://reviews.llvm.org/D7151
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227108 91177308-0d34-0410-b5e6-96231b3b80d8
MIPS64 ELF file has a very specific relocation record format. Each
record might specify up to three relocation operations. So the `r_info`
field in fact consists of three relocation type sub-fields and optional
code of "special" symbols.
http://techpubs.sgi.com/library/manuals/4000/007-4658-001/pdf/007-4658-001.pdf
page 40
The patch implements support of the MIPS64 relocation record format in
yaml2obj/obj2yaml tools by introducing new optional Relocation fields:
Type2, Type3, and SpecSym. These fields are recognized only if the
object/YAML file relates to the MIPS64 target.
Differential Revision: http://reviews.llvm.org/D7136
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227044 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Some parsers need references back to the option they are members of. This is used for handling the argument string as well as by the various pass name parsers for making pass names into flags.
Making parsers that need to refer back to the option have a reference to the option eliminates some of the members of various parsers, and enables further code cleanup.
Reviewers: dexonsmith
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7131
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226864 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The default copy and assignment operators for these objects probably don't actually do what the clients intend, so they should be deleted.
Places using the assignment operator to set the value of an option should cast to the option's data type first to call into the override for operator=. Places using the copy constructor just need to be changed to not copy (i.e. passing by const reference instead of value).
Reviewers: dexonsmith, chandlerc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7114
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226762 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: cl::getRegisteredOptions really exposes some of the innards of how command line parsing is implemented. Exposing new APIs that allow us to disentangle client code from implementation details will allow us to make more extensive changes to command line parsing.
Reviewers: chandlerc, dexonsmith, beanz
Reviewed By: dexonsmith
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7100
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226729 91177308-0d34-0410-b5e6-96231b3b80d8
Since MCStreamer isn't part of Support, the dtor can't be called from
here - so just pass by reference instead. This is rather imperfect, but
will hopefully suffice.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226415 91177308-0d34-0410-b5e6-96231b3b80d8
Note: This change ended up being slightly more controversial than expected. Chandler has tentatively okayed this for the moment, but I may be revisiting this in the near future after we settle some high level questions.
Rather than have the GCStrategy object owned by the GCModuleInfo - which is an immutable analysis pass used mainly by gc.root - have it be owned by the LLVMContext. This simplifies the ownership logic (i.e. can you have two instances of the same strategy at once?), but more importantly, allows us to access the GCStrategy in the middle end optimizer. To this end, I add an accessor through Function which becomes the canonical way to get at a GCStrategy instance.
In the near future, this will allows me to move some of the checks from http://reviews.llvm.org/D6808 into the Verifier itself, and to introduce optimization legality predicates for some of the recent additions to InstCombine. (These will follow as separate changes.)
Differential Revision: http://reviews.llvm.org/D6811
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226311 91177308-0d34-0410-b5e6-96231b3b80d8
I haven't looked closely at exactly why the side effect is required, but
this seems better than not mentioning it at all.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226030 91177308-0d34-0410-b5e6-96231b3b80d8
utils/sort_includes.py.
I clearly haven't done this in a while, so more changed than usual. This
even uncovered a missing include from the InstrProf library that I've
added. No functionality changed here, just mechanical cleanup of the
include order.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225974 91177308-0d34-0410-b5e6-96231b3b80d8
Now that the passes are wrappers around this, we no longer need
a vtable, virtual destructor, and other associated mess. This is
particularly nice to me as this is a class template. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225970 91177308-0d34-0410-b5e6-96231b3b80d8
into the new pass manager's analysis cache which stores results
by-value.
Technically speaking, the dom trees were originally not movable but
copyable! This, unsurprisingly, didn't work at all -- the copy was
shallow and just resulted in rampant memory corruption. This change
explicitly forbids copying (as it would need to be a deep copy) and
makes them explicitly movable with the unsurprising boiler plate to
member-wise move them because we can't rely on MSVC to generate this
code for us. =/
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225966 91177308-0d34-0410-b5e6-96231b3b80d8
class members are implicitly "inline", no key word needed.
Naturally, this could change how LLVM inlines these functions because
<GRR>, but that's not an excuse to use the keyword. ;]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225939 91177308-0d34-0410-b5e6-96231b3b80d8
significantly. Clean it up with the help of clang-format.
I've touched this up by hand in a couple of places that weren't quite
right (IMO). I think most of these actually have bugs open about
already.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225938 91177308-0d34-0410-b5e6-96231b3b80d8
A pass that adds random noops to X86 binaries to introduce diversity with the goal of increasing security against most return-oriented programming attacks.
Command line options:
-noop-insertion // Enable noop insertion.
-noop-insertion-percentage=X // X% of assembly instructions will have a noop prepended (default: 50%, requires -noop-insertion)
-max-noops-per-instruction=X // Randomly generate X noops per instruction. ie. roll the dice X times with probability set above (default: 1). This doesn't guarantee X noop instructions.
In addition, the following 'quick switch' in clang enables basic diversity using default settings (currently: noop insertion and schedule randomization; it is intended to be extended in the future).
-fdiversify
This is the llvm part of the patch.
clang part: D3393
http://reviews.llvm.org/D3392
Patch by Stephen Crane (@rinon)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225908 91177308-0d34-0410-b5e6-96231b3b80d8
No functional changes, I'm just going to be doing a lot of work in these files and it would be helpful if they had more current LLVM style.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225817 91177308-0d34-0410-b5e6-96231b3b80d8
