Removed some unused variables, added some consts, changed some casts
to const_cast. I don't think any of these changes are very
controversial.
Differential Revision: http://reviews.llvm.org/D9674
llvm-svn: 237218
For PIE executables the type of the main executable is shared object
so we can't force that the main executable should have the type of
executable.
llvm-svn: 236870
Patch by Jaydeep Patil
Added MIPS32 and MIPS64 core revisions. This would be followed by register context and emulate-instruction for MIPS32.
DYLDRendezvous.cpp:
On Linux link map struct does not contain extra load offset field.
Reviewers: clayborg
Subscribers: bhushan, mohit.bhakkad, sagar, lldb-commits.
Differential Revision: http://reviews.llvm.org/D9190
llvm-svn: 235574
This includes following:
# Add a missing Process argument when calling GetSharedModule in DynamicLoaderDarwinKernel::KextImageInfo::LoadImageUsingMemoryModule
# Fix PlatformDarwinKernel::GetSharedModule prototype
llvm-svn: 233084
Summary:
Saw this while reading some code in DynamicLoader classes. Looks like this has
been a FIXME since 2011 at least.
Test Plan: Run unit tests.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8558
llvm-svn: 232983
Summary:
This has been discovered while experimenting with the gecko linker on android.
In general, assert()'ing on "user input" is a bad idea.
Test Plan: Run unit tests.
Reviewers: clayborg, tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8495
llvm-svn: 232966
* On Android (at least on platfrom-21 x86) the dynamic linker reports the
executable with its full path
* Use the platform path of the executable when storing it into the cache
(used to identify the SO entry for the executable) as this is the path
what will be reported by the dynamic linker. If the platform path isn't
set (local debugging) then it falls back to the normal file path.
Differential revision: http://reviews.llvm.org/D8296
llvm-svn: 232158
kernel debug session, instead of issuing a warning (which on one ever
sees), drop the user-specified kernel binary Module from the target and
try to discover the correct one dynamically.
<rdar://problem/19450329>
llvm-svn: 231885
This continues the effort to reduce header footprint and improve
build speed by removing clang and other unnecessary headers
from Target.h. In one case, some headers were included solely
for the purpose of declaring a nested class in Target, which was
not needed by anybody outside the class. In this case the
definition and implementation of the nested class were isolated
in the .cpp file so the header could be removed.
llvm-svn: 231107
This is part of a larger effort to reduce header file footprints.
Combined, these patches reduce the build time of LLDB locally by
over 30%. However, they touch many files and make many changes,
so will be submitted in small incremental pieces.
Reviewed By: Greg Clayton
Differential Revision: http://reviews.llvm.org/D8022
llvm-svn: 231097
Background: dyld binaries often have extra symbols in their symbol table like "malloc" and "free" for the early bringup of dyld and we often don't want to set breakpoints in dynamic linker binaries. We also don't want to call the "malloc" or "free" function in dyld when a user writes an expression like "(void *)malloc(123)" so we need to avoid doing name lookups in dyld. We mark Modules as being dynamic link editors and this helps do correct lookups for breakpoints by name and function lookups.
<rdar://problem/19716267>
llvm-svn: 228261
Summary:
The Android dynamic linker reports only the basename of each SO entry, so for
the above check to be successful, we need to compare it to the basename of the
main executable.
This also has a nasty side-effect when working with older version of
Android (verified on platform version 16), and debugging PIE
executables: the dynamic linker has a bug and reports the load address
of the main executable (which is a shared object, because PIE) to be 0.
We then try to update the list of loaded sections for all shared
objects, including the main executable, and set the load address to 0,
which breaks everything that relies on resolving addresses in the main
executable (breakpoints, stepping, etc). This commit also fixes that broken
behavior when debugging on older Androids. This bug doesn't happen on newer
Android versions (verified for Android L).
Test Plan: Run test suite on linux.
Reviewers: clayborg, tfiala, richard.mitton
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7188
llvm-svn: 228057
Summary:
This adds preliminary support for PowerPC/PowerPC64, for FreeBSD. There are
some issues still:
* Breakpoints don't work well on powerpc64.
* Shared libraries don't yet get loaded for a 32-bit process on powerpc64 host.
* Backtraces don't work. This is due to PowerPC ABI using a backchain pointer
in memory, instead of a dedicated frame pointer register for the backchain.
* Breakpoints on functions without debug info may not work correctly for 32-bit
powerpc.
Reviewers: emaste, tfiala, jingham, clayborg
Reviewed By: clayborg
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D5988
llvm-svn: 220944
This change adds some logging around dynamic loader handling.
It also fixes an issue where the dynamic loader entry breakpoint can end
up being re-inserted, showing the wrong (i.e. software breakpoint) instruction
at the stop location when a backtrace is displayed at program startup.
I discussed with Jim Ingham a few weeks back. Essentially the
one-hit breakpoints need to make it back to public state handling before
the software breakpoint gets cleared. The flow I was hitting was that
the breakpoint would get set, it would get hit, it would get cleared to
step over, then it would get reapplied, when we never wanted it reapplied.
Stops at the beginning of execution would then show backtraces with
software breakpoint instructions in it, erroneously. This change fixes it.
There might be a more elegant way to do this, or a flow change somewhere else
to avoid, but it does fix an issue I experienced in startup breakpoint handling.
llvm-svn: 219371
that would clear the module list, and then put it back by hand. But we forgot to
also put its sections back in the target SectionList, so we would jettison it as
unloaded when we finished handling the first real load event. Add its sections.
<rdar://problem/18385947>
llvm-svn: 218156
Changes include:
- fix it so you can select the "host" platform using "platform select host"
- change all callbacks that create platforms to returns shared pointers
- fix TestImageListMultiArchitecture.py to restore the "host" platform by running "platform select host"
- Add a new "PlatformSP Platform::Find(const ConstString &name)" method to get a cached platform
- cache platforms that are created and re-use them instead of always creating a new one
llvm-svn: 218145
Covers more of the behavior of rendezvous breakpoint handling and other
dynamic loader aspects, all on the 'enable log lldb dyld' log channel.
llvm-svn: 217283
See the following llvm change for details:
r213743 | tnorthover | 2014-07-23 05:32:47 -0700 (Wed, 23 Jul 2014) | 9 lines
AArch64: remove arm64 triple enumerator.
This change fixes build breaks on Linux and MacOSX lldb.
llvm-svn: 213755
Fixes include:
- Don't say that "<arch>-apple-ios" is compatible with "<arch>-apple-macosx"
- Fixed DynamicLoaderMacOSXDYLD so specify an architecture that was converted solely from a cputype and subtype, just specify the file + UUID.
- Fixed PlatformiOSSimulator::GetSupportedArchitectureAtIndex() so it returns the correct archs
- Fixed SymbolFileDWARFDebugMap to load .o files correctly by just specifying the architecture without the vendor and OS now that "<arch>-apple-ios" is not compatible with "<arch>-apple-macosx" so we can load .o files correctly for DWARF with debug map
- Fixed the coded in TargetList::CreateTarget() so it does the right thing with an underspecified triple where just the arch is specified.
llvm-svn: 212783
This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64.
(More architectures coming soon).
Not every debugserver option is covered yet. Currently
the lldb-gdbserver command line can start unattached,
start attached to a pid (process-name attach not supported yet),
or accept lldb attaching and launching a process or connecting
by process id.
The history of this large change can be found here:
https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64
Until mid/late April, I was not sharing the work and continued
to rebase it off of head (developed via id tfiala@google.com). I switched over to
user todd.fiala@gmail.com in the middle, and once I went to github, I did
merges rather than rebasing so I could share with others.
llvm-svn: 212069
when it is reading the kext table, in case we're reading out of a core file with
corrupt contents in this region.
<rdar://problem/16601915>
llvm-svn: 206233
This is a mechanical change addressing the various sign comparison warnings that
are identified by both clang and gcc. This helps cleanup some of the warning
spew that occurs during builds.
llvm-svn: 205390
These changes were written by Greg Clayton, Jim Ingham, Jason Molenda.
It builds cleanly against TOT llvm with xcodebuild. I updated the
cmake files by visual inspection but did not try a build. I haven't
built these sources on any non-Mac platforms - I don't think this
patch adds any code that requires darwin, but please let me know if
I missed something.
In debugserver, MachProcess.cpp and MachTask.cpp were renamed to
MachProcess.mm and MachTask.mm as they picked up some new Objective-C
code needed to launch processes when running on iOS.
llvm-svn: 205113
This was primarily working around problems where we weren't able
to identify trap handlers for different environments -- but instead,
I'm working to make it easier to specify those trap handler function
names.
llvm-svn: 201366
They were enforcing 16-byte alignment on stack frames for Darwin x86 programs.
But we've found that trap handlers typically don't have the stack pointer
aligned correctly when a trap happens and lldb wasn't backtracing all
the way through. This method is only used as a safety guard to prevent
lldb's unwinder from using a bogus address as a stack frame - we'll still
enforce word-size alignment on stack frames so that should be fine.
Also rolled back akaylor's changes from August 2013 in r188952 which changed
the i386 ABI plugin to relax the CallFrameAddressIsValid offsets for non-Darwin
targets where only 4-byte alignment is enforced. Now Darwin is the same as
those environments.
<rdar://problem/15982682>
llvm-svn: 201292
ObjectFile::SetLoadAddress (Target &target,
lldb::addr_t value,
bool value_is_offset);
Now "value" is a slide if "value_is_offset" is true, and "value" is an image base address otherwise. All previous usage of this API was using slides.
Updated the ObjectFileELF and ObjectFileMachO SetLoadAddress methods to do the right thing.
Also updated the ObjectFileMachO::SetLoadAddress() function to not load __LINKEDIT when it isn't needed and to only load sections that belong to the executable object file.
llvm-svn: 201003
Move some code that was in DynamicLoaderPOSIXDLYD into the
base class DynamicLoader. In the case of UpdateLoadedSections(),
the test to see whether a file is loadable (its address is zero)
is not generally applicable so that test is changed to a more
universally applicable check for the SHF_ALLOC flag on the section.
Also make it explicit that the reading of the module_id in
DynamicLoaderPOSIXDYLD::GetThreadLocalData() is using a hardcoded
size (of module_id) of 4, which might not be appropriate on
big-endian 64-bit systems, leaving a FIXME comment in place.
llvm-svn: 200939
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
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
<rdar://problem/15314403>
This patch adds a new lldb_private::SectionLoadHistory class that tracks what shared libraries were loaded given a process stop ID. This allows us to keep a history of the sections that were loaded for a time T. Many items in history objects will rely upon the process stop ID in the future.
llvm-svn: 196557
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
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
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
On at least FreeBSD and NetBSD there is an extra field in the dyld link
map struct. I've left an assert for other OSes (i.e., Linux/mips) until
it's determined if they do the same.
llvm-svn: 192358
1. existing breakpoints weren't being re-resolved after the sections of a library were loaded (ie. through dlopen).
2. loaded sections weren't being removed after a shared library had been unloaded.
llvm-svn: 190727
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
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
A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error.
This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness.
llvm-svn: 186130
Fixed ProcessMachCore to be able to locate the main executeable in the core file even if it doesn't start at a core file address range boundary. Prior to this we only checked the first bytes of each range in the core file for mach_kernel or dyld. Now we still do this, but if we don't find the mach_kernel or dyld anywhere, we go through all core file ranges and check every 0x1000 to see if we can find dyld or the mach_kernel.
Now that we can properly detect the mach_kernel at any address, we don't need to call "DynamicLoaderDarwinKernel::SearchForDarwinKernel(Process*)" anymore.
llvm-svn: 182513
<rdar://problem/13594769>
Main changes in this patch include:
- cleanup plug-in interface and use ConstStrings for plug-in names
- Modfiied the BSD Archive plug-in to be able to pick out the correct .o file when .a files contain multiple .o files with the same name by using the timestamp
- Modified SymbolFileDWARFDebugMap to properly verify the timestamp on .o files it loads to ensure we don't load updated .o files and cause problems when debugging
The plug-in interface changes:
Modified the lldb_private::PluginInterface class that all plug-ins inherit from:
Changed:
virtual const char * GetPluginName() = 0;
To:
virtual ConstString GetPluginName() = 0;
Removed:
virtual const char * GetShortPluginName() = 0;
- Fixed up all plug-in to adhere to the new interface and to return lldb_private::ConstString values for the plug-in names.
- Fixed all plug-ins to return simple names with no prefixes. Some plug-ins had prefixes and most ones didn't, so now they all don't have prefixed names, just simple names like "linux", "gdb-remote", etc.
llvm-svn: 181631
DynamicLoaderDarwinKernel finds in memory, have DynamicLoaderDarwinKernel
re-set the Target's arch based on the kernel's cpu type / cpu subtype.
llvm-svn: 180962
std::string
Module::GetSpecificationDescription () const;
This returns the module as "/usr/lib/libfoo.dylib" for normal files (calls "std::string FileSpec::GetPath()" on m_file) but it also might include the object name in case the module is for a .o file in a BSD archive ("/usr/lib/libfoo.a(bar.o)"). Cleaned up necessary logging code to use it.
llvm-svn: 180717
- conditionally build mac-specific plugins only on mac (PluginObjectFileMachO, PluginDynamicLoaderDrawinKernel and PluginDynamicLoaderMacOSXDYLD)
- clean up warnings by ignoring deprecated declarations (auto_ptr for example)
llvm-svn: 179694
from the current Target, if there is one, else back off to getting
the currently selected platform from the Debugger (as it ws doing
previously.)
Remove code from DynamicLoaderDarwinKernel that was setting the platform
in both the Target and in the Debugger.
llvm-svn: 178836
plugin will index the kext bundles on the local filesystem when
created. During a kernel debug session, when the DynamicLoader
plugin needs to locate a kext by name like
"com.apple.com.apple.filesystems.autofs", the Platform can quickly
look for a UUID match in those kernel debug kit directories it
previously indexed.
I'm still working on profiling the performance impact of the inital
kext bundle scan; there will likely need to be a switch to enable
or disable this plugin's scan.
This only affects Mac kernel debugging and the code is only built
on Apple systems because of some use of low-level CoreFoundation
to parse plists.
<rdar://problem/13503583>
llvm-svn: 178827
LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.
All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.
llvm-svn: 178191
in a core file if it didn't start at the beginning of a memory segment.
I added more sophisticated kernel location code to DynamicLoaderDarwinKernel
and removed the simple one in ProcessMachCore. Unfortunately the kernel
DynamicLoader doesn't get a chance to search around in memory unless there's
a hint that this might be a kernel debug session. It was easy ot make the
kernel location code static in DynamicLoaderDarwinKernel and call it from
ProcessMachCore on the start of the session, so that's what I did.
<rdar://problem/13326647>
llvm-svn: 176405
binary to lldb already check that the UUID of that binary and the UUID of
the kernel binary in memory match. Warn if they don't.
<rdar://problem/13184784>
llvm-svn: 176160
plugin.dynamic-loader.darwin-kernel.load-kexts setting, don't print
any messages about loading the kexts (which isn't being done) and
don't read the Mach-O headers out of memory (which can be slow and
they're not being used for anything at this point).
llvm-svn: 176064
- generate-vers.pl has to be called by cmake to generate the version number
- parallel builds not yet supported; dependency on clang must be explicitly specified
Tested on Linux.
- Building on Mac will require code-signing logic to be implemented.
- Building on Windows will require OS-detection logic and some selective directory inclusion
Thanks to Carlo Kok (who originally prepared these CMakefiles for Windows) and Ben Langmuir
who ported them to Linux!
llvm-svn: 175795
to search for kexts on the local system -- the ModuleList FindModule()
method is the best first attempt, only call
Symbols::DownloadObjectAndSymbolFile() if that has failed and this
is the kernel binary which really needs to have its symbols located.
<rdar://problem/13241893>
llvm-svn: 175495
find a binary on the debugger-host during a kernel debug session
for a kernel extension (kext). This may prove to be too verbose
in typical usage, particularly if there are many third-party kexts.
We'll try this and see how it works.
<rdar://problem/13080833>
llvm-svn: 175494
a kernel binary - even if we can't find the symbol-rich binary or
dSYM on the debugger-system. Print a warning if the symbol-rich binary
cannot be located. This more closely emulates the gdb behavior when
a kernel debug session failed to locate a kernel binary.
<rdar://problem/13016095>
llvm-svn: 175491
of kernel extensions (kexts) that have been loaded into the kernel.
Now when we hit the "kexts have changed" breakpoint we can avoid
adding kexts multiple times, and can properly detect kext unloads
and remove them from the Target's list of modules.
<rdar://problem/13107639>
<rdar://problem/13191016>
llvm-svn: 175489
lldb was mmap'ing archive files once per .o file it loads, now it correctly shares the archive between modules.
LLDB was also always mapping entire contents of universal mach-o files, now it maps just the slice that is required.
Added a new logging channel for "lldb" called "mmap" to help track future regressions.
Modified the ObjectFile and ObjectContainer plugin interfaces to take a data offset along with the file offset and size so we can implement the correct caching and efficient reading of parts of files without mmap'ing the entire file like we used to.
The current implementation still keeps entire .a files mmaped (once) and entire slices from universal files mmaped to ensure that if a client builds their binaries during a debug session we don't lose our data and get corrupt object file info and debug info.
llvm-svn: 174524
Fix in loading mach files from memory when using DynamicLoaderMacOSXDYLD.
Removed the uuid mismatch warning that could be spit out and any time during debugging and removed the test case that was looking for that. Currently the "add-dsym" or "target symbols add" command will report an error when the UUID's don't match.
Be more careful when checking and resolving section + offset addresses to make sure none of the base addresses are invalid.
llvm-svn: 174222
Enhance lldb so it can search for a kernel in memory when attaching
to a remote system. Remove some of the code that was doing this
from ProcessMachCore and ProcessGDBRemote and put it in
DynamicLoaderDarwinKernel.
I've added a new setting, plugin.dynamic-loader.darwin-kernel.scan-type
which can be set to
none - for environments where reading random memory can cause a
device crash
basic - look at one fixed location in memory for a kernel load address,
plus the contents of that address
fast-scan - the default, tries "basic" and then looks for the kernel's
mach header near the current pc value when lldb connects
exhaustive-scan - on 32-bit targets, step through the entire range where
the kernel can be loaded, looking for the kernel binary
I don't have the setting set up correctly right now, I'm getting back unexpected
values from the Property system, but I'll figure that out tomorrow and fix.
Besides that, all of the different communication methods / types of kernels
appear to be working correctly with these changes.
llvm-svn: 173891
Add the ability to give breakpoints a "kind" string, and have the StopInfoBreakpoint
print that in the brief description if set. Also print the kind - if set - in the breakpoint
listing.
Give kinds to a bunch of the internal breakpoints.
We were deleting the Mac OS X dynamic loader breakpoint as though the id we had stored away was
a breakpoint site ID, but in fact it was a breakpoint id, so we never actually deleted it. Fixed that.
llvm-svn: 173555
Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.
So I defined a new "lldb::offset_t" which should be used for all file offsets.
After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.
Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.
llvm-svn: 173463
- remove unused members
- add NO_PEDANTIC to selected Makefiles
- fix return values (removed NULL as needed)
- disable warning about four-char-constants
- remove unneeded const from operator*() declaration
- add missing lambda function return types
- fix printf() with no format string
- change sizeof to use a type name instead of variable name
- fix Linux ProcessMonitor.cpp to be 32/64 bit friendly
- disable warnings emitted by swig-generated C++ code
Patch by Matt Kopec!
llvm-svn: 169645
- add new header lldb-python.h to be included before other system headers
- short term fix (eventually python dependencies must be cleaned up)
Patch by Matt Kopec!
llvm-svn: 169341
that kexts were newly added.
The Darwin userland dynamic loader provides lldb with a list of
newly-added or newly-removed binaries but in the kernel case we
only know that something has changed. DynamicLoaderDarwinKernel
really needs to maintain its own persistent list of kexts that
it has been notified about (most importantly, it will not detect
kext unlods) but for now we'll at least avoid re-adding an already
present kext.
<rdar://problem/12658487>, <rdar://problem/12658487>
llvm-svn: 169082
This commit does three things:
(a) introduces a new notification model for adding/removing/changing modules to a ModuleList, and applies it to the Target's ModuleList, so that we make sure to always trigger the right set of actions
whenever modules come and go in a target. Certain spots in the code still need to "manually" notify the Target for several reasons, so this is a work in progress
(b) adds a new capability to the Platforms: locating a scripting resources associated to a module. A scripting resource is a Python file that can load commands, formatters, ... and any other action
of interest corresponding to the loading of a module. At the moment, this is only implemented on Mac OS X and only for files inside .dSYM bundles - the next step is going to be letting
the frameworks themselves hold their scripting resources. Implementors of platforms for other systems are free to implement "the right thing" for their own worlds
(c) hooking up items (a) and (b) so that targets auto-load the scripting resources as the corresponding modules get loaded in a target. This has a few caveats at the moment:
- the user needs to manually add the .py file to the dSYM (soon, it will also work in the framework itself)
- if two modules with the same name show up during the lifetime of an LLDB session, the second one won't be able to load its scripting resource, but will otherwise work just fine
llvm-svn: 167569
DynamicLoaderDarwinKernel::OSKextLoadedKextSummary::LoadImageUsingMemoryModule
where it assumed that a kernel had been found in memory, when that may not be
the case when we're attaching to a device early in the boot process.
<rdar://problem/12638140>
llvm-svn: 167564
plugin
dynamic-loader
macosx-kernel
(bool) disable-kext-loading
To settings can be set using:
(lldb) settings set plugin.dynamic-loader.macosx-kernel.disable-kext-loading true
I currently only hooked up the DynamicLoader plug-ins, but the code is very easy to duplicate when and if we need settings for other plug-ins.
llvm-svn: 166294
whether we try to call an external program to load symbols unconditionally,
or if we check the user's preferences before calling it.
ProcessMachCore now sets CanJIT to false - we can't execute code in a core file.
DynamicLoaderDarwinKernel::OSKextLoadedKextSummary::LoadImageUsingMemoryModule changed
to load the kernel from an on-disk file if at all possible.
Don't load the kext binaries out of memory from the remote systems - their linkedit doesn't
seem to be in a good state and we'll error out down in SymbolVendorMacOSX if we try to use
the in-memory images.
Call Symbols::DownloadObjectAndSymbolFile to get the kext/kernel binary -- the external
program may be able to give us a file path on the local filesystem instead of reading
the binary / dSYM over a network drive every time. Fall back to calling
Target::GetSharedModule() like before if DownloadObjectAndSymbolFile fails.
llvm-svn: 165471
if we have a kernel binary, set the target's architecture to match.
Include the target's architecture in the ModuleSpec when we're searching for the
kext binaries on the local system -- otherwise we won't get a specific slice of
a fat file picked out for us and we won't use the returned Module correctly.
Remove the redundant attempt to find a file on the local filesystem from this method.
In ProcessGDBRemote::CheckForKernel(), if we have a kernel binary in memory, mark
the canJIT as false. There is no jitting code in kernel debug sessions.
llvm-svn: 165357
remove the duplicates of this code in ProcessGDBRemote and ProcessKDP.
These two Process plugins will hardcode their DynamicLoader name to be
the DynamicLoaderDarwinKernel so the correct DynamicLoader is picked,
and return the kernel load address as the ImageInfosAddress.
<rdar://problem/12417038>
llvm-svn: 165080
the Symbols::LocateExecutableObjectFile method to locate kexts and
kernels instead of copying them out of the memory of the remote
system. This is the fix for <rdar://problem/12416384>.
Fix a variable shadowing problem in
Symbols::LocateMacOSXFilesUsingDebugSymbols which caused the symbol
rich executable binaries to not be found even if they were listed
in the dSYM Info.plist.
Change Symbols::DownloadObjectAndSymbolFile to ignore dsymForUUID's
negative cache - this is typically being called by the user and we
should try even if there's a incorrect entry in the negative cache.
llvm-svn: 165061
loaded at a random offset).
To get the kernel's UUID and load address I need to send a kdp
packet so I had to implement the kernel relocation (and attempt to
find the kernel if none was provided to lldb already) in ProcessKDP
-- but this code really properly belongs in DynamicLoaderDarwinKernel.
I also had to add an optional Stream to ConnectRemote so
ProcessKDP::DoConnectRemote can print feedback about the remote kernel's
UUID, load address, and notify the user if we auto-loaded the kernel via
the UUID.
<rdar://problem/7714201>
llvm-svn: 164881
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()
Cleaned up header includes a bit as well.
llvm-svn: 162860
setting breakpoints. That's dangerous, since while we are setting a breakpoint,
the target might hit the dyld load notification, and start removing modules from
the list. This change adds a GetMutex accessor to the ModuleList class, and
uses it whenever we are accessing the target's ModuleList (as returned by GetImages().)
<rdar://problem/11552372>
llvm-svn: 157668
Vince Harron