| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Differential Revision: http://llvm-reviews.chandlerc.com/D2826
llvm-svn: 202028
|
| |
|
|
| |
llvm-svn: 201897
|
| |
|
|
|
|
|
|
| |
successfully called it
on the debugserver side) when we kill a process or it leaves a zombie around.
llvm-svn: 201896
|
| |
|
|
|
|
| |
tests how long it takes to send a 4MB buffer from the REMOTE GDB server to LLDB.
llvm-svn: 201875
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
class. If we try to unwind a stack frame to find a caller stack
frame, and we fail to get a valid-looking frame, AND if the UnwindPlan
we used is an assembly-inspection based UnwindPlan, then we should
throw away the assembly-inspection UnwindPlan and try unwinding with
the architectural default UnwindPlan.
This code path won't be taken if eh_frame unwind instructions are available -
lldb will always prefer those once it's off the zeroth frame.
The problem I'm trying to fix here is the class of unwind failures that
happen when we have hand-written assembly on the stack, with no eh_frame,
and lldb's assembly parser fails to understand the assembly. People usually
write their hand-written assembly to follow the frame-pointer-preserving
conventions of the platform so the architectural default UnwindPlan will
often work. We won't have the spill location for most of the non-volatile
registers if we fall back to this, but it's better than stopping the unwind
prematurely.
This is a bit of a tricky change that I believe is correct, but if we get
unwinds that go of into the weeds / unwind bogus frames at the end of the
stack, I'll need to revisit it.
<rdar://problem/16099440>
llvm-svn: 201839
|
| |
|
|
|
|
| |
thread information.
llvm-svn: 201773
|
| |
|
|
|
|
| |
llvm.org/pr18894
llvm-svn: 201724
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement x86_64 debug register read/write in support of hardware
watchpoints. Hoist LinuxThread::TraceNotify code back into
POSIXThread::TraceNotify()
Patch by John Wolfe.
We still need to rework this later to avoid the #ifdef FreeBSD.
llvm-reviews.chandlerc.com/D2572
llvm.org/pr16706
llvm-svn: 201706
|
| |
|
|
|
|
|
|
|
|
|
| |
This way the same RegisterContext class can support i386 and
amd64/x86_64 core files.
With some further refinement we should be able to merge all of the
processor-specific RegisterContextPOSIX_* classes into a single shared
one.
llvm-svn: 201577
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ProcessElfCore::ParseThreadContextsFromNoteSegment was leaking
ThreadData for each ELF note found in core file. We now allocate it
only once and use std::unique_ptr to ensure it is always being freed.
While at it make ParseFreeBSDThrMisc and ParseFreeBSDPrStatus take
ThreadData by reference, rather than pointer, since those arguments are
not optional.
Patch by Piotr Rak.
http://llvm-reviews.chandlerc.com/D2813
llvm-svn: 201473
|
| |
|
|
|
|
|
|
|
|
| |
This seems like a more straightforward approach for instantiating the
appropriate RegisterContext* class, made possible by Michael Sartain's
cleanup of the POSIX RegisterContext class hierarchy in r190647.
Better (user-facing) error handling is still needed.
llvm-svn: 201457
|
| |
|
|
| |
llvm-svn: 201435
|
| |
|
|
| |
llvm-svn: 201434
|
| |
|
|
|
|
|
|
|
|
|
|
| |
specify a list of functions which should be treated as trap handlers.
This will be primarily useful to people working in non-user-level
process debugging - kernels and other standalone environments.
For most people, the trap handler functions provided by the Platform
plugin will be sufficient.
<rdar://problem/15835846>, <rdar://problem/15982682>
llvm-svn: 201386
|
| |
|
|
|
|
|
|
|
| |
operating system plugins, and other async python usage.
<rdar://problem/16054348>
<rdar://problem/16040833>
llvm-svn: 201372
|
| |
|
|
|
|
|
|
| |
Michael Sartain refactored RegisterContextPOSIX_* in r192332, and I must
have missed the now-shadowed variable when I rebased the FreeBSD MIPS64
register context after that.
llvm-svn: 201334
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
aka asynchronous signal handlers, which subclasses should fill
in as appropriate. For most Unix user process environments,
the one entry in this list is _sigtramp. For bare-board and
kernel environments, there will be different sets of trap
handlers.
The unwinder needs to know when a frame is a trap handler
because the rules it enforces for the frame "above" the
trap handler is different from most middle-of-the-stack frames.
<rdar://problem/15835846>
llvm-svn: 201300
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Elf core files were collapsing core segments when the virtual memory
addresses were contiguous without checking if the core-file-backed
memory region was the same size as the segment's VMA region. Without
this extra check, any time regions were collapsed but the core-backed
region was smaller (and thus had a zero-filled hole at the end), the
collapse operation would break VMA to core file lookups for subsequent
collapsed regions.
This change fixes the following bug:
http://llvm.org/bugs/show_bug.cgi?id=18769
llvm-svn: 201214
|
| |
|
|
| |
llvm-svn: 201027
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
libldi library to collect extended backtrace information; switch
to the libBacktraceRecording library and its APIs. Complete the
work of adding QueueItems to Queues and allow for the QueueItems
to be interrogated about their extended backtraces in turn.
There's still cleanup and documentation to do on this code but the
code is functional and I it's a good time to get the work-in-progress
checked in.
<rdar://problem/15314027>
llvm-svn: 200822
|
| |
|
|
|
|
|
| |
This is SVN r191618 by Sylvestre Ledru applied to the FreeBSD
ProcessMonitor.
llvm-svn: 200791
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes http://llvm.org/bugs/show_bug.cgi?id=18656.
Note this exposes a failure on Linux of
TestInferiorAssert.test_inferior_asserting_disassemble, similar to how
it fails on FreeBSD. I'll file a bug for this next. We're now getting
another frame beyond where we used to prior to this fix, so the fix is
exposing failures in previosly not-reachable frames.
Much thanks to Jason Molenda, who had much to do with helping figure
out where unwinding was breaking.
llvm-svn: 200600
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GDBProcessCommunicationServer now optionally takes a PlatformSP that
defaults to the default platform for the host.
GDBProcessCommunicationServer::LaunchProcess () now uses the platform
to launch the process.
lldb-gdbserver now takes an optional --platform={platform_plugin_name}
or -p {platform_plugin_name} command line option. If no platform is
specified, the default platform for the host is used; otherwise, if
the platform_plugin_name matches a registered platform plugin or
matches the default platform's name (which is not necessarily
registered by name in the case of 'host'), that platform is used. If
the platform name cannot be resolved, lldb-gdbserver exits after
printing all the available platform plugin names and the default
platform plugin name.
llvm-svn: 200266
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The many many benefits include:
1 - Input/Output/Error streams are now handled as real streams not a push style input
2 - auto completion in python embedded interpreter
3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use
4 - it is now possible to use curses to drive LLDB (please try the "gui" command)
We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases.
llvm-svn: 200263
|
| |
|
|
|
|
|
|
|
| |
if the remote stub provided enough information to identify it in the
qProcessInfo packet response. (e.g. for an Apple device where we know
it is Mach-O, the cpu type & cpu sub type).
<rdar://problem/15847901>
llvm-svn: 200253
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This change modifies the 'A' command handler's launch code to launch
with LaunchProcess (). The net effect is that the default process
monitoring that LaunchProcess () adds will kick in, allowing the
GDBRemoteCommunicationServer to be able to reap processes started with
this facility correctly. Later, in the case of lldb-gdbserver, we'll
also have the proper process monitoring going on to really debug the
inferior process.
llvm-svn: 200246
|
| |
|
|
|
|
|
|
|
|
| |
This patch addresses a bug where in a multi-threaded program a new
signal from the inferior may be received before all group-stop
messages from an earlier signal have been handled.
Patch by Andrew MacPherson
llvm-svn: 200226
|
| |
|
|
|
|
| |
Spotted by John Wolfe.
llvm-svn: 200092
|
| |
|
|
|
|
|
|
|
|
| |
There are a couple of pieces:
* some lazy-evaluation members that store info listed in a qSupported response
* new method SendPacketsAndConcatenateResponses which is used for
fetching fixed-size objects from the remote gdbserver by using multiple
packets if necessary (first use will be to fetch shared-library XML files).
llvm-svn: 200072
|
| |
|
|
|
|
|
|
|
|
| |
GDBRemoteCommunication::StartDebugserverProcess
right after the space for it is allocated on the stack, instead of trying
to initialize it in all the different places in this method. It's too easy
for another uninitialized code path to sneak in as it is written right now.
llvm-svn: 200066
|
| |
|
|
|
|
| |
Patch by Andrew MacPherson.
llvm-svn: 200049
|
| |
|
|
|
|
|
|
| |
it later in GDBRemoteCommunication::StartDebugserverProcess and report
an error.
<rdar://problem/15820813>
llvm-svn: 200047
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GDBRemoteCommunicationServer::LaunchProcess () now uses the built-up
ProcessLaunchArgs rather than clearing and setting items from the
function arguments. I added setters for the arguments and launch
flags, which lldb-gdbserver uses for its specification of the
commandline-specified startup app (if one is specified).
LaunchProcess () also adds a new reaper monitor that it applies to
the launched process if no process monitor has already been applied.
This addresses an issue where the 'k' command would generate (possibly
false) warnings about not being able to positively state whether a
killed process actually terminated. GDBRemoteCommunicationServer now
definitely knows the disposition of its children.
llvm-svn: 199959
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lldb-gdbserver was launching the commandline-specified launch process
directly, without GDBRemoteCommunicationServer knowing anything about
it. As GDBRemoteCommunicationServer is the piece that manages and
knows about processes that the gdb remote protocol discusses with
the client end, it is important that it know about launched processes.
This change also implements the k gdb remote protocol message, having it
kill all known spawned processes when it is received.
(Note: in lldb-gdbserver, the spawned processes are not properly
monitored yet. The response to the k packet will complain that
spawned processes do not really appear to be getting killed even if
they are. This will get addressed soon.)
llvm-svn: 199945
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ArchSpec now contains an optional distribution_id, with getters and
setters. Host::GetArchitecture () sets it on non-Apple platforms using
Host::GetDistributionId (). The distribution_id is ignored during
ArchSpec comparisons.
The gdb remote qHostInfo message transmits it, if set, via the
distribution_id={id-value} key/value pair. Updated gdb remote docs to
reflect this change.
As before, GetDistributionId () returns nothing on non-Linux platforms
at this time. On Linux, it is returned only if the lsb_platform
command is installed (in /bin or /usr/bin), and only if the
distributor id key is returned by 'lsb_platform -i'. This id is
lowercased, and whitespace is replaced with underscores.
llvm-svn: 199539
|
| |
|
|
| |
llvm-svn: 199432
|
| |
|
|
| |
llvm-svn: 199202
|
| |
|
|
| |
llvm-svn: 199111
|
| |
|
|
|
|
| |
debugging.
llvm-svn: 198977
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
evaluator to handle Indirect
symbols correctly. There were a couple of pieces to this.
1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created
it needs to resolve the symbol and actually set the site at its target.
2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the
specified address, so somem machinery was needed to specify that.
3) I added some info to the break list output for indirect symbols so you could see what was happening.
Also I made it clear when we re-route through re-exported symbols.
4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X
and the other posix systems. If we find a platform that doesn't do it this way, they can override the
call in Process.
5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had
been broadcast, the event coalescing would cause you to miss the ThreadPlan running event. So I added
a way to override the coalescing.
6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols.
<rdar://problem/15280639>
llvm-svn: 198976
|
| |
|
|
|
|
|
|
| |
iOS. The sandboxing is not letting debugserver reverse connect back to lldb.
<rdar://problem/15789865>
llvm-svn: 198963
|
| |
|
|
|
|
|
|
|
|
| |
I previously fixed a bug in the SocketAddress class where SocketAddress::GetPort() wasn't using ntohs() on the port number in the structures.
After fixing this, it broke places where we weren't using ntohs() and htons() correctly.
<rdar://problem/15767514>
llvm-svn: 198902
|
| |
|
|
|
|
|
|
|
|
| |
This change fixes a bug recently introduced in ProcessGDBRemote that
prevented the Python register definition file from getting loaded when
the qRegisterInfo0 response returned $00#.
Patch by Steve Pucci.
llvm-svn: 198742
|
| |
|
|
|
|
|
|
|
| |
The former will set the Address object's offset to the load address value if
it is not present in any section; the latter will only set the Address object
if the load addr is contained in one of its sections.
<rdar://problem/15135987>
llvm-svn: 198469
|
| |
|
|
|
|
|
|
|
|
| |
its stack frame is a constructed, fake thing that may not conform
correctly to these rules. This fixes a problem where lldb couldn't
backtrace past an asynchronous signal handler (_sigtramp) frame on
a stack on Mac OS X.
<rdar://problem/15035673>
llvm-svn: 198450
|
| |
|
|
|
|
| |
<rdar://problem/15745397>
llvm-svn: 198447
|
| |
|
|
|
|
|
|
|
|
| |
interpret core files that contain both a user
process dyld and a kernel executable in them.
Fix an additional method that needs to be
adjusted depending on this preference as well.
<rdar://problem/15721409>
llvm-svn: 197931
|
| |
|
|
|
|
|
|
|
|
| |
parameter is redundant as this information is already provided by the ProcessAttachInfo parameter.
CC: lldb-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2463
llvm-svn: 197923
|
| |
|
|
|
|
|
|
|
|
| |
it needs to fall back to using the HostArchitecture if a valid one is not
returned. When doing low-level system debugging we may not have a process
(or the remote stub may not support the qProcessInfo packet) in which case
we should fall back to the architecture we determined via qHostInfo.
<rdar://problem/15713180>
llvm-svn: 197857
|
| |
|
|
|
|
|
|
|
|
|
| |
The original code was not completely correct, but a form of
this check is necessary to avoid an infinite recursion on
some unwind cases where a function unwinds to itself with the
same CFA. Ashok thought the recursion would be caught in
RegisterContextLLDB but this one isn't - we still need it here.
<rdar://problem/15664282>
llvm-svn: 197761
|