1. 13 Sep, 2017 1 commit
  2. 09 Aug, 2017 1 commit
  3. 11 Jul, 2017 1 commit
  4. 05 Jul, 2017 1 commit
  5. 12 Jun, 2017 1 commit
  6. 07 Jun, 2017 1 commit
  7. 06 Jun, 2017 1 commit
  8. 30 May, 2017 1 commit
  9. 02 May, 2017 1 commit
  10. 26 Apr, 2017 1 commit
    • hjk's avatar
      Debugger: Add a boost::variant dumper · 81d93155
      hjk authored
      This requires making template argument extraction a bit more robust
      
      GCC 5.4.1 created debug info only reports the first argument for
      boost::variant<int, bool>:
      
          #include <boost/variant/variant.hpp
          int main() { boost::variant<int, float> v = 1; return 0; }
      
          py print(gdb.parse_and_eval('v').type)
      
            -> boost::variant<int, float>
      
          py print(gdb.parse_and_eval('v').type.template_argument(0))
      
            -> int
      
          py print(gdb.parse_and_eval('v').type.template_argument(1))
      
             -> Traceback (most recent call last):
                File \"<string>\", line 1, in <module>
                RuntimeError: No argument 1 in template.
                Error while executing Python code.
      
      Change-Id: Iedca8b073078c93449ab61bb2cab05d6cd9803ba
      Reviewed-by: Christian Stenger's avatarChristian Stenger <christian.stenger@qt.io>
      81d93155
  11. 25 Apr, 2017 1 commit
  12. 20 Apr, 2017 1 commit
    • hjk's avatar
      Debugger: Add a workaround for bad gcc debug info generation · 53ff0e1c
      hjk authored
      Gcc does not write out full type names with 'using template ...', see
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80466
      
      This is in most cases harmless for Creator as dumpers are triggered
      independently of template arguments. However, if the dumper takes
      different code path based on the template argument type, as is
      e.g. needed for std::vector<bool>, wrong results are produced,
      as the type cache only used the template base name as type id.
      
      Work around by mangling the id of the un-typedef-ed type into
      the type id of a typedef, which, in case of templates contain
      the full parameter list.
      
      Change-Id: I63c59cccdc186b09ff780e9dfd57b0ad668ae98f
      Reviewed-by: Christian Stenger's avatarChristian Stenger <christian.stenger@qt.io>
      53ff0e1c
  13. 28 Mar, 2017 1 commit
  14. 15 Mar, 2017 2 commits
  15. 14 Mar, 2017 1 commit
  16. 09 Mar, 2017 1 commit
  17. 07 Mar, 2017 1 commit
  18. 01 Mar, 2017 1 commit
  19. 13 Feb, 2017 1 commit
  20. 08 Feb, 2017 1 commit
  21. 19 Dec, 2016 2 commits
  22. 16 Dec, 2016 2 commits
  23. 15 Dec, 2016 1 commit
    • hjk's avatar
      Debugger: Fix Window grabbing on GDB · c2eada27
      hjk authored
      Needs to make namespace detection work without valid frame
      
      Task-number: QTCREATORBUG-17326
      Change-Id: Ia7c7017db4ef384d4f246e11a5601d01f4f366f1
      Reviewed-by: default avatarhjk <hjk@qt.io>
      c2eada27
  24. 02 Dec, 2016 3 commits
  25. 24 Nov, 2016 1 commit
  26. 16 Nov, 2016 1 commit
    • hjk's avatar
      Debugger: Workaround gdb.lookup_symbol ignoring QArrayData::shared_null · b26400e8
      hjk authored
      There have been cases observed where 'p QArrayData::shared_null' finds
      valid symbols that are not found using gdb.lookup_symbols. The cause
      for that is unknown.
      
      Apply an expensive workaround by checking for (the equivalent of)
      a working 'p QArrayData::shared_null' but execute it only when
      a libQt5Core was found. This keeps the overhead for non-Qt setups
      at a bearable (unsuccessful) iteration over known shared object
      names.
      
      Change-Id: Id398673b938d3c3a72c24317abdbefbe793e54df
      Reviewed-by: Christian Stenger's avatarChristian Stenger <christian.stenger@qt.io>
      b26400e8
  27. 14 Nov, 2016 1 commit
  28. 11 Nov, 2016 1 commit
  29. 10 Nov, 2016 4 commits
  30. 04 Nov, 2016 2 commits
  31. 02 Nov, 2016 1 commit