Skip to content
  1. Oct 24, 2012
  2. Oct 23, 2012
  3. Oct 22, 2012
    • Enrico Granata's avatar
      <rdar://problem/12437442> · e3e91517
      Enrico Granata authored
      Given our implementation of ValueObjects we could have a scenario where a ValueObject has a dynamic type of Foo* at one point, and then its dynamic type changes to Bar*
      If Bar* has synthetic children enabled, by the time we figure that out, our public API is already vending SBValues wrapping a DynamicVO, instead of a SyntheticVO and there was
      no trivial way for us to change the SP inside an SBValue on the fly
      This checkin reimplements SBValue in terms of a wrapper, ValueImpl, that allows this substitutions on-the-fly by overriding GetSP() to do The Right Thing (TM)
      As an additional bonus, GetNonSyntheticValue() now works, and we can get rid of the ForceDisableSyntheticChildren idiom in ScriptInterpreterPython
      Lastly, this checkin makes sure the synthetic VOs get the correct m_value and m_data from their parents (prevented summaries from working in some cases)
      
      llvm-svn: 166426
      e3e91517
  4. Oct 18, 2012
    • Greg Clayton's avatar
      <rdar://problem/12462048> · 45392553
      Greg Clayton authored
      LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings:
      
      target.arg0 (string) = 
      
      There is also the program argument that are separate from the first argument that have existed for a while:
      
      target.run-args (arguments) =
      
      When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the:
      - resolved executable path
      - argv0
      - program args
      
      Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision.
      
      llvm-svn: 166137
      45392553
    • Sean Callanan's avatar
      Added support for "bool", "true", and "false" to · aa0f9cbc
      Sean Callanan authored
      the expression parser (also wchar_t) and added a
      test case.
      
      llvm-svn: 166131
      aa0f9cbc
  5. Oct 17, 2012
  6. Oct 16, 2012
  7. Oct 12, 2012
  8. Oct 09, 2012
  9. Oct 06, 2012
  10. Oct 05, 2012
  11. Oct 04, 2012
  12. Sep 26, 2012
  13. Sep 24, 2012
  14. Sep 22, 2012
  15. 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
  16. Sep 20, 2012
  17. Sep 18, 2012
  18. Sep 13, 2012
  19. Sep 12, 2012
  20. Sep 11, 2012
  21. Sep 08, 2012
  22. Sep 04, 2012
    • Enrico Granata's avatar
      <rdar://problem/11485744> Implement important data formatters in C++. Have the... · 3467d80b
      Enrico Granata authored
      <rdar://problem/11485744> Implement important data formatters in C++. Have the Objective-C language runtime plugin expose class descriptors objects akin to the objc_runtime.py Pythonic implementation. Rewrite the data formatters for some core Cocoa classes in C++ instead of Python.
      
      llvm-svn: 163155
      3467d80b
    • Greg Clayton's avatar
      Patch from Filipe Cabecinhas that uses argparse in dotest.py instead of a hand... · 5ec9645f
      Greg Clayton authored
      Patch from Filipe Cabecinhas that uses argparse in dotest.py instead of a hand coded option. I made a few modifications:
      
      Changed the '-A' option to also have a long option of '--arch'. This is now specified multiple times to get multiple architectures.
      
      Old: -A i386^x86_64
      New: -A i386 -A x86_64
           --arch i386 --arch x86_64
           
      Changed the '-C' option to also have a long option of '--compiler'. This is now specified multiple times to get multiple compiler.
      
      Old: -C clang^gcc
      New: -C clang -C gcc
           --compiler clang --compiler gcc
      llvm-svn: 163141
      5ec9645f
  23. 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
  24. Aug 25, 2012
    • Filipe Cabecinhas's avatar
      Added SBDebugger's log callbacks to Python-land · c5041918
      Filipe Cabecinhas authored
      - Tweaked a parameter name in SBDebugger.h so my typemap will catch it;
      - Added a SBDebugger.Create(bool, callback, baton) to the swig interface;
      - Added SBDebugger.SetLoggingCallback to the swig interface;
      - Added a callback utility function for log callbacks;
      - Guard against Py_None on both callback utility functions;
      
      - Added a FIXME to the SBDebugger API test;
      - Added a __del__() stub for SBDebugger.
      
      We need to be able to get both the log callback and baton from an
      SBDebugger if we want to protect against memory leaks (or make the user
      responsible for holding another reference to the callback).
      Additionally, it's impossible to revert from a callback-backed log
      mechanism to a file-backed log mechanism.
      
      llvm-svn: 162633
      c5041918
  25. Aug 24, 2012
Loading