- Sep 13, 2010
-
-
Sean Callanan authored
- If you put a semicolon at the end of an expression, this no longer causes the expression parser to error out. This was a two-part fix: first, ClangExpressionDeclMap::Materialize now handles an empty struct (such as when there is no return value); second, ASTResultSynthesizer walks backward from the end of the ASTs until it reaches something that's not a NullStmt. - ClangExpressionVariable now properly byte-swaps when printing itself. - ClangUtilityFunction now cleans up after itself when it's done compiling itself. - Utility functions can now use external functions just like user expressions. - If you end your expression with a statement that does not return a value, the expression now runs correctly anyway. Also, added the beginnings of an Objective-C object validator function, which is neither installed nor used as yet. llvm-svn: 113789
-
Johnny Chen authored
the binaries. If the build* function is passed the compiler argument, for example, 'llvm-gcc', it is passed as a make variable to the make command. Otherwise, we check the LLDB_CC environment variable; if it is defined, it is passed as a make variable to the make command. If neither the compiler keyword argument nor the LLDB_CC environment variable is specified, no CC make variable is passed to the make command. The Makefile gets to define the default CC being used. -------------------------------------------------------------------------------- Example usage follows: o Via the keyword argument: class ArrayTypesTestCase(TestBase): mydir = "array_types" @unittest2.skipUnless(sys.platform.startswith("darwin"), "requires Darwin") def test_with_dsym_and_run_command(self): """Test 'frame variable var_name' on some variables with array types.""" self.buildDsym(compiler='llvm-gcc') self.array_types() ... o Via LLDB_CC environment variable: $ LLDB_CC=llvm-gcc ./dotest.py -v -t array_types ---------------------------------------------------------------------- Collected 4 tests test_with_dsym_and_python_api (TestArrayTypes.ArrayTypesTestCase) Use Python APIs to inspect variables with array types. ... os command: [['/bin/sh', '-c', 'make clean; make MAKE_DSYM=YES CC=llvm-gcc']] output: rm -rf "a.out" "a.out.dSYM" main.o main.d llvm-gcc -arch x86_64 -gdwarf-2 -O0 -arch x86_64 -gdwarf-2 -O0 -c -o main.o main.c llvm-gcc -arch x86_64 -gdwarf-2 -O0 main.o -o "a.out" /usr/bin/dsymutil -o "a.out.dSYM" "a.out" ... llvm-svn: 113781
-
Johnny Chen authored
llvm-svn: 113756
-
Johnny Chen authored
llvm-svn: 113755
-
Johnny Chen authored
llvm-svn: 113753
-
Johnny Chen authored
llvm-svn: 113751
-
Johnny Chen authored
llvm-svn: 113750
-
Johnny Chen authored
llvm-svn: 113748
-
Caroline Tice authored
llvm-svn: 113738
-
Greg Clayton authored
map on macosx. llvm-svn: 113737
-
Greg Clayton authored
frame variables. llvm-svn: 113736
-
Greg Clayton authored
point to. llvm-svn: 113735
-
Greg Clayton authored
llvm-svn: 113734
-
Greg Clayton authored
no elements so that they at least have 1 element. Added the ability to show the declaration location of variables to the "frame variables" with the "--show-declaration" option ("-c" for short). Changed the "frame variables" command over to use the value object code so that we use the same code path as the public API does when accessing and displaying variable values. llvm-svn: 113733
-
Greg Clayton authored
llvm-svn: 113732
-
Greg Clayton authored
static class array. It turns out that gcc 4.2 will emit DWARF that correctly describes the PointType, but it will incorrectly emit debug info for the "g_points" array where the following things are wrong: - the DW_TAG_array_type won't have a subrange info - the DW_TAG_variable for "g_points" won't have a valid byte size, so even though we know the size of PointType, we can't infer the actual size of the array by dividing the size of the variable by the number of elements. We want to make sure clang and llvm-gcc handle this correctly. llvm-svn: 113730
-
Greg Clayton authored
union, or class that contained an enumeration type. When I was creating the clang enumeration decl, I wasn't calling "EnumDecl::setIntegerType (QualType)" which means that if the enum decl was ever asked to figure out it's bit width (getTypeInfo()) it would crash. We didn't run into this with enum types that weren't inside classes because the DWARF already told us how big the type was and when we printed an enum we would never need to calculate the size, we would use the pre-cached byte size we got from the DWARF. When the enum was in a struct/union/class and we tried to layout the struct, the layout code would attempt to get the type info and segfault. llvm-svn: 113729
-
- Sep 12, 2010
-
-
Greg Clayton authored
Fixed an issue where LLDB would fail to set a breakpoint by file and line if the DWARF line table has multiple file entries in the support files for a source file. llvm-svn: 113721
-
Greg Clayton authored
we cached remapping information using the old nlist index to the new symbol index, yet we tried to lookup the symbol stubs that were for symbols that had been remapped by ID instead of using the new symbol index. This is now fixed and the mach-o symbol tables are fixed. Use the delta between two vector entries to determine the stride in case any padding is inserted by compilers for bsearch calls on symbol tables when finding symbols by their original ID. llvm-svn: 113719
-
Caroline Tice authored
llvm-svn: 113715
-
Caroline Tice authored
missing arguments for some of the command options. llvm-svn: 113714
-
Caroline Tice authored
it with llvm::sys::Program::FindProgramByName. llvm-svn: 113709
-
- Sep 11, 2010
-
-
Greg Clayton authored
They will now be represented as: eSymbolTypeFunction: eSymbolTypeCode with IsDebug() == true eSymbolTypeGlobal: eSymbolTypeData with IsDebug() == true and IsExternal() == true eSymbolTypeStatic: eSymbolTypeData with IsDebug() == true and IsExternal() == false This simplifies the logic when dealing with symbols and allows for symbols to be coalesced into a single symbol most of the time. Enabled the minimal symbol table for mach-o again after working out all the kinks. We now get nice concise symbol tables and debugging with DWARF in the .o files with a debug map in the binary works well again. There were issues where the SymbolFileDWARFDebugMap symbol file parser was using symbol IDs and symbol indexes interchangeably. Now that all those issues are resolved debugging is working nicely. llvm-svn: 113678
-
Jason Molenda authored
llvm-svn: 113674
-
Johnny Chen authored
llvm-svn: 113673
-
Johnny Chen authored
to specify a one-liner (either scripting or lldb command) inline. Refactored CommandObjectBreakpointCommandAdd::Execute() a little bit and added some comments. Sn now, we use: breakpoint command add -p 1 -o "conditional_break.stop_if_called_from_a()" to specify a Python one-liner as the callback for breakpoint #1. llvm-svn: 113672
-
Jim Ingham authored
llvm-svn: 113669
-
Jim Ingham authored
llvm-svn: 113661
-
Jim Ingham authored
SBValue to access it. For now this is just the result of ObjC NSPrintForDebugger, but could be extended. Also store the results of the ObjC Object Printer in a Stream, not a ConstString. llvm-svn: 113660
-
Jim Ingham authored
Mainly ExecuteFunction should save & restore the currently selected Thread & Frame. llvm-svn: 113658
-
Jim Ingham authored
When the debugger updates its symbol context, if no thread or frame are selected select the first thread's 0th frame. llvm-svn: 113657
-
Jim Ingham authored
llvm-svn: 113655
-
Greg Clayton authored
Make sure the address passed into SymbolContext::DumpStopContext() is valid before trying to calculate any offsets. llvm-svn: 113645
-
- Sep 10, 2010
-
-
Greg Clayton authored
There was a check to make sure that the frame had a valid function before the expression parser would allow decl lookups which was not needed. After removing this you can evaluate expressions correctly when stopped in a frame that only has a symbol or has no symbol context at all. llvm-svn: 113611
-
Johnny Chen authored
pointed out by Jim Ingham. The convenient one-liner specification should only apply when there is only one breakpoint id being specified for the time being. llvm-svn: 113609
-
Johnny Chen authored
llvm-svn: 113607
-
Greg Clayton authored
up a seciton offset address (SBAddress) within a module that returns a symbol context (SBSymbolContext). Also added a SBSymbolContextList in preparation for adding find/lookup APIs that can return multiple results. Added a lookup example code that shows how to do address lookups. llvm-svn: 113599
-
Johnny Chen authored
llvm-svn: 113598
-
Johnny Chen authored
command for a breakpoint, for example: (lldb) breakpoint command add -p 1 "conditional_break.stop_if_called_from_a()" The ScriptInterpreter interface has an extra method: /// Set a one-liner as the callback for the breakpoint command. virtual void SetBreakpointCommandCallback (CommandInterpreter &interpreter, BreakpointOptions *bp_options, const char *oneliner); to accomplish the above. Also added a test case to demonstrate lldb's use of breakpoint callback command to stop at function c() only when its immediate caller is function a(). The following session shows the user entering the following commands: 1) command source .lldb (set up executable, breakpoint, and breakpoint command) 2) run (the callback mechanism will skip two breakpoints where c()'s immeidate caller is not a()) 3) bt (to see that indeed c()'s immediate caller is a()) 4) c (to continue and finish the program) test/conditional_break $ ../../build/Debug/lldb (lldb) command source .lldb Executing commands in '.lldb'. (lldb) file a.out Current executable set to 'a.out' (x86_64). (lldb) breakpoint set -n c Breakpoint created: 1: name = 'c', locations = 1 (lldb) script import sys, os (lldb) script sys.path.append(os.path.join(os.getcwd(), os.pardir)) (lldb) script import conditional_break (lldb) breakpoint command add -p 1 "conditional_break.stop_if_called_from_a()" (lldb) run run Launching '/Volumes/data/lldb/svn/trunk/test/conditional_break/a.out' (x86_64) (lldb) Checking call frames... Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread: frame #0: a.out`c at main.c:39 frame #1: a.out`b at main.c:34 frame #2: a.out`a at main.c:25 frame #3: a.out`main at main.c:44 frame #4: a.out`start c called from b Continuing... Checking call frames... Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread: frame #0: a.out`c at main.c:39 frame #1: a.out`b at main.c:34 frame #2: a.out`main at main.c:47 frame #3: a.out`start c called from b Continuing... Checking call frames... Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread: frame #0: a.out`c at main.c:39 frame #1: a.out`a at main.c:27 frame #2: a.out`main at main.c:50 frame #3: a.out`start c called from a Stopped at c() with immediate caller as a(). a(1) returns 4 b(2) returns 5 Process 20420 Stopped * thread #1: tid = 0x2e03, 0x0000000100000de8 a.out`c + 7 at main.c:39, stop reason = breakpoint 1.1, queue = com.apple.main-thread 36 37 int c(int val) 38 { 39 -> return val + 3; 40 } 41 42 int main (int argc, char const *argv[]) (lldb) bt bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: 0x0000000100000de8 a.out`c + 7 at main.c:39 frame #1: 0x0000000100000dbc a.out`a + 44 at main.c:27 frame #2: 0x0000000100000e4b a.out`main + 91 at main.c:50 frame #3: 0x0000000100000d88 a.out`start + 52 (lldb) c c Resuming process 20420 Process 20420 Exited a(3) returns 6 (lldb) llvm-svn: 113596
-
Johnny Chen authored
set the debugger_unique_id with the lldb prefix. llvm-svn: 113589
-