I went back and forth on removing this - and tried dropping it for
a few weeks. But when you're working at an assembly language, it
really is helpful to have this displayed to show where the current
pc is.
llvm-svn: 221682
being asked about symbols it doesn't know about. If
it's asked about a symbol by mangled name and it finds
nothing, then it will try again with the demangled
base name.
llvm-svn: 221660
runtime. This eliminates potential confusion
when the compiler has to deal with these weird
types later on.
One day I'd like to actually generate the proper
templates, but this is not the day that I write
the parser code to do that.
<rdar://problem/18887634>
llvm-svn: 221658
- A correctness issue: with assertions disabled,
ReadQuotedString would misbehave; and
- A performance issue: BuildType used a long
chain of if()s; I changed that to two switch
statements. That also makes the code much
nicer to step through when debugging it.
llvm-svn: 221651
structures are parsed safely by the Objective-C runtime.
Also made some modifications to the way we parse structs
in the runtime to avoid mis-parsing @ followed by the name
of the next field.
<rdar://problem/18887634>
llvm-svn: 221643
This patch implements basic support for stopping at breakpoints
and resuming later. While a breakpoint is stopped at, LLDB will
cease to process events in the debug loop, effectively suspending
the process, and then resume later when ProcessWindows::DoResume
is called.
As a side effect, this also correctly handles the loader breakpoint
(i.e. the initial stop) so that LLDB goes through the correct state
sequence during the initial process launch.
llvm-svn: 221642
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
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
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
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
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
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
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
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
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
a nop). Fixes an instruction stepping problem when trying to step
over the final instructions of an epilogue.
<rdar://problem/18068877>
llvm-svn: 221241
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
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
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
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
The details are: large packets (like large memory reads (m packets) or large binary memory reads (x packet)) can get responses that come in across multiple read() calls. The while loop that was added meant that if only a partial packet came in (like only "$abc" coming for a response) GDBRemoteCommunication::CheckForPacket() was called, it would deadlock in the while loop because no more data is going to come in as this function needs to be called again with more data from another read. So the original fix will need to be corrected and resubmitted.
<rdar://problem/18853744>
llvm-svn: 221181
Summary:
Instead of using a homegrown solution to get the auxv from a process, instead
use the OS-provided sysctl to get the needed data. This allows the same code to
be used for both 32-bit and 64-bit processes on a 64-bit host.
Reviewers: emaste
Reviewed By: emaste
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D6071
llvm-svn: 221063
Summary:
SIGPROF is used for profiling processes (with google-perftools for
instance), which results in the inferior receiving a SIGPROF from the
kernel every few milliseconds. Instead of stopping the debugging session
and notifying the user of this, we should just pass the signal and keep
running.
This follows the behavior we have in UnixSignals.cpp.
Test Plan: Run LLDB on linux with a binary using google-perftools, see that execution gets interrupted all the time because we receive SIGPROF. Apply the patch, everything works fine.
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D5953
llvm-svn: 221011
If it has an Address object, it is assumed to be Valid.
Change SBAddress to always have an Address object and check
whether it is valid or not in those case.
This is fixing a subtle problem where we ended up with
a SBAddress with an Address of LLDB_INVALID_ADDRESS could
run through a copy constructor and turn into an SBAddress
with no Address object being backed (because it wasn't
distinguishing between invalid-Address versus no-Address.)
The cost of an Address object is not high and this will be
an easy mistake for someone else to make; I'm fixing
SBAddress so it doesn't come up again.
<rdar://problem/18069407>
llvm-svn: 221002
the runtime rather than trying to fix it up,
because now those types have ivars regardless of
whether they come from "frame variable" or from
expressions.
Patch by Enrico Granata.
llvm-svn: 220982
Jason Molenda