| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 192462
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 192322
|
|
|
|
|
|
|
| |
To support cross-endian and big-endian debugging avoid copying target
memory directly into host variables.
llvm-svn: 191826
|
|
|
|
| |
llvm-svn: 191367
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 189317
|
|
|
|
|
|
| |
Patch from Abid, Hafiz.
llvm-svn: 188776
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
BreakpointLocationList::FindByAddress
Differential Revision: http://llvm-reviews.chandlerc.com/D1145
llvm-svn: 186458
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
TODO: Support for RegisterContext_x86_64::ReadFPR.
Patch by Samuel Jacob!
llvm-svn: 186207
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
number of compiler warnings.
llvm-svn: 184333
|
|
|
|
| |
llvm-svn: 184094
|
|
|
|
|
|
| |
(Used with image list, etc.)
llvm-svn: 184082
|
|
|
|
|
|
| |
AuxVector::DumpToLog
llvm-svn: 184023
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 181711
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
<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
|
|
|
|
| |
llvm-svn: 181374
|
|
|
|
|
|
|
| |
UUID string in; added UUID::GetAsString() which returns the uuid string in
a std::string. Updated callers to use the new method.
llvm-svn: 181078
|
|
|
|
|
|
|
| |
DynamicLoaderDarwinKernel finds in memory, have DynamicLoaderDarwinKernel
re-set the Target's arch based on the kernel's cpu type / cpu subtype.
llvm-svn: 180962
|
|
|
|
|
|
| |
about which kernel binary lldb is referring to.
llvm-svn: 180821
|
|
|
|
|
|
|
|
|
|
|
| |
Also added a similar function for modules:
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
|
|
|
|
|
|
| |
code, thanks to Greg Clayton for finding these.
llvm-svn: 179822
|
|
|
|
|
|
| |
the macros and just use C++11.
llvm-svn: 179805
|
|
|
|
|
|
|
|
| |
C++11 is being used. To do this, we follow what we have done for shared pointers and we define a STD_UNIQUE_PTR macro that can be used and it will "do the right thing". Due to some API differences in std::unique_ptr and due to the fact that we need to be able to compile without C++11, we can't use move semantics so some code needed to change so that it can compile with either C++.
Anyone wanting to use a unique_ptr or auto_ptr should now use the "STD_UNIQUE_PTR(TYPE)" macro.
llvm-svn: 179779
|
|
|
|
|
|
|
| |
- add a workaround header to define uuid_t on platforms that need it
- unbreak remote debugging of mac os x apps
llvm-svn: 179710
|
|
|
|
|
|
| |
- will commit a different workaround momentarily
llvm-svn: 179705
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
| |
DynamicLoaderMacOSXDYLD::ReadAllImageInfosStructure for
version 13 of that structure.
llvm-svn: 179584
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 176879
|
|
|
|
| |
llvm-svn: 176541
|
|
|
|
| |
llvm-svn: 176492
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 176311
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
twice.
llvm-svn: 175496
|
|
|
|
|
|
|
|
|
|
|
| |
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
|