| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
out we only want to roll back text that was in the
buffer to begin with, so it's not necessary to
provide a pushback stack.
I'm going to use this slightly cleaner API to perform
lookahead for the Objective-C runtime type parser.
llvm-svn: 221640
|
|
|
|
| |
llvm-svn: 221637
|
|
|
|
|
|
|
|
|
|
|
|
| |
MSVC warns that not all control paths return a value when a switch
doesn't have a default case handler. Changed explicit value checks
to a default check.
Also, it caught a case where bitwise AND was being used instead of
logical AND. I'm not sure what this fixes, but presumably it is
not covered by any kind of test case.
llvm-svn: 221636
|
|
|
|
| |
llvm-svn: 221633
|
|
|
|
|
|
| |
recent renaming in clang (clang change for revision 221451). This broke all objective C expressions in LLDB.
llvm-svn: 221632
|
|
|
|
|
|
| |
call bound methods as cleanup hooks
llvm-svn: 221624
|
|
|
|
|
|
|
|
| |
r221575 introduced a NoreturnUnwind test that did not skip the dsym
test on non-darwin platforms, and had the @dwarf_test case as an exact
copy of the dsym case (including the test name, test_with_dsym).
llvm-svn: 221611
|
|
|
|
|
|
| |
http://reviews.llvm.org/D6166
llvm-svn: 221593
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
it in RegisterContext.cpp.
There's a lot of bookkeeping code in RegisterContextLLDB where it has
to convert between different register numbering schemes and it makes
some methods like SavedLocationForRegister very hard to read or
maintain. Abstract all of the details about different register numbering
systems for a given register into this new class to make it easier
to understand what the method is doing.
Also add register name printing to all of the logging -- that's easy to
get now that I've got an object to represent the register numbers.
There were some gnarly corner cases of this method that I believe
I've translated correctly - initial testing looks good but it's
possible I missed a corner case, especially with architectures which
uses a link-register aka return address register like arm32/arm64.
Basic behavior is correct but there are a lot of corner casese that are
handled in this method ...
llvm-svn: 221577
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a noreturn function was the last function in a section,
we wouldn't correctly back up the saved-pc value into the
correct section leading to us showing the wrong function in
the backtrace.
Also add a backtrace test with an attempt to elicit this
particular layout. It happens to work out with clang -Os
but other compilers may not quite get the same layout I'm
getting at that opt setting. We'll still be exercising the
basic noreturn handling in the unwinder even if we don't get
one function at the very end of a section.
<rdar://problem/16051613>
llvm-svn: 221575
|
|
|
|
| |
llvm-svn: 221570
|
|
|
|
| |
llvm-svn: 221566
|
|
|
|
|
|
|
|
|
|
| |
Originally the idea was that we would queue requests to a master
thread that would dispatch them to other slave threads each
responsible for debugging an individual process. This might make
some scenarios more scalable and responsive, but for now it seems
to be unwarranted complexity for no observable benefit.
llvm-svn: 221561
|
|
|
|
| |
llvm-svn: 221541
|
|
|
|
|
|
| |
casting via the expression evaluator. Some of our clients depend on it, so we can't remove it. But any new adopters should favor the expression parser as the way forward
llvm-svn: 221540
|
|
|
|
| |
llvm-svn: 221509
|
|
|
|
|
|
|
|
|
|
| |
Fixes include:
- dont set or change LDFLAGS, but set LD_EXTRAS instead
- fix compilation errors for iOS based builds with objective C code
- fix test cases to create classes instead of relying on classes from AppKit
- rename things where it makes sense
llvm-svn: 221496
|
|
|
|
|
|
| |
be run remotely via lldb-platform.
llvm-svn: 221494
|
|
|
|
|
|
|
|
| |
golden output, use the process STDOUT instead.
This helps this test be able to be run remotely.
llvm-svn: 221493
|
|
|
|
|
|
| |
when getting the SDK path and use xcrun to find the SDK path.
llvm-svn: 221492
|
|
|
|
|
|
| |
take on the additional TypeSummaryOptions argument. It is still not used for anything, but it is now there. Adding support for this extra argument to Python formatters will follow suit
llvm-svn: 221486
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
down to individual summary formatters to alter their behavior in a formatter-dependent way
Two flags are introduced:
- preferred display language (as in, ObjC vs. C++)
- summary capping (as in, should a limit be put to the amount of data retrieved)
The meaning - if any - of these options is for individual formatters to establish
The topic of a subsequent commit will be to actually wire these through to individual data formatters
llvm-svn: 221482
|
|
|
|
|
|
|
|
| |
protocols.
<rdar://problem/18883778>
llvm-svn: 221476
|
|
|
|
|
|
|
|
| |
floating point instead of something that can't to avoid test suite failures on different devices and architectures.
<rdar://problem/18826900>
llvm-svn: 221468
|
|
|
|
| |
llvm-svn: 221467
|
|
|
|
| |
llvm-svn: 221452
|
|
|
|
|
|
|
|
|
|
|
|
| |
identifies as a C++ method.
This was done by using regular expressions on any basename we find to ensure it is valid.
This fixed setting breakpoints by name with values like '[J]com.robovm.debug.server.apps.SleepLoop.startingUp()V'. This was previously triggering the C++ method name class to identify the string as C++ with a basename of '[J]com.robovm.debug.server.apps.SleepLoop.startingUp' which was obviously incorrect.
The changes also fixed errors in templated function names like "void foo<int>(...)" where "void foo<int>" was being identified incorrectly as the basename. We also handle more C++ operators correctly now.
llvm-svn: 221416
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows me to generate a Visual Studio solution that builds LLDB if
you have standalone builds of LLVM and Clang lying around.
Unfortunately, you have to pass *four* CMake variables in, but it means
you don't have to take the extra step of installing Clang and LLVM to
some package prefix.
Hopefully this will generate a more usable XCode project too.
llvm-svn: 221413
|
|
|
|
|
|
|
|
|
| |
In the llgs world, ProcessWindows will eventually go away and
we'll implement a different protocol. This patch decouples
ProcessWindows from the core debug loop so that this transition
will not be more difficult than it needs to be.
llvm-svn: 221405
|
|
|
|
|
|
| |
allowing a hook to be passed back the test instance, were it not to be already bound to self. Use this ability to make the reversal of escape-non-printables a teardown hook for added reliability of the testing logic
llvm-svn: 221402
|
|
|
|
|
|
|
|
|
|
|
| |
that we load debug information properly. If we don't
explicitly add-dsym, sometimes Spotlight will help out
and tell us about the dSYM but we shouldn't be relying
on that. Thanks to Jim for catching this.
<rdar://problem/16424661>
llvm-svn: 221400
|
|
|
|
|
|
|
|
|
|
|
| |
should or should not escape sequences such as \t, \n, .. and generally any non-printing character
The recent StringPrinter changes made this behavior the default, and the setting defaults to yes
If you want to change this behavior and see non-printables unescaped (e.g. "a\tb" as "a b"), set it to false
Fixes rdar://12969594
llvm-svn: 221399
|
|
|
|
| |
llvm-svn: 221378
|
|
|
|
|
|
| |
launching LLGS process. Differential Revision: http://reviews.llvm.org/D6105
llvm-svn: 221324
|
|
|
|
|
|
|
|
|
|
|
|
| |
Renamed monitor -> driver, to make clear that the implementation here
is in no way related to that of other process plugins which have also
implemented classes with similar names such as DebugMonitor.
Also created a DebugEventHandler interface, which will be used by
implementors to get notified when debugging events happen in the
inferiors.
llvm-svn: 221322
|
|
|
|
|
|
| |
as it doesn't build and is optional.
llvm-svn: 221315
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D6122
llvm-svn: 221310
|
|
|
|
|
|
| |
value changed' flag for scalar valued variables. This fixes rdar://17851144
llvm-svn: 221298
|
|
|
|
| |
llvm-svn: 221286
|
|
|
|
|
|
|
|
| |
a nop). Fixes an instruction stepping problem when trying to step
over the final instructions of an epilogue.
<rdar://problem/18068877>
llvm-svn: 221241
|
|
|
|
|
|
|
| |
so it doesn't try the arch default if a comiler-generated (eh_frame,
compact unwind info) based unwind plan has failed.
llvm-svn: 221239
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
let's let lldb try the arch default unwind every time but not destructively --
it doesn't permanently replace the main unwind method for that function from
now on.
This fix is for <rdar://problem/18683658>.
I tested it against Ryan Brown's go program test case and also a
collection of core files of tricky unwind scenarios
<rdar://problem/15664282> <rdar://problem/15835846>
<rdar://problem/15982682> <rdar://problem/16099440>
<rdar://problem/17364005> <rdar://problem/18556719>
that I've fixed over the last 6-9 months.
llvm-svn: 221238
|
|
|
|
| |
llvm-svn: 221232
|
|
|
|
| |
llvm-svn: 221231
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is "invalid" -- it is past the end of the stack trace. Add a new
method IsCompletedStackWalk() so we can tell if an invalid stack
frame is from a complete backtrace or if it might be worth re-trying
the last unwind with a different method.
This fixes the unwinder problems Ryan Brown was having with go
programs. The unwinder can (under the right circumstances) still
destructively replace unwind plans permanently - I'll work on
that in a different patch.
<rdar://problem/18683658>
llvm-svn: 221229
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
case that was reading target memory in TargetAPITestCase.test_read_memory_with_dsym and TargetAPITestCase.test_read_memory_with_dwarf.
The problem was that SBTarget::ReadMemory() was making a new section offset lldb_private::Address by doing:
size_t
SBTarget::ReadMemory (const SBAddress addr,
void *buf,
size_t size,
lldb::SBError &error)
{
...
lldb_private::Address addr_priv(addr.GetFileAddress(), NULL);
bytes_read = target_sp->ReadMemory(addr_priv, false, buf, size, err_priv);
This is wrong. If you get the file addresss from the "addr" argument and try to read memory using that, it will think the file address is a load address and it will try to resolve it accordingly. This will work fine if your executable is loaded at the same address (no slide), but it won't work if there is a slide.
The fix is to just pass along the "addr.ref()" instead of making a new addr_priv as this will pass along the lldb_private::Address that is inside the SBAddress (which is what we want), and not always change it into something that becomes a load address (if we are running), or abmigious file address (think address zero when you have 150 shared libraries that have sections that start at zero, which one would you pick). The main reason for passing a section offset address to SBTarget::ReadMemory() is so you _can_ read from the actual section + offset that is specified in the SBAddress.
llvm-svn: 221213
|
|
|
|
|
|
|
|
| |
Objective-C runtime. We'll need to do more
(subclasses, partially-defined classes, etc.)
but this tests that at least the basics work.
llvm-svn: 221208
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When processes are launched for debugging on Windows now, LLDB
will detect changes such as DLL loads and unloads, breakpoints,
thread creation and deletion, etc.
These notifications are not yet propagated to LLDB in a way that
LLDB understands what is happening with the process. This only
picks up the notifications from the OS in a way that they can be
sent to LLDB with subsequent patches.
Reviewed by: Scott Graham
Differential Revision: http://reviews.llvm.org/D6037
llvm-svn: 221207
|
|
|
|
|
|
| |
get hit so it doesn't intermittently fail on MacOSX.
llvm-svn: 221201
|
|
|
|
|
|
| |
data section name for all file formats. Instead fix the test by finding the section by section type so the test is agnostic to the file format (and passes on MacOSX).
llvm-svn: 221197
|