| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
something; add a new ExtendedThreadList to Process where they can be retained
for the duration of a public stop.
<rdar://problem/15314068>
llvm-svn: 194367
|
|
|
|
|
|
| |
There were 6 on darwin. All of these were related to the recent changes for exec.
llvm-svn: 194298
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
llvm::ArrayRef of arguments rather than taking
a fixed number of possibly-NULL pointers to
arguments.
Also changed ClangFunction::GetThreadPlanToCallFunction
to take the address of the argument struct by value
instead of by reference, since it doesn't actually
modify the value passed into it.
llvm-svn: 194232
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It completes the job of using EvaluateExpressionOptions consistently throughout
the inferior function calling mechanism in lldb begun in Greg's patch r194009.
It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which
were there for convenience. Using the EvaluateExpressionOptions removes the need for them.
Using that it gets the --debug option from Greg's patch to work cleanly.
It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't
use this option unless you KNOW your expression can't throw beyond itself. This is:
<rdar://problem/15374885>
At present this is only available through the SB API's or python.
It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether
they were set by somebody else already.
llvm-svn: 194182
|
|
|
|
|
|
|
| |
bit from the method names.
<rdar://problem/15314369>
llvm-svn: 194122
|
|
|
|
|
|
|
| |
SystemRuntime and SBThread classes.
<rdar://problem/15314369>
llvm-svn: 194111
|
|
|
|
|
|
|
|
| |
Fixed the test case for "test/functionalities/exec/TestExec.py" on Darwin.
The issue was breakpoints were persisting and causing problems. When we exec, we need to clear out the process and target and start fresh with nothing and let the breakpoints populate themselves again. This patch correctly clears out the breakpoints and also flushes the process so that the objects (process/thread/frame) give out valid information.
llvm-svn: 194106
|
|
|
|
|
|
|
| |
SystemRuntime class.
<rdar://problem/15314369>
llvm-svn: 194045
|
|
|
|
|
|
|
| |
class, not any actual plugin implementation yet.
<rdar://problem/15314068>
llvm-svn: 194044
|
|
|
|
|
|
|
|
| |
Instead of looking up registers by name, we use the generic ID when we can.
Also added code that creates an extra frame when running expressions by pushing the current PC and FP and then hooking up the FP backchain. This code is "#if 0" out for now until we can pair it with unwinder fixes.
llvm-svn: 194035
|
|
|
|
|
|
|
|
| |
Cleaned up ClangUserExpression::Evaluate() to have only one variant that takes a "const EvaluateExpressionOptions& options" instead of taking many arguments.
The "--debug" option is designed to allow you to debug your expression by stopping at the first instruction (it enables --ignore-breakpoints=true and --unwind-on-error=false) and allowing you to step through your JIT code. It needs to be more integrated with the thread plan, so I am checking this in so Jim Ingham can make it happen.
llvm-svn: 194009
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
at some point in the past. We may have nothing more than a pc value
for this type of stack frame -- hopefully we'll have a pc and a
stop_id so we can track module loads and unloads over time and
symbolicate the pc at the correct point in time.
Also add a flag to indicate if the CFA for the frame is available
(a bit different from a CFA of LLDB_INVALID_ADDRESS) and also an
overall setting to indicate whether this is a history stack frame
or not. A history stack frame may not have a CFA, it may not have
a register context, it may not have variables, it may not have a
frame pointer or a stack pointer.
<rdar://problem/15314068>
llvm-svn: 193987
|
|
|
|
|
|
|
|
|
|
| |
pure virtual base class and made StackFrame a subclass of that. As
I started to build on top of that arrangement today, I found that it
wasn't working out like I intended. Instead I'll try sticking with
the single StackFrame class -- there's too much code duplication to
make a more complicated class hierarchy sensible I think.
llvm-svn: 193983
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
defines a protocol that all subclasses will implement. StackFrame
is currently the only subclass and the methods that Frame vends are
nearly identical to StackFrame's old methods.
Update all callers to use Frame*/Frame& instead of pointers to
StackFrames.
This is almost entirely a mechanical change that touches a lot of
the code base so I'm committing it alone. No new functionality is
added with this patch, no new subclasses of Frame exist yet.
I'll probably need to tweak some of the separation, possibly moving
some of StackFrame's methods up in to Frame, but this is a good
starting point.
<rdar://problem/15314068>
llvm-svn: 193907
|
|
|
|
|
|
|
|
|
|
| |
In almost all cases, the misuse is about "%lu" being used instead of the correct "%zu" (even though these are compatible on 64-bit platforms in practice). There are even a couple of cases where "%ld" (ie., signed int) is used instead of "%zu", and one where "%lu" is used instead of "%" PRIu64.
Fixes bug #17551.
Patch by "/dev/humancontroller"
llvm-svn: 193832
|
|
|
|
|
|
| |
<rdar://problem/15208799>
llvm-svn: 193530
|
|
|
|
| |
llvm-svn: 193488
|
|
|
|
|
|
| |
macros.
llvm-svn: 193260
|
|
|
|
| |
llvm-svn: 193159
|
|
|
|
|
|
| |
<rdar://problem/15252474>
llvm-svn: 192989
|
|
|
|
|
|
|
|
|
|
| |
thread
has gone away by the time they get around to doing it.
<rdar://problem/15245544>
llvm-svn: 192987
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the __thread modifier.
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
|
|
|
|
|
|
|
|
| |
Added a way to set hardware breakpoints from the "breakpoint set" command with the new "--hardware" option. Hardware breakpoints are not a request, they currently are a requirement. So when breakpoints are specified as hardware breakpoints, they might fail to be set when they are able to be resolved and should be used sparingly. This is currently hooked up for GDB remote debugging.
Linux and FreeBSD should quickly enable this feature if possible, or return an error for any breakpoints that are hardware breakpoint sites in the "virtual Error Process::EnableBreakpointSite (BreakpointSite *bp_site);" function.
llvm-svn: 192491
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Remove 32-bit POSIX register hack in ConvertBetweenRegisterKinds.
llvm-svn: 192306
|
|
|
|
|
|
|
|
|
| |
already in the stopped state
- By default, the above function will wait for at least one event
- Set wait_always=false to make the function return immediately if the process is already stopped
llvm-svn: 192301
|
|
|
|
|
|
|
| |
Implement SBTarget::CreateValueFromAddress() with a behavior equivalent to SBValue::CreateValueFromAddress()
(but without the need to grab an SBValue first just as a starting point to make up another SBValue out of whole cloth)
llvm-svn: 192239
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to be explicit, to prevent horrid things like
std::string a = ConstString("foo")
from taking the path ConstString -> bool -> char
-> std::string.
This fixes, among other things, ClangFunction.
<rdar://problem/15137989>
llvm-svn: 191934
|
|
|
|
|
|
|
|
|
|
| |
line that should
not have breakpoints set on it inserted into code that does have a valid line number. So allow
that line number, and the ThreadPlanStepRange should just continue stepping over 0 line ranges
as if they had the same line number as whatever we were previously stepping through.
llvm-svn: 191477
|
|
|
|
|
|
| |
of the function.)
llvm-svn: 191476
|
|
|
|
| |
llvm-svn: 191367
|
|
|
|
|
|
|
|
|
|
| |
values while passing an SBValue to a synthetic child provider, or incur an endless recursion
Now that SBValues can be setup to ignore synthetic values, this is no longer necessary, and so m_suppress_synthetic_value can go away
Another Hack Bites the Dust
llvm-svn: 191338
|
|
|
|
|
|
|
|
| |
- searches frames beginning from the current frame, stops when an equivalent context is found
- not using GetStackFrameCount() for performance reasons
- fixes TestInlineStepping (clang/gcc buildbots)
llvm-svn: 190868
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with prefer_file_cache == false. This is what we want to do when
the user is doing a disassemble command -- show the actual memory
contents in case the memory has been corrupted or something -- but
when we're profiling functions for stepping or unwinding
(ThreadPlanStepRange::GetInstructionsForAddress,
UnwindAssemblyInstEmulation::GetNonCallSiteUnwindP) we can read
__TEXT instructions directly out of the file, if it exists.
<rdar://problem/14397491>
llvm-svn: 190638
|
|
|
|
|
|
|
|
|
| |
This allows the PC to be directly changed to a different line.
It's similar to the example python script in examples/python/jump.py, except implemented as a builtin.
Also this version will track the current function correctly even if the target line resolves to multiple addresses. (e.g. debugging a templated function)
llvm-svn: 190572
|
|
|
|
|
|
|
|
|
|
| |
depends on the
setting of the environment variable COMMAND_MODE. Changed the Platform::GetResumeCountForShell
to Platform::GetResumeCountForLaunchInfo, and check both the shell and in the case of
/bin/sh the environment as well.
llvm-svn: 190538
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that /bin/sh re-exec's itself to /bin/bash, so it needs one more resume when you
are using it as the shell than /bin/bash did or you will stop at the start of your
program, rather than running it.
So I added a Platform API to get the number of resumes needed when launching with
a particular shell, and set the right values for Mac OS X.
<rdar://problem/14935282>
llvm-svn: 190381
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From Jim's post on the lldb-dev mailing list:
This code is there as a backstop for when the unwinder drops a frame at
the beginning of new function/trampoline or whatever.
In the (older_ctx_is_equivalent == false) case we will see if we are at
a trampoline function that somebody knows how to get out of, and
otherwise we will stop.
llvm-svn: 190149
|
|
|
|
| |
llvm-svn: 190063
|
|
|
|
|
|
|
|
| |
/bin/sh is more portable, and all systems with /bin/bash are expected to
have /bin/sh as well, even if only a link to bash.
Review: http://llvm-reviews.chandlerc.com/D1576
llvm-svn: 189879
|
|
|
|
| |
llvm-svn: 189355
|
|
|
|
| |
llvm-svn: 189317
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
portability.
llvm-svn: 189107
|
|
|
|
|
|
| |
32-bit Linux targets.
llvm-svn: 188954
|
|
|
|
|
|
| |
Improve the documentation for the new target.memory-module-load-level setting, and also return an error when there is no nlist data when appropriate.
llvm-svn: 188317
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLDB needs in memory module load level settings to control how much information is read from memory when loading in memory modules. This change adds a new setting:
(lldb) settings set target.memory-module-load-level [minimal|partial|complete]
minimal will load only sections (no symbols, or function bounds via function starts or EH frame)
partial will load sections + bounds
complete will load sections + bounds + symbols
llvm-svn: 188246
|
|
|
|
|
|
|
|
|
|
| |
- Immediates can be shown as hex (either Intel or MASM style)
- See TestSettings.py for usage examples
- Verified to cause no regressions on Linux x86_64 (Ubuntu 12.10)
Patch by Richard Mitton!
llvm-svn: 187921
|
|
|
|
| |
llvm-svn: 187900
|
|
|
|
|
|
|
| |
to a log channel in StopInfoBreakpoint::PerformAction().
<rdar://problem/14651751>
llvm-svn: 187833
|