On FreeBSD ptrace(PT_KILL) is used to terminate the traced process
(as if PT_CONTINUE had been used with SIGKILL as the signal to be
delivered), and is the desired behaviour for ProcessPOSIX::DoDestroy.
On Linux, after ptrace(PTRACE_KILL) the traced process still exists
and can be interrogated. It is only upon resume that it exits as though
it received SIGKILL.
As the Linux PTRACE_KILL behaviour is not used by LLDB, rename
BringProcessIntoLimbo to Kill, and change the implementation to simply
call kill() instead of using ptrace.
Thanks to Todd F for testing (Ubuntu 12.04, gcc 4.8.2).
Sponsored by: DARPA, AFRL
Differential Revision: http://llvm-reviews.chandlerc.com/D3159
llvm-svn: 205337
On FreeBSD ptrace(PT_KILL) is used to terminate the traced process
(as if PT_CONTINUE had been used with SIGKILL as the signal to be
delivered), and is the desired behaviour for ProcessPOSIX::DoDestroy.
On Linux, after ptrace(PTRACE_KILL) the traced process still exists
and can be interrogated. It is only upon resume that it exits as though
it received SIGKILL.
For now I'm committing only the FreeBSD change, until the Linux change
(review D3159) is successfully tested.
http://llvm.org/pr18894
llvm-svn: 205315
Fix Windows build by adding JITLoaderGDB and ProcessElfCore.
RegisterContext: fixes for Windows build: sizeof(GPR::register) didn't work, switched to sizeof(((GPR*)NULL)->register).
llvm-svn: 203667
memcpy cannot be passed NULL. Ensuring that the destination pointer is non-NULL
requires checking success. Rather than performing the success check at that
point, increasing indentation an additional level, fold it into the previous
statement.
llvm-svn: 203359
This change uses a fixed known offset for the Linux i386 DR0 register.
This change also undoes the 32-bit wordsize change from r169645 that
revolved around being 32-bit/64-bit friendly in
WriteRegOperation::Execute within the Linux ProcessMonitor.cpp. I ran
all the tests on x86_64 Linux with no failures. I also ran some simple
tests with 32-bit Linux exe on x86_64 host and 32-bit linux exe on
i686 32-bit host and these worked fine.
Note (from Todd): the UserData struct in the Linux i386 register
context (only used by Linux i386 host running Linux 32-bit inferior)
is out of sync with what shows up in the sys/user.h for an 32-bit
Linux build (per an earlier change of mine to make it look more like
x86_64 host running x86 exe). I think we should (1) make i386 Linux
targets run using the same register context (and correct ones) on i386
and x86_64 linux hosts if that is possible, and (2) we could use some
tests around the register handling, particularly to verify things like
DR0 registers are in the right spots on host/target combos that we can
verify vs. known correct values.
Change by Matthew Gardiner.
llvm-svn: 202887
This seems a little more straightforward and is equivalent to r201457
for ELF core files. A case for FreeBSD i386 is also added (it was
incorrectly using the 64-bit register context and corrupting mememory).
Better (user-facing) error handling is still needed.
Review: http://llvm-reviews.chandlerc.com/D2765
llvm-svn: 202549
This change fixes up issues with specifying the size of the i386
register infos for FPU registers. The bug was that for the i386
register context, the size of the FPU registers were still being
computed based on the x86_64 FXSAVE structure.
This change permits the FPR_SIZE macro to optionally be defined
outside of RegisterInfos_i386.h, which RegisterContextLinux_i386.cpp
does properly. It redefines the FPR_i386 structure with all the
accessible parts that RegisterInfos_i386.h wants to see, which we had
not done before when we made the overall size of the structure
properly sized a recently.
This change also modifies POSIXThread to create a
RegisterContextLinux_i386 only when the host is 32-bit; otherwise, it
uses the RegisterContextLinux_x86_64, which works properly for 32-bit
and 64-bit inferiors on a 64-bit host.
I tested this debugging a Linux x86 exe on an x86 host (Ubuntu 13.10
x86), and debugging a Linux x86 exe and a Linux x86-64 exe on an
x86-64 host (Ubuntu 12.04 LTS). Those cases all worked.
Thanks to Matthew Gardiner who discoverd may key insights into
tracking down the issue. The motivation for this change and some of
the code originates from him via this thread:
http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140224/010554.html
llvm-svn: 202428
This fix changes thee x86 32-bit floating point register area to be
the proper size independent of the host platform.
Note as of this change list, this register context is not yet used
since selecting it exposes issues with watchpoint assertions.
Change by Matthew Gardiner.
llvm-svn: 202285
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
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
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
To make this work this patch extends LLDB to:
- Explicitly track the link_map address for each module. This is effectively the module handle, not sure why it wasn't already being stored off anywhere. As an extension later, it would be nice if someone were to add support for printing this as part of the modules list.
- Allow reading the per-thread data pointer via ptrace. I have added support for Linux here. I'll be happy to add support for FreeBSD once this is reviewed. OS X does not appear to have __thread variables, so maybe we don't need it there. Windows support should eventually be workable along the same lines.
- Make DWARF expressions track which module they originated from.
- Add support for the DW_OP_GNU_push_tls_address DWARF opcode, as generated by gcc and recent versions of clang. Earlier versions of clang (such as 3.2, which is default on Ubuntu right now) do not generate TLS debug info correctly so can not be supported here.
- Understand the format of the pthread DTV block. This is where it gets tricky. We have three basic options here:
1) Call "dlinfo" or "__tls_get_addr" on the inferior and ask it directly. However this won't work on core dumps, and generally speaking it's not a good idea for the debugger to call functions itself, as it has the potential to not work depending on the state of the target.
2) Use libthread_db. This is what GDB does. However this option requires having a version of libthread_db on the host cross-compiled for each potential target. This places a large burden on the user, and would make it very hard to cross-debug from Windows to Linux, for example. Trying to build a library intended exclusively for one OS on a different one is not pleasant. GDB sidesteps the problem and asks the user to figure it out.
3) Parse the DTV structure ourselves. On initial inspection this seems to be a bad option, as the DTV structure (the format used by the runtime to manage TLS data) is not in fact a kernel data structure, it is implemented entirely in useerland in libc. Therefore the layout of it's fields are version and OS dependent, and are not standardized.
However, it turns out not to be such a problem. All OSes use basically the same algorithm (a per-module lookup table) as detailed in Ulrich Drepper's TLS ELF ABI document, so we can easily write code to decode it ourselves. The only question therefore is the exact field layouts required. Happily, the implementors of libpthread expose the structure of the DTV via metadata exported as symbols from the .so itself, designed exactly for this kind of thing. So this patch simply reads that metadata in, and re-implements libthread_db's algorithm itself. We thereby get cross-platform TLS lookup without either requiring third-party libraries, while still being independent of the version of libpthread being used.
Test case included.
llvm-svn: 192922
Just pass a Target* into ObjectFileELF::GetImageInfoAddress so that
it can do the extra dereference necessary on MIPS, instead of passing
a flag back to the caller.
Review: http://llvm-reviews.chandlerc.com/D1899
llvm-svn: 192469
MIPS's .dyanamic section is read-only. Instead of using DT_DEBUG for
the pointer to dyld information it uses a separate tag DT_MIPS_RLD_MAP
which points to storage in the read-write .rld_map section, which in
turn points to the dyld information.
Review: http://llvm-reviews.chandlerc.com/D1890
llvm-svn: 192408
Based on the POSIX x86_64 register context. This is sufficient for opening
a mips64 (big endian) core file. Subsequent changes will connect the
disassembler, dynamic loader support, ABI, etc.
Review: http://llvm-reviews.chandlerc.com/D1873
llvm-svn: 192335
Use 32-bit register enums without gaps on 64-bit hosts.
Don't show 64-bit registers when debugging 32-bit targets.
Add psuedo gpr registers (ax, ah, al, etc.)
Add mmx registers.
Fix TestRegisters.py to not read ymm15 register on 32-bit targets.
Fill out and move gcc/dwarf/gdb register enums to RegisterContext_x86.h
llvm-svn: 192263
Instead of directly manipulating the thread list in Launch and Attach,
just rely on RefreshStateAfterStop to populate the initial list.
Review: http://llvm-reviews.chandlerc.com/D1565
llvm-svn: 189889
On Linux there is no separate notion of a process (vs. a thread) for
ptrace(); each thread needs to be individually detached. On FreeBSD
we have a separate process context, and we detach just it.
Review: http://llvm-reviews.chandlerc.com/D1418
llvm-svn: 189666
Summary:
This merge brings in the improved 'platform' command that knows how to
interface with remote machines; that is, query OS/kernel information, push
and pull files, run shell commands, etc... and implementation for the new
communication packets that back that interface, at least on Darwin based
operating systems via the POSIXPlatform class. Linux support is coming soon.
Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS
X Mountain Lion.
Additional improvements (not in the source SVN branch 'lldb-platform-work'):
- cmake build scripts for lldb-platform
- cleanup test suite
- documentation stub for qPlatform_RunCommand
- use log class instead of printf() directly
- reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely.
- add new logging category 'platform'
Reviewers: Matt Kopec, Greg Clayton
Review: http://llvm-reviews.chandlerc.com/D1493
llvm-svn: 189295
Created new LinuxThread class inherited from POSIXThread and removed linux / freebsd ifdefs
Removed several un-needed set thread name calls
CR (and multiple suggestions): mkopec
llvm-svn: 187545
Instantiate RegisterContext... based on getOS() instead of with
compile-time #ifdef-ery.
The assert() here is unfortunate, but better than crashing with no
explanation.
This change is equivalent to r186865 for elf-core.
llvm-svn: 187422
Usage: 'lldb a.out -c core'.
TODO: FreeBSD support.
TODO: Support for AVX registers.
TODO: Refactor so that RegisterContextCore* don't inherit from classes that use ProcessMonitor
to fix the build on OS/X.
llvm-svn: 186516
RegisterContextCoreLinux_x86_64 inherits from RegisterContextLinux_x86_64 which inherits from RegisterContext_x86_64 which uses has:
ProcessMonitor &GetMonitor();
This register context used by the core file can't use this since the process plug-in will be ProcessElfCore and the implementation of GetMonitor() does:
ProcessMonitor &
RegisterContext_x86_64::GetMonitor()
{
ProcessSP base = CalculateProcess();
ProcessPOSIX *process = static_cast<ProcessPOSIX*>(base.get());
return process->GetMonitor();
}
ProcessELFCore doesn't, nor should it inherit from ProcessPOSIX and any call to GetMonitor() will fail for ELF core files.
Suggested cleanups:
- Make a register context class that is a base class that doesn't have any reading smarts, then make one that uses ProcessPOSIX and the has the GetMonitor() call, and one that gets its data straight from the core file.
llvm-svn: 186223
Andrew MacPherson