Skip to content
  1. Sep 22, 2012
  2. Sep 21, 2012
    • Enrico Granata's avatar
      Initial commit of a new testsuite feature: test categories. · 165f8af8
      Enrico Granata authored
      This feature allows us to group test cases into logical groups (categories), and to only run a subset of test cases based on these categories.
      
      Each test-case can have a new method getCategories(self): which returns a list of strings that are the categories to which the test case belongs.
      If a test-case does not provide its own categories, we will look for categories in the class that contains the test case.
      If that fails too, the default implementation looks for a .category file, which contains a comma separated list of strings.
      The test suite will recurse look for .categories up until the top level directory (which we guarantee will have an empty .category file).
      
      The driver dotest.py has a new --category <foo> option, which can be repeated, and specifies which categories of tests you want to run.
      (example: ./dotest.py --category objc --category expression)
      
      All tests that do not belong to any specified category will be skipped. Other filtering options still exist and should not interfere with category filtering.
      A few tests have been categorized. Feel free to categorize others, and to suggest new categories that we could want to use.
      
      All categories need to be validly defined in dotest.py, or the test suite will refuse to run when you use them as arguments to --category.
      
      In the end, failures will be reported on a per-category basis, as well as in the usual format.
      
      This is the very first stage of this feature. Feel free to chime in with ideas for improvements!
      
      llvm-svn: 164403
      165f8af8
  3. Sep 18, 2012
  4. Sep 13, 2012
  5. Sep 11, 2012
  6. Sep 08, 2012
  7. Sep 04, 2012
  8. Aug 29, 2012
    • Greg Clayton's avatar
      <rdar://problem/11757916> · 1f746071
      Greg Clayton authored
      Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
      - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". 
      - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
      - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
      - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()
      
      Cleaned up header includes a bit as well.
      
      llvm-svn: 162860
      1f746071
  9. Aug 24, 2012
    • Johnny Chen's avatar
      rdar://problem/11811338 · 6d675243
      Johnny Chen authored
      Add 'attach <pid>|<process-name>' command to lldb, as well as 'detach' which is an alias of 'process detach'.
      Add two completion test cases for "attach" and "detach".
      
      llvm-svn: 162573
      6d675243
    • Johnny Chen's avatar
      Cope with the case where the user-supplied callbacks want the watchpoint itself to be disabled! · 892943f9
      Johnny Chen authored
      Previously we put a WatchpointSentry object within StopInfo.cpp to disable-and-then-enable the watchpoint itself
      while we are performing the actions associated with the triggered watchpoint, which can cause the user-initiated
      watchpoint disabling action to be negated.
      
      Add a test case to verify that a watchpoint can be disabled during the callbacks.
      
      llvm-svn: 162483
      892943f9
  10. Aug 23, 2012
  11. Aug 22, 2012
    • Greg Clayton's avatar
      Reimplemented the code that backed the "settings" in lldb. There were many... · 67cc0636
      Greg Clayton authored
      Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation:
      - no setting auto completion
      - very manual and error prone way of getting/setting variables
      - tons of code duplication
      - useless instance names for processes, threads
      
      Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing".
      
      llvm-svn: 162366
      67cc0636
  12. Aug 16, 2012
    • Johnny Chen's avatar
      rdar://problem/12096295 · eb46f78b
      Johnny Chen authored
      Add an lldb command line option to specify a core file: --core/-c.
      For consistency, change the "target create" command to also use --core.
      
      llvm-svn: 161993
      eb46f78b
  13. Aug 14, 2012
  14. Aug 13, 2012
    • Johnny Chen's avatar
      rdar://problem/12007576 · 209bd65e
      Johnny Chen authored
      Record the snapshot of our watched value when the watchpoint is set or hit.
      And report the old/new values when watchpoint is triggered.  Add some test scenarios.
      
      llvm-svn: 161785
      209bd65e
  15. Aug 11, 2012
  16. Aug 10, 2012
  17. Aug 09, 2012
  18. Aug 08, 2012
  19. Jul 25, 2012
  20. Jul 19, 2012
  21. Jul 13, 2012
  22. Jul 12, 2012
  23. Jun 29, 2012
  24. Jun 20, 2012
  25. Jun 19, 2012
Loading