back in r173096 by Greg. When constructing a g packet or parsing a G packet,
and we're iterate over our register list, skip registers that are actually
just slices of other, real, registers. For instance, eax is 32-bits of rax
on x86_64.
<rdar://problem/15104187>
llvm-svn: 191802
the name of the remote gdb-protocol server, and get
a version number from it. This can be useful if lldb
needs to interoperate with a gdb-protocol server with
a known issue or bug.
llvm-svn: 191729
- test wasn't checking for a stop reason before issuing the 'script' command
- should resolve intermittent failure on the Linux GCC buildbot
llvm-svn: 191708
DumpValueObject() 2.0
This checkin restores pre-Xcode5 functionality to the "po" (expr -O) command:
- expr now has a new --description-verbosity (-v) argument, which takes either compact or full as a value (-v is the same as -vfull)
When the full mode is on, "po" will show the extended output with type name, persistent variable name and value, as in
(lldb) expr -O -v -- foo
(id) $0 = 0x000000010010baf0 {
1 = 2;
2 = 3;
}
When -v is omitted, or -vcompact is passed, the Xcode5-style output will be shown, as in
(lldb) expr -O -- foo
{
1 = 2;
2 = 3;
}
- for a non-ObjectiveC object, LLDB will still try to retrieve a summary and/or value to display
(lldb) po 5
5
-v also works in this mode
(lldb) expr -O -vfull -- 5
(int) $4 = 5
On top of that, this is a major refactoring of the ValueObject printing code. The functionality is now factored into a ValueObjectPrinter class for easier maintenance in the future
DumpValueObject() was turned into an instance method ValueObject::Dump() which simply calls through to the printer code, Dump_Impl has been removed
Test case to follow
llvm-svn: 191694
scan-build was complaining about:
The return value from the call to 'setgid' is not checked. If an error occurs in 'setgid', the following code may execute with unexpected privileges
llvm-svn: 191618
line breakpoints past the prologue of functions so it can be shared between the
file & line breakpoint resolver, and the source pattern breakpoint resolver,
and then share it.
llvm-svn: 191478
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
- Removes the block in UnwindLLDB::AddOneMoreFrame that tests for a bad stack setup,
since it is neither correct (tests the FP GPR), complete (doesn't consider multi-frame
cycles), nor reachable (the construction of RegisterContextLLDB will fail in the case
where either of the two (why just two?) previous frames have the same canonical frame
address as the frame that we propose adding to the stack).
llvm-svn: 191430
el_gets was using fflush to output it's string, but because we have our own filter running on the piped pty output, fflush only causes the prompt to be written into the pipe, and does not cause the filter code to run immediately.
The simplest fix is to manually block and wait for all editline output to be processed.
This fixes PR 14637.
llvm-svn: 191392
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
to build out the symbol table as addresses are used, and implements
the mechanism for ELF to add stripped symbols from eh_frame.
Uses this mechanism to allow disassembly for addresses corresponding
to stripped symbols for ELF, and provide hooks to implement this for
PE COFF.
Also removes eSymbolContextTailCall in favor of an option for
ResolveSymbolContextForAddress for consistency with the documentation
for eSymbolContextEverything. Essentially, this is just an option for
interpreting the so_addr.
llvm-svn: 191307
the CFA instructions when it was profiling an -fomit-frame-pointer function
and a "volatile" register was saved on the stack (e.g. an argument register).
<rdar://problem/15036546>
llvm-svn: 191267
default-at-first-instruction UnwindPlan if we're at the beginning of a function and
the ABI can provide us with an UnwindPlan to get out of there before falling back
to the generic architectural default UnwindPlan (which usually assumes that the stack
has already been set up.)
Update the FuncUnwinders methods to gracefully handle the case where an assembly
profiler may not be available.
Fix a bug where FuncUnwinders::GetUnwindPlanArchitectureDefaultAtFunctionEntry was
returning the wrong UnwindPlan to its caller.
llvm-svn: 191262
Specifically, allows the unwinder to handle the case where sc.function
gets resolved with a pc that is one past the address range of the function
(consistent with a tail call). However, there is no matching symbol.
Adds eSymbolContextTailCall to provide callers with control over the scope
of symbol resolution and to allow ResolveSymbolContextForAddress to handle
tail calls since this routine is common to unwind and disassembly.
llvm-svn: 191102
- tests are now anostic to the currently selected thread, as that is a frontend (i.e. driver) decision
- this is in preparation to a fix to POSIXThread::BreakNotify that will be committed shortly
Reviewed by: Matt Kopec
llvm-svn: 191041
Targets and hosts today are little-endian (arm, x86), so this change
should be a no-op as they will not encounter the byte swapping cases.
Byte swapping will happen when cross debugging of big endian-targets
(e.g. MIPS, PPC) on a little-endian host (x86). Register- or word-
sized data copies need to be swapped, but calls to ExtractBytes or
CopyByteOrderedData that would invoke the swapping case are presumably
in error.
llvm-svn: 191005
platforms and called in lldb.cpp while it is built only on some, excluding OSX.
There is no reason to not build it then by default on all platforms.
This fixes build on OSX using llvm configure & make scripts.
Patch (2 of 2) by Adam Strzelecki!
llvm-svn: 190945
We cannot use "GetMaxU64Bitfield" for non-power-of-two sizes, so just use
the same code that handles N > 8 for these.
Review: http://llvm-reviews.chandlerc.com/D1699
llvm-svn: 190873
- 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
- ProcessMonitor::[Do|Serve]Operation no longer depend on file descriptors!
- removed unused member functions CloseFD and EnableIPC
- add semaphores to signal when an Operation is ready to be processed/complete.
This commit fixes a bug that was identified under stress-testing (i.e. build
LLVM while running tests) that led to LLDB becoming unresponsive because the
read/write operations on file descriptors in ProcessMonitor were not checked.
Other test runner improvement/convenience:
- pickup environment variables LLDB_LINUX_LOG and LLDB_LINUX_LOG_OPTIONS to
enable (Linux) logging when running the test suite. Example usage:
$ LLDB_LINUX_LOG="mylog.txt" LLDB_LINUX_LOG_OPTIONS="process thread" python dotest.py
llvm-svn: 190820
for the frame is one past the address range of the calling function.
- Lowers the fix from RegisterContextLLDB for use with disassembly
- Fixes one of three issues in the disassembly test in TestInferiorAssert.py
Also adds documentation that explains the resolution depths and interface.
Note: This change affects the resolution scope for eSymbolContextFunction
without impacting the performance of eSymbolContextSymbol.
Thanks to Matt Kopec for his review.
llvm-svn: 190812
Fixed an issue with the lldb/test/lang/cpp/virtual test case had a virtual class that had a DW_TAG_inheritance child that was virtual and had a DW_AT_data_member_location of:
DW_AT_data_member_location( DW_OP_dup, DW_OP_deref, DW_OP_constu(0x00000018), DW_OP_minus, DW_OP_deref, DW_OP_plus )
We failed to evaluate this and then we were passing the incorrect offset back to clang and clang would crash. The AST external source has a function named LayoutRecordType which allows us to supply the virtual base class offsets, but that really doesn't make sense to do as clang will lay them out correctly. So we must ignore virtual base classes when doing layout.
llvm-svn: 190811
Enrico Granata