Not yet enabled as the default unwinder but there are no known
backtrace problems with the code at this point.
Added 'log enable lldb unwind' to help diagnose backtrace problems;
this output needs a little refining but it's a good first step.
eh_frame information is currently read unconditionally - the code
is structured to allow this to be delayed until it's actually needed.
There is a performance hit when you have to parse the eh_frame
information for any largeish executable/library so it's necessary
to avoid if possible.
It's confusing having both the UnwindPlan::RegisterLocation struct
and the RegisterConextLLDB::RegisterLocation struct, I need to rename
one of them.
The writing of registers isn't done in the RegisterConextLLDB subclass
yet; neither is the running of complex DWARF expressions from eh_frame
(e.g. used for _sigtramp on Mac OS X).
llvm-svn: 117256
Specifically, we fixed handling of the objc_class
built-in type, which allowed us to pass
named Objective-C objects to functions,
call variable list -t on objects safely, etc.
llvm-svn: 117249
"unsigned short." As discussed in the comments,
this is pending a better solution to the problem
of types not in the debug information but readily
available through headers.
llvm-svn: 117247
method results to int. This will only last until we
get accurate type information for Objective-C methods
or some way of making their types inferred by the
parser.
llvm-svn: 117178
directory used to dump the session info for test failures/errors.
Example:
/Volumes/data/lldb/svn/trunk/test $ ./dotest.py -s jason -v array_types
Session info for test errors or failures will go into directory jason
----------------------------------------------------------------------
Collected 4 tests
test_with_dsym_and_python_api (TestArrayTypes.ArrayTypesTestCase)
Use Python APIs to inspect variables with array types. ... ok
test_with_dsym_and_run_command (TestArrayTypes.ArrayTypesTestCase)
Test 'frame variable var_name' on some variables with array types. ... ok
test_with_dwarf_and_python_api (TestArrayTypes.ArrayTypesTestCase)
Use Python APIs to inspect variables with array types. ... ok
test_with_dwarf_and_run_command (TestArrayTypes.ArrayTypesTestCase)
Test 'frame variable var_name' on some variables with array types. ... FAIL
======================================================================
FAIL: test_with_dwarf_and_run_command (TestArrayTypes.ArrayTypesTestCase)
Test 'frame variable var_name' on some variables with array types.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Volumes/data/lldb/svn/trunk/test/array_types/TestArrayTypes.py", line 27, in test_with_dwarf_and_run_command
self.array_types()
File "/Volumes/data/lldb/svn/trunk/test/array_types/TestArrayTypes.py", line 62, in array_types
'stop reason = breakpoint'])
File "/Volumes/data/lldb/svn/trunk/test/lldbtest.py", line 594, in expect
self.runCmd(str, trace = (True if trace else False), check = not error)
File "/Volumes/data/lldb/svn/trunk/test/lldbtest.py", line 564, in runCmd
msg if msg else CMD_MSG(cmd, True))
AssertionError: False is not True : Command 'thread list' returns successfully
----------------------------------------------------------------------
Ran 4 tests in 3.086s
FAILED (failures=1)
/Volumes/data/lldb/svn/trunk/test $ ls jason
TestArrayTypes.ArrayTypesTestCase.test_with_dwarf_and_run_command.log
/Volumes/data/lldb/svn/trunk/test $ head -10 jason/TestArrayTypes.ArrayTypesTestCase.test_with_dwarf_and_run_command.log
Session info generated @ Thu Oct 21 09:54:15 2010
os command: [['/bin/sh', '-c', 'make clean; make MAKE_DSYM=NO']]
stdout: rm -rf "a.out" "a.out.dSYM" main.o main.d
cc -arch x86_64 -gdwarf-2 -O0 -c -o main.o main.c
cc -arch x86_64 -gdwarf-2 -O0 main.o -o "a.out"
stderr: None
retcode: 0
/Volumes/data/lldb/svn/trunk/test $
llvm-svn: 117028
session information files to. This makes the directory name less intimidating.
Currently, the directory only gets created if there are failures/errors while
running the test suite.
llvm-svn: 116982
So the issue here was that we have lldb_private::FileSpec that by default was
always resolving a path when using the:
FileSpec::FileSpec (const char *path);
and in the:
void FileSpec::SetFile(const char *pathname, bool resolve = true);
This isn't what we want in many many cases. One example is you have "/tmp" on
your file system which is really "/private/tmp". You compile code in that
directory and end up with debug info that mentions "/tmp/file.c". Then you
type:
(lldb) breakpoint set --file file.c --line 5
If your current working directory is "/tmp", then "file.c" would be turned
into "/private/tmp/file.c" which won't match anything in the debug info.
Also, it should have been just a FileSpec with no directory and a filename
of "file.c" which could (and should) potentially match any instances of "file.c"
in the debug info.
So I removed the constructor that just takes a path:
FileSpec::FileSpec (const char *path); // REMOVED
You must now use the other constructor that has a "bool resolve" parameter that you must always supply:
FileSpec::FileSpec (const char *path, bool resolve);
I also removed the default parameter to SetFile():
void FileSpec::SetFile(const char *pathname, bool resolve);
And fixed all of the code to use the right settings.
llvm-svn: 116944
parent call frame information. And comment out the check for stop reason for the
time being. The stop reason disappeared from the "thread backtrace" output for
breakpoint stop with condition.
llvm-svn: 116939
if passed in a NULL new_value and the operation intended is eVarSetOperationAssign.
This fixed a bug where in TestSettings.py:
# Set the run-args and the env-vars.
self.runCmd('settings set target.process.run-args A B C')
self.runCmd('settings set target.process.env-vars ["MY_ENV_VAR"]=YES')
# And add hooks to restore the settings during tearDown().
self.addTearDownHook(
lambda: self.runCmd("settings set -r target.process.run-args"))
self.addTearDownHook(
lambda: self.runCmd("settings set -r target.process.env-vars"))
"settings set -r target.process.env-vars" was not restoring the original env-vars
setting.
llvm-svn: 116895
to be run during tearDown() to effect the restore action instead of executing it inline
during the test method, because the test may already fail and bailout before the inline
restore action.
Fix test_set_output_path() and pass_run_args_and_env_vars() to use this mechanism.
llvm-svn: 116881
optionally specify the tty you want to use if you want to use an existing
terminal window by giving a partial or full path name:
(lldb) process launch --tty=ttys002
This would find the terminal window (or tab on MacOSX) that has ttys002 in its
tty path and use it. If it isn't found, it will use a new terminal window.
llvm-svn: 116878
Johnny Chen