lldb-platform's listener socket only had a backlog of one connection.
That means that if more than one client connected simultaneously, the
connection would be refused. The test suite can be run remotely with
dozens of threads connecting simultaneously. Raised this limit to 100
to effectively eliminate lost connections.
Test Plan:
run tests against a remote target
Differential Revision: http://reviews.llvm.org/D8696
llvm-svn: 233652
lldb-server server process was holding on to a connection to every
client that connected. This continued until the process hit it's
file limit and exited.
lldb-server p --listen *:5432 --server
run remote tests against that server more than 1000 times
Differential Revision: http://reviews.llvm.org/D8697
llvm-svn: 233651
Two things here:
1. I read `getScope()` and `getContext()` backwards in r233640. There
was no need for `getScopeOfScope()`. Obviously not enough test
coverage here (as I said in that commit, I'm going to come back to
that), but anyway I'm reverting to the behaviour before r233640.
2. The callers that use `DILexicalBlockFile::getContext()` don't seem
to care about the difference. Just have it redirect to `getScope()`
so I can't get confused again.
llvm-svn: 233650
examples/ExceptionDemo/CMakeFiles/ExceptionDemo.dir/ExceptionDemo.cpp.o:(.data.rel.ro._ZTIN4llvm18MCJITMemoryManagerE[_ZTIN4llvm18MCJITMemoryManagerE]+0x10): undefined reference to `typeinfo for llvm::RuntimeDyld::MemoryManager'
llvm-svn: 233647
The only user of `DebugLoc::getFromDILexicalBlock()` was creating a new
`MDLocation` as convenient API for passing an `MDScope`. Stop doing
that, and remove the API. If in the future we actually *want* to create
new DebugLocs, calling `MDLexicalBlock::get()` makes more sense.
llvm-svn: 233643
Pervasively use the types provided by the debug info hierarchy rather
than `MDNode` in `LexicalScopes`.
I noticed (again, I guess, based on comments in the implementation?)
that `DILexicalBlockFile::getScope()` returns something different from
`DILexicalBlockFile::getContext()`. I created a local helper for
getting the same logic from `MDLexicalBlockFile` called
`getScopeOfScope()`. I still don't really understand it, but I've added
some FIXMEs and I'll come back to it (I suspect the way we encode these
objects isn't really ideal).
Note that my previous commit r233610 accidentally changed behaviour in
`findLexicalScope()` -- it transitioned from a call to
`DILexicalBlockFile::getScope()` to `MDLexicalBlockFile::getScope()`
(sounds right, doesn't it?) -- so I've fixed that as a drive-by. No
tests failed with my error, so it looks like we're missing some coverage
here... when I come back to understand the logic, I'll see if I can add
some.
Other than the fix to `findLexicalScope()`, no functionality change.
llvm-svn: 233640
Summary:
Move lib/Fuzzer docs from a README.txt to a proper .rst file.
This change does not add any content, just formatting.
Test Plan: n/a
Reviewers: samsonov
Reviewed By: samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8710
llvm-svn: 233638
Generate tables in the .xdata section representing what actions to take
when an exception is thrown. This currently fills in state for
cleanups, catch handlers are still unfinished.
llvm-svn: 233636
When we expand the RET_ReallyLR pseudo instruction we also need to transfer the
implicit operands.
The return register is an implicit operand and without it the liveness
calculation generates an incorrect live-out set for the patchpoint.
This fixes rdar://problem/19068476.
llvm-svn: 233635
Type of `OutputSection::_type` field is int64_t. This change makes
the field's and the argument's types consistent and allows to assign
full range of values to the `OutputSection::_type` field.
llvm-svn: 233617
Summary:
This adds a simple DFSan-based (i.e. taint-guided) fuzzer mutator,
see the comments for details.
Test Plan: a test added
Reviewers: samsonov, pcc
Reviewed By: samsonov, pcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8669
llvm-svn: 233613
There's no benefit to using `DebugLoc` here. Moreover, this will let a
follow-up commit work with `MDScope` directly instead of `DebugLoc`.
llvm-svn: 233610
This pushes the use of PointerType::getElementType up into several
callers - I'll essentially just have to keep pushing that up the stack
until I can eliminate every call to it...
llvm-svn: 233604
Keep a note in the materializer that we are stripping debug info so that
user doing a lazy read of the module don't hit outdated formats.
Thanks to Duncan for suggesting the fix.
llvm-svn: 233603
Since I'm slowly gutting `DISubprogram` and `DICompileUnit`, update the
`CloneFunc` unit tests to call `verifyModule()` (where the checks are
moving to).
llvm-svn: 233602
Don't use `DebugLoc::getFnDebugLoc()`, which creates new `MDLocation`s,
in the backend. We just want to grab the subprogram here anyway.
llvm-svn: 233601
Remove old API for `DebugLoc` now that all the callers have been
updated. If this broke your out-of-tree build, here's a quick map from
the old API to the new one:
DebugLoc DebugLoc::getFromMDLocation(MDNode *)
=> DebugLoc::DebugLoc(MDLocation *)
=> explicit DebugLoc::DebugLoc(MDNode *) // works with broken code
MDNode *DebugLoc::getAsMDNode(LLVMContext &)
=> MDLocation *DebugLoc::get()
=> DebugLoc::operator MDLocation *()
=> MDNode *DebugLoc::getAsMDNode() // works with broken code
bool DebugLoc::isUnknown()
=> DebugLoc::operator MDLocation *()
i.e.: if (MDLocation *DL = ...)
=> DebugLoc::operator bool() // works with broken code
i.e.: if (DebugLoc DL = ...)
void DebugLoc::getScopeAndInlinedAt(MDNode *&, MDNode *&)
=> use: MDNode *DebugLoc::getScope()
and: MDLocation *DebugLoc::getInlinedAt()
MDNode *DebugLoc::getScopeNode(LLVMContext &)
=> MDNode *DebugLoc::getInlinedAtScope()
void DebugLoc::dump(LLVMContext &)
=> void DebugLoc::dump()
void DebugLoc::getFnDebugLoc(LLVMContext &)
=> void DebugLoc::getFnDebugLoc()
MDNode *DebugLoc::getScope(LLVMContext &)
=> MDNode *DebugLoc::getScope()
MDNode *DebugLoc::getInlinedAt(LLVMContext &)
=> MDLocation *DebugLoc::getInlinedAt()
I've noted above the only functions that won't crash on broken code (due
to downcasting to `MDLocation`). If your code could be dealing with
broken IR (i.e., you haven't run the verifier yet, or you've used a
temporary node that will eventually (but not yet) get RAUW'ed to an
`MDLocation`), you need to restrict yourself to those.
llvm-svn: 233599
This fixes the visibility of symbols in certain edge cases involving aliases
with multiple levels of indirection.
Fixes PR19582.
Differential Revision: http://reviews.llvm.org/D8586
llvm-svn: 233595
Add Tool and ToolChain support for clang to target the NaCl OS using the NaCl
SDK for x86-32, x86-64 and ARM.
Includes nacltools::Assemble and Link which are derived from gnutools. They
are similar to Linux but different enought that they warrant their own class.
Also includes a NaCl_TC in ToolChains derived from Generic_ELF with library
and include paths suitable for an SDK and independent of the system tools.
Differential Revision: http://reviews.llvm.org/D8590
llvm-svn: 233594
Again, this is being applied in a separate commit so that the previous commit
can be reverted while leaving the test in place.
rdar://problem/20335433
llvm-svn: 233593
This is imitating a pre-r228174 state where ivars are not considered tracked by
default, but with the addition that even ivars /with/ retain count information
(e.g. "[_ivar retain]; [ivar _release];") are not being tracked as well. This is
to ensure that we don't regress on values accessed through both properties and
ivars, which is what r228174 was trying to fix.
The issue occurs in code like this:
[_contentView retain];
[_contentView removeFromSuperview];
[self addSubview:_contentView]; // invalidates 'self'
[_contentView release];
In this case, the call to -addSubview: may change the value of self->_contentView,
and so the analyzer can't be sure that we didn't leak the original _contentView.
This is a correct conservative view of the world, but not a useful one. Until we
have a heuristic that allows us to not consider this a leak, not emitting a
diagnostic is our best bet.
This commit disables all of the ivar-related retain count tests, but does not
remove them to ensure that we don't crash trying to evaluate either valid or
erroneous code. The next commit will add a new test for the example above so
that this commit (and the previous one) can be reverted wholesale when a better
solution is implemented.
Rest of rdar://problem/20335433
llvm-svn: 233592
Give up this checking in order to continue tracking that these values came from
direct ivar access, which will be important in the next commit.
Part of rdar://problem/20335433
llvm-svn: 233591
Vince Harron