| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 164889
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
ProcessGDBRemote::DoRemoteConnect().
When attaching to a remote system that does not look like a typical vendor system, and no
executable binary was specified to lldb, check a couple of fixed locations where kernels
running in ASLR mode (slid in memory to a random address) store their load addr when booted
in debug mode, and relocate the symbols or load the kernel wholesale from the host computer
if we can find it.
<rdar://problem/7714201>
llvm-svn: 164888
|
| |
|
|
|
|
| |
operators to end of preceding line. No functional change intended.
llvm-svn: 164887
|
| |
|
|
|
|
| |
the varying arguments. No functional change.
llvm-svn: 164886
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is not profitable in many cases
because moden processos can store multiple values in parallel, and preparing the consecutive store requires
some work. We only handle these cases:
1. Consecutive stores where the values and consecutive loads. For example:
int a = p->a;
int b = p->b;
q->a = a;
q->b = b;
2. Consecutive stores where the values are constants. Foe example:
q->a = 4;
q->b = 5;
llvm-svn: 164885
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
loaded at a random offset).
To get the kernel's UUID and load address I need to send a kdp
packet so I had to implement the kernel relocation (and attempt to
find the kernel if none was provided to lldb already) in ProcessKDP
-- but this code really properly belongs in DynamicLoaderDarwinKernel.
I also had to add an optional Stream to ConnectRemote so
ProcessKDP::DoConnectRemote can print feedback about the remote kernel's
UUID, load address, and notify the user if we auto-loaded the kernel via
the UUID.
<rdar://problem/7714201>
llvm-svn: 164881
|
| |
|
|
|
|
| |
on gcc 4.7.
llvm-svn: 164880
|
| |
|
|
| |
llvm-svn: 164879
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
runtime, we read method signatures for both class
and instance methods out of the runtime data.
(lldb) fr var str
(NSString *) str = 0x0000000105000180 @"Hello from '/Volumes/Data/projects/lldb/test/lang/objc/foundation/a.out'"
(lldb) expr str.length
(unsigned long long) $0 = 72
(lldb) expr [NSString stringWithCString:"Hello world!" encoding:1]
(id) $1 = 0x0000000105100050
(lldb) po $1
$1 = 0x0000000105100050 Hello world!
(lldb) fr var array1
(NSArray *) array1 = 0x000000010010a6e0 @"3 objects"
(lldb) expr array1.count
(unsigned long long) $0 = 3
(lldb) expr [array1 objectAtIndex:2]
(id) $1 = 0x00000001000025d0
(lldb) po $1
$1 = 0x00000001000025d0 array1 object3
Notice that both regular and property-style notation
work. I still need to add explicit support for
properties with non-default setters/getters.
This information is only queried if an Objective-C
object does not have debug information for a complete
type available. Otherwise we query debug information
as usual.
llvm-svn: 164878
|
| |
|
|
|
|
|
|
| |
accessing fields"
This reverts commit 6f61df3e7256413dcb99afb9673f4206e3c4992c.
llvm-svn: 164877
|
| |
|
|
|
|
|
|
| |
rvalue."
This reverts commit 0006ba445962621ed82ec84400a6b978205a3fbc.
llvm-svn: 164876
|
| |
|
|
|
|
|
|
| |
correctly."
This reverts commit 580cd17f256259f39a382e967173f34d68e73859.
llvm-svn: 164875
|
| |
|
|
|
|
|
| |
an inclusion directive was automatically turned into a module import, and
PPCallbacks::moduleImport() for an explicit module import.
llvm-svn: 164874
|
| |
|
|
| |
llvm-svn: 164873
|
| |
|
|
|
|
| |
is the same as the suggested one when looking up the include filename.
llvm-svn: 164872
|
| |
|
|
|
|
| |
could happen
llvm-svn: 164871
|
| |
|
|
|
|
| |
where we fail to check for NULL or empty class name
llvm-svn: 164870
|
| |
|
|
| |
llvm-svn: 164869
|
| |
|
|
|
|
|
|
|
|
|
| |
the validation occurred.
The original implementation was pessimistic - we assumed that ivars
which escape are invalidated. This version is optimistic, it assumes
that the ivars will always be explicitly invalidated: either set to nil
or sent an invalidation message.
llvm-svn: 164868
|
| |
|
|
| |
llvm-svn: 164867
|
| |
|
|
| |
llvm-svn: 164866
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This checkin adds the capability for LLDB to load plugins from external dylibs that can provide new commands
It exports an SBCommand class from the public API layer, and a new SBCommandPluginInterface
There is a minimal load-only plugin manager built into the debugger, which can be accessed via Debugger::LoadPlugin.
Plugins are loaded from two locations at debugger startup (LLDB.framework/Resources/PlugIns and ~/Library/Application Support/LLDB/PlugIns) and more can be (re)loaded via the "plugin load" command
For an example of how to make a plugin, refer to the fooplugin.cpp file in examples/plugins/commands
Caveats:
Currently, the new API objects and features are not exposed via Python.
The new commands can only be "parsed" (i.e. not raw) and get their command line via a char** parameter (we do not expose our internal Args object)
There is no unloading feature, which can potentially lead to leaks if you overwrite the commands by reloading the same or different plugins
There is no API exposed for option parsing, which means you may need to use getopt or roll-your-own
llvm-svn: 164865
|
| |
|
|
|
|
|
| |
observe their addresses (taking their address gives the vtable slot) so we are
free to merge their definitions.
llvm-svn: 164864
|
| |
|
|
|
|
| |
full description of _LIBCXX_DYNAMIC_FALLBACK, see src/private_typeinfo.cpp.
llvm-svn: 164863
|
| |
|
|
|
|
|
|
|
|
| |
We can't specialize the usual llvm::DenseMapInfo at the end of the file
because by that point the DenseMap in FunctionScopeInfo has already been
instantiated.
No functionality change.
llvm-svn: 164862
|
| |
|
|
|
|
|
| |
(I still need to add a test once I figure it out).
Reviewed off-line by Doug. // rdar://12378879
llvm-svn: 164861
|
| |
|
|
| |
llvm-svn: 164860
|
| |
|
|
|
|
|
| |
No need to specialize BeforeThanCompare for a comparator that's only
going to be used once.
llvm-svn: 164859
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When issuing a diagnostic message for the -Wimplicit-fallthrough diagnostics, always try to find the latest macro, defined at the point of fallthrough, which is immediately expanded to "[[clang::fallthrough]]", and use it's name instead of the actual sequence.
Known issues:
* uses PP.getSpelling() to compare macro definition with a string (anyone can suggest a convenient way to fill a token array, or maybe lex it in runtime?);
* this can be generalized and used in other similar cases, any ideas where it should reside then?
Reviewers: doug.gregor, rsmith
Reviewed By: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D50
llvm-svn: 164858
|
| |
|
|
|
|
|
|
|
|
|
|
| |
New output:
warning: weak property may be unpredictably set to nil
note: property declared here
note: assign the value to a strong variable to keep the object alive
during use
<rdar://problem/12277204>
llvm-svn: 164857
|
| |
|
|
|
|
|
|
|
| |
The infrastructure for -Warc-repeated-use-of-weak got a little too heavy
to leave sitting at the top of Sema.cpp.
No functionality change.
llvm-svn: 164856
|
| |
|
|
|
|
|
|
|
|
| |
Like properties, loading from a weak ivar twice in the same function can
give you inconsistent results if the object is deallocated between the
two loads. It is safer to assign to a strong local variable and use that.
Second half of <rdar://problem/12280249>.
llvm-svn: 164855
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The motivating example:
if (self.weakProp)
use(self.weakProp);
As with any non-atomic test-then-use, it is possible a weak property to be
non-nil at the 'if', but be deallocated by the time it is used. The correct
way to write this example is as follows:
id tmp = self.weakProp;
if (tmp)
use(tmp);
The warning is controlled by -Warc-repeated-use-of-receiver, and uses the
property name and base to determine if the same property on the same object
is being accessed multiple times. In cases where the base is more
complicated than just a single Decl (e.g. 'foo.bar.weakProp'), it picks a
Decl for some degree of uniquing and reports the problem under a subflag,
-Warc-maybe-repeated-use-of-receiver. This gives a way to tune the
aggressiveness of the warning for a particular project.
The warning is not on by default because it is not flow-sensitive and thus
may have a higher-than-acceptable rate of false positives, though it is
less noisy than -Wreceiver-is-weak. On the other hand, it will not warn
about some cases that may be legitimate issues that -Wreceiver-is-weak
will catch, and it does not attempt to reason about methods returning weak
values.
Even though this is not a real "analysis-based" check I've put the bug
emission code in AnalysisBasedWarnings for two reasons: (1) to run on
every kind of code body (function, method, block, or lambda), and (2) to
suggest that it may be enhanced by flow-sensitive analysis in the future.
The second (smaller) half of this work is to extend it to weak locals
and weak ivars. This should use most of the same infrastructure.
Part of <rdar://problem/12280249>
llvm-svn: 164854
|
| |
|
|
|
|
| |
struct assignment.
llvm-svn: 164853
|
| |
|
|
|
|
| |
Improve performance of StringExtractor::GetHexS8().
llvm-svn: 164852
|
| |
|
|
|
|
|
| |
record, skip at least one element from the InitListExpr to avoid an infinite
loop if we're initializing an array of unknown bound.
llvm-svn: 164851
|
| |
|
|
|
|
| |
rdar://9142819
llvm-svn: 164850
|
| |
|
|
| |
llvm-svn: 164849
|
| |
|
|
| |
llvm-svn: 164848
|
| |
|
|
|
|
|
|
|
| |
In reStructuredText, indented blocks denote block quotes [1]. This list
is not a block quote.
[1]. http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#block-quotes
llvm-svn: 164847
|
| |
|
|
| |
llvm-svn: 164846
|
| |
|
|
| |
llvm-svn: 164845
|
| |
|
|
|
|
|
|
| |
constructing the ObjCInterfaceDecl for an ISA,
we'd continue and try to use that Decl anyway,
possibly causing a crash.
llvm-svn: 164844
|
| |
|
|
|
|
| |
now be printed with highlighting.
llvm-svn: 164843
|
| |
|
|
| |
llvm-svn: 164842
|
| |
|
|
|
|
| |
Tijl Coosemans!
llvm-svn: 164841
|
| |
|
|
| |
llvm-svn: 164840
|
| |
|
|
|
|
| |
functions. Reworked one of the conditionals. No functional changes.
llvm-svn: 164839
|
| |
|
|
|
|
|
| |
use the integrated pre-processor, preprocess in objective-c++ mode.
// rdar://12189793.
llvm-svn: 164836
|
| |
|
|
|
|
|
|
| |
second output of SUB with first output of TEST.
PR13966
llvm-svn: 164835
|