removed the bitfields. This should be conforming
C++11, though, cf. C++03 9.6(3):
"
A bit-field shall have integral or enumeration
type (3.9.1).
"
llvm-svn: 182545
Added logging for the OS plug-in python objects in OperatingSystemPython so we can see the python dictionary returned from the plug-in when logging is enabled.
llvm-svn: 182530
live as long as they needed to. This led to
equality tests involving persistent variables
often failing or succeeding when they had no
business doing so.
To do this, I introduced the ability for a
memory allocation to "leak" - that is, to
persist in the process beyond the lifetime of
the expression. Hand-declared persistent
variables do this now.
<rdar://problem/13956311>
llvm-svn: 182528
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
Lock the lldb_private::Module mutex while tearing down the module to make sure we don't get clients accessing the contents on a module as it is going away.
llvm-svn: 182511
Another fix to make sure that if we aren't able to extract an object file for any reason, we don't crash when trying to parse the debug map info.
llvm-svn: 182441
Yet another implementation of the python in dSYM autoload :)
This time we are going with a ternary setting:
true - load, do not warn
false - do not load, do not warn
warn - do not load, warn (default)
llvm-svn: 182414
A user request such as: memory read -fc -s10 -c1 *charPtrPtr would cause us to crash upon trying to read 1 char of size 10 from memory
This request is now translated into: memory read -fc -s1 -c10 *charPtrPtr (i.e. read 10 chars of size 1 from memory) which is probably also what the user originally wanted
llvm-svn: 182398
There are two settings:
target.load-script-from-symbol-file is a boolean that says load or no load (default: false)
target.warn-on-script-from-symbol-file is also a boolean, it says whether you want to be warned when a script file is not loaded due to security (default: true)
the auto loading on change for target.load-script-from-symbol-file is preserved
llvm-svn: 182336
This changes the setting target.load-script-from-symbol-file to be a ternary enum value:
default (the default value) will NOT load the script files but will issue a warning suggesting workarounds
yes will load the script files
no will not load the script files AND will NOT issue any warning
if you change the setting value from default to yes, that will then cause the script files to be loaded
(the assumption is you didn't know about the setting, got a warning, and quickly want to remedy it)
if you have a settings set command for this in your lldbinit file, be sure to change "true" or "false" into an appropriate "yes" or "no" value
llvm-svn: 182323
Name matching was working inconsistently across many places in LLDB. Anyone doing name lookups where you want to look for all types of names should used "eFunctionNameTypeAuto" as the sole name type mask. This will ensure that we get consistent "lookup function by name" results. We had many function calls using as mask like "eFunctionNameTypeBase | eFunctionNameTypeFull | eFunctionNameTypeMethod | eFunctionNameTypeSelector". This was due to the function lookup by name evolving over time, but as it stands today, use eFunctionNameTypeAuto when you want general name lookups. Either ModuleList::FindFunctions() or Module::FindFunctions() will figure out the right kinds of names to lookup and remove the "eFunctionNameTypeAuto" and replace it with the exact subset of what the name can be.
This checkin also changes eFunctionNameTypeAny over to use eFunctionNameTypeAuto to reflect this.
llvm-svn: 182179
- copy lldb python module into directory specified with CMAKE_INSTALL_PREFIX
- make liblldb.so a symlink (to liblldb.so.X.Y where X.Y is the LLVM version)
llvm-svn: 182157
- Note that this is not correct, as the failure is associated with build options of libc.so, however it's failing on a Debian buildbot that uses gcc 4.6.2 (and the real goal is a complete backtrace even with -fomit-frame-pointer).
- Adds helpers to lldbtest.py to check the expectedCompiler and expectedVersion, with an eventual goal of reducing the number of test decorators.
--- Currently allows a comparison operator and a compiler version to be specified.
--- Can be extended to support ranges of compiler versions.
llvm-svn: 182155
-Remove tracing of fork/vfork until we add support for tracing inferiors' children on Linux.
-Add trace exec option for ptrace so that we don't receive legacy SIGTRAP signals on execve calls.
-Add handling of SIGCHLD sent by kernel (for now, deliver the signal to the inferior).
llvm-svn: 182153
- now, the output binary is called 'lldb-3.4' instead of 'lldb'
- a symlink 'lldb' -> 'lldb-3.4' is also created
- this fixes one of the problems preventing CMake from building Debian packages
llvm-svn: 182148
- On Linux, the partial back-trace after an assert can cause the basic test to fail as discussed on lldb-dev.
- Uses SBFrame to walk up the stack to the assert site and tests expression evaluation of locals, globals and arguments.
Thanks to Daniel for review and testing on OS/X.
llvm-svn: 182115
