Scalar now can make itself signed if needed.

<rdar://problem/13977632>

llvm-svn: 182668

- Fix for attach by name
- Details for register support
- Punted on i386 details as its status has drifted since this page was originally posted
- Multi-threaded target support is soon to be released on Linux
- Partial back-trace is called out since its a high-profile issue

llvm-svn: 182664

which takes a first step towards symbolization of disassembled instructions.

llvm-svn: 182650

Fixed performance issues that arose after changing SBTarget, SBProcess, SBThread and SBFrame over to using a std::shared_ptr to a ExecutionContextRef. The ExecutionContextRef doesn't store a std::weak_ptr to a stack frame because stack frames often get replaced with new version, so it held onto a StackID object that would allow us to ask the thread each time for the frame for the StackID. The linear function was too slow for large recursive stacks. We also fixed an issue where anytime the std::shared_ptr<ExecutionContextRef> in any SBTarget, SBProcess, SBThread objects was turned into an ExecutionContext object, it would try to resolve all items in the ExecutionContext which are shared pointers. Even if the StackID in the ExecutionContextRef was invalid, it was looking through all frames in every thread. This causes a lot of unnecessary frame accesses.

llvm-svn: 182627

llvm-svn: 182619

1. Added new :Lpo command
2. :Lpo and :Lprint can be invoked without parameters. In that case
cursor word will be used
3. Added :LpO command in that case instead of <cword> will be used
stripped <cWORD>. This command is useful for printing objective-c
properties (for ex.: self.tableView). 

Patch by Arthur Evstifeev!!

llvm-svn: 182613

Which means "platform process list" should work and list the architecture.
We are now parsing the elf build-id if it exists, which should allow us to load stripped symbols (looking at that next).

llvm-svn: 182610

settings set use-color [false|true]
settings set prompt "${ansi.bold}${ansi.fg.green}(lldb)${ansi.normal} "
also "--no-use-colors" on the command prompt

llvm-svn: 182609

Make sure to not call "regexec" from <regex.h> with a NULL C string, otherwise we can crash.

llvm-svn: 182607

llvm-svn: 182606

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

llvm-svn: 182540

Patch by Matthew Sorrels

llvm-svn: 182539

llvm-svn: 182538

llvm-svn: 182537

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

Changes after feedback:
Directly use function pointer, just to be safer on 10.8.

llvm-svn: 182529

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

Collect 'anonymous memory' info, if possible

llvm-svn: 182523

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

llvm-svn: 182491

- no longer requires a pane name argument

Patch by Arthur Evstifeev

llvm-svn: 182484

patch by Arthur Evstifeev

llvm-svn: 182483

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

Add test case to make sure we don't regress on fat files full of skinny BSD archives.

llvm-svn: 182440

lldb crashes with universal file containing skinny BSD archives when doing DWARF with .o file debugging.

llvm-svn: 182437

llvm-svn: 182434

llvm-svn: 182429

Added a test case that verifies that LLDB can debug across a process exec'ing itself into a new program. This currently is only enabled for Darwin since we exec from 64 bit to 32 bit and vice versa for 'x86_64' targets.

This can easily be adapted for linux and other platforms, but I didn't want to break any buildbots by assuming it will work.

llvm-svn: 182428

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

LLDB can now debug across calls to exec when the architecture changes from say i386 to x86_64 (on darwin).

llvm-svn: 182345

Thanks to Greg Clayton for catching this

llvm-svn: 182339

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

Correctly handle the case of a ValueObjectVariable backed by a Vector

llvm-svn: 182330

Replacing an assertion with an error - at least we won’t crash

llvm-svn: 182326

llvm-svn: 182325

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

llvm-svn: 182302