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
ObjectFile::CopyData is used to copy a block of target memory to the
caller's buffer (e.g. for "memory read"). This should be a straight
memcpy, and not byte-swapped if the target and host have different
endianness.
Add a new DataExtractor::CopyData() method that performs this straight
copy and use it in ObjectFile::CopyData().
llvm-svn: 192323
Constant ValueObjects should clear their description as well as their summary. Rationale being that both can depend on deeper-than-constified data
so both are subject to changes in "unpredictable" ways
To see this consider repeatedly po'ing a persistent variable of a type whose -description result changes at each invocation
llvm-svn: 192259
Formats (as in "type format") are now included in categories
The only bit missing is caching formats along with synthetic children and summaries, which might be now desirable
llvm-svn: 192217
that all clients use them explicitly. This will hopefully
prevent any future confusion where things get cast to types
we don't expect.
<rdar://problem/15146458>
llvm-svn: 191984
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
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
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
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
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
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
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
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
SVN r189964 provided a sample Python script to inspect unordered(multi){set|map} with synthetic children, contribued by Jared Grubb
This checkin converts that sample script to a C++ provider built into LLDB
A test case is also provided
llvm-svn: 190564
Since I renamed most of the LLVM Mach-O enums in r189314, I had to go fix
LLDB to use the new names. While I was here, I decided that a COFF
plugin really shouldn't be using Mach-O enums.
llvm-svn: 189316
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
This means that "register read stmm0 --format f" actually works now.
This is a little messy but LLDB assumes 'long double' is portable, when it is not.
llvm-svn: 188698
address.
When loading a dSYM, and the file addresses of the dSYM Sections are
different than the executable binary Sections' file addresses, the
debug info won't be remapped to the actual load addresses correctly.
This only happens with binaries on the in-memory shared cache binaries
where their File addresses have been set to their actual load address
(outside an offset value) whereas the original executable and dSYM
have 0-based File addresses.
I think this patch will not be activated for other cases -- this is
the only case we know of where the dSYM and the executable's File
addresses differ -- but if this causes other problems we can restrict
it more carefully.
<rdar://problem/12335086>
llvm-svn: 188532
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
list have a shared pointer back to their DisassemblerLLVMC. This checkin force clears the InstructionList
in all the places we use the DisassemblerSP to stop the leaking for now. I'll go back and fix this
for real when I have time to do so.
<rdar://problem/14581918>
llvm-svn: 187473
Ed Maste