This project is mirrored from Pull mirroring updated .
  1. 23 Jan, 2022 1 commit
  2. 22 Jan, 2022 1 commit
    • Dave Lee's avatar
      [lldb] Allow aliases to aliases of raw input commands · b9515041
      Dave Lee authored
      Allow users to create aliases for aliases to raw input commands. That probably
      sounds convoluted, so here's an example:
      command alias some-setup env SOMEVAR=SOMEVALUE
      This an alias based on `env`, which itself is an alias for `_regex-env`.
      `_regex-env` is a `command regex` command, which takes raw input.
      The above `some-setup` alias fails with:
      error: Unable to create requested alias.
      This change allows such aliases to be created. lldb already supports aliases to
      aliases for parsed commands.
      Differential Revision:
  3. 18 Oct, 2021 1 commit
  4. 30 Sep, 2021 1 commit
  5. 09 Jul, 2021 1 commit
    • Jonas Devlieghere's avatar
      [lldb] Add the ability to silently import scripted commands · f9517353
      Jonas Devlieghere authored
      Add the ability to silence command script import. The motivation for
      this change is being able to add command script import -s
      lldb.macosx.crashlog to your ~/.lldbinit without it printing the
      following message at the beginning of every debug session.
        "malloc_info", "ptr_refs", "cstr_refs", "find_variable", and
        "objc_refs" commands have been installed, use the "--help" options on
        these commands for detailed help.
      In addition to forwarding the silent option to LoadScriptingModule, this
      also changes ScriptInterpreterPythonImpl::ExecuteOneLineWithReturn and
      ScriptInterpreterPythonImpl::ExecuteMultipleLines to honor the enable IO
      option in ExecuteScriptOptions, which until now was ignored.
      Note that IO is only enabled (or disabled) at the start of a session,
      and for this particular use case, that's done when taking the Python
      lock in LoadScriptingModule, which means that the changes to these two
      functions are not strictly necessary, but (IMO) desirable nonetheless.
      Differential revision:
  6. 17 Jun, 2021 1 commit
  7. 09 Jun, 2021 1 commit
    • Jonas Devlieghere's avatar
      [lldb] Use C++11 default member initializers · 9494c510
      Jonas Devlieghere authored
      This converts a default constructor's member initializers into C++11
      default member initializers. This patch was automatically generated with
      clang-tidy and the modernize-use-default-member-init check.
      $ -header-filter='lldb' -checks='-*,modernize-use-default-member-init' -fix
      This is a mass-refactoring patch and this commit will be added to
      Differential revision:
  8. 08 Feb, 2021 1 commit
  9. 23 Dec, 2020 1 commit
  10. 17 Dec, 2020 1 commit
    • Pavel Labath's avatar
      Revert "[lldb] Make CommandInterpreter's execution context the same as debugger's one." · 122a4ebd
      Pavel Labath authored
      This reverts commit a01b26fb, because it
      breaks the "finish" command in some way -- the command does not
      terminate after it steps out, but continues running the target. The
      exact blast radius is not clear, but it at least affects the usage of
      the "finish" command in The error is *not*
      gui-related, as the same issue can be reproduced by running the same
      steps outside of the gui.
      There is some kind of a race going on, as the test fails only 20% of the
      time on the buildbot.
  11. 12 Dec, 2020 1 commit
    • Tatyana Krasnukha's avatar
      [lldb] Make CommandInterpreter's execution context the same as debugger's one. · a01b26fb
      Tatyana Krasnukha authored
      Currently, the interpreter's context is not updated until a command is executed.
      This has resulted in the behavior of SB-interface functions and some commands
      depends on previous user actions. The interpreter's context can stay uninitialized,
      point to a currently selected target, or point to one of previously selected targets.
      This patch removes any usages of CommandInterpreter::UpdateExecutionContext.
      CommandInterpreter::HandleCommand* functions still may override context temporarily,
      but now they always restore it before exiting. CommandInterpreter saves overriden
      contexts to the stack, that makes nesting commands possible.
      Added test reproduces one of the issues. Without this fix, the last assertion fails
      because interpreter's execution context is empty until running "target list", so,
      the value of the global property was updated instead of process's local instance.
      Differential Revision:
  12. 27 Oct, 2020 1 commit
  13. 02 Sep, 2020 1 commit
    • Jonas Devlieghere's avatar
      [lldb] Move ScriptCommand and RegexCommand under Commands (NFC) · 9390b346
      Jonas Devlieghere authored
      Move the CommandObjectScript and CommandObjectRegexCommand under
      Commands where all the other CommandObject implementations live.
      Although neither implementations currently use the TableGen-generated, this move would have been necessary anyway if they
      were to in the future.
  14. 11 Aug, 2020 1 commit
  15. 27 Jul, 2020 1 commit
  16. 23 Jul, 2020 1 commit
  17. 16 Jun, 2020 1 commit
  18. 04 Jun, 2020 2 commits
  19. 26 Mar, 2020 1 commit
  20. 28 Jan, 2020 1 commit
    • Benjamin Kramer's avatar
      Make llvm::StringRef to std::string conversions explicit. · adcd0268
      Benjamin Kramer authored
      This is how it should've been and brings it more in line with
      std::string_view. There should be no functional change here.
      This is mostly mechanical from a custom clang-tidy check, with a lot of
      manual fixups. It uncovers a lot of minor inefficiencies.
      This doesn't actually modify StringRef yet, I'll do that in a follow-up.
  21. 24 Jan, 2020 1 commit
    • Raphael Isemann's avatar
      [lldb][NFC] Fix all formatting errors in .cpp file headers · 80814287
      Raphael Isemann authored
      A *.cpp file header in LLDB (and in LLDB) should like this:
      //===-- TestUtilities.cpp -------------------------------------------------===//
      However in LLDB most of our source files have arbitrary changes to this format and
      these changes are spreading through LLDB as folks usually just use the existing
      source files as templates for their new files (most notably the unnecessary
      editor language indicator `-*- C++ -*-` is spreading and in every review
      someone is pointing out that this is wrong, resulting in people pointing out that this
      is done in the same way in other files).
      This patch removes most of these inconsistencies including the editor language indicators,
      all the different missing/additional '-' characters, files that center the file name, missing
      trailing `===//` (mostly caused by clang-format breaking the line).
      Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
      Reviewed By: JDevlieghere
      Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
      Tags: #lldb
      Differential Revision:
  22. 15 Jan, 2020 2 commits
  23. 23 Dec, 2019 2 commits
  24. 16 Dec, 2019 1 commit
  25. 30 Oct, 2019 1 commit
  26. 27 Sep, 2019 1 commit
    • Lawrence D'Anna's avatar
      remove File::SetStream(), make new files instead. · 7ca15ba7
      Lawrence D'Anna authored
      This patch removes File::SetStream() and File::SetDescriptor(),
      and replaces most direct uses of File with pointers to File.
      Instead of calling SetStream() on a file, we make a new file and
      replace it.
      My ultimate goal here is to introduce a new API class SBFile, which
      has full support for python io.IOStream file objects.   These can
      redirect read() and write() to python code, so lldb::Files will
      need a way to dispatch those methods.   Additionally it will need some
      form of sharing and assigning files, as a SBFile will be passed in and
      assigned to the main IO streams of the debugger.
      In my prototype patch queue, I make File itself copyable and add a
      secondary class FileOps to manage the sharing and dispatch.  In that
      case SBFile was a unique_ptr<File>.
      However in review, Pavel Labath suggested that it be shared_ptr instead.
      In order for SBFile to use shared_ptr<File>, everything else should
      as well.
      If this patch is accepted, I will make SBFile use a shared_ptr
      I will remove FileOps from future patches and use subclasses of File
      Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath
      Reviewed By: labath
      Subscribers: lldb-commits
      Tags: #lldb
      Differential Revision:
      llvm-svn: 373090
  27. 13 Sep, 2019 1 commit
    • Raphael Isemann's avatar
      [lldb][NFC] Remove ArgEntry::ref member · 0d9a201e
      Raphael Isemann authored
      The StringRef should always be identical to the C string, so we
      might as well just create the StringRef from the C-string. This
      might be slightly slower until we implement the storage of ArgEntry
      with a string instead of a std::unique_ptr<char[]>. Until then we
      have to do the additional strlen on the C string to construct the
      llvm-svn: 371842
  28. 03 Sep, 2019 1 commit
  29. 22 Aug, 2019 2 commits
    • Raphael Isemann's avatar
      [lldb][NFC] Remove dead code that is supposed to handle invalid command options · 36162014
      Raphael Isemann authored
      We currently have a bunch of code that is supposed to handle invalid command options, but
      all this code is unreachable because invalid options are already handled in `Options::Parse`.
      The only way we can reach this code is when we declare but then not implement an option
      (which will be made impossible with D65386, which is also when we can completely remove
      the `default` cases).
      This patch replaces all this code with `llvm_unreachable` to make clear this is dead code
      that can't be reached.
      Reviewers: JDevlieghere
      Reviewed By: JDevlieghere
      Subscribers: lldb-commits
      Tags: #lldb
      Differential Revision:
      llvm-svn: 369625
    • Raphael Isemann's avatar
      [lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and... · ae34ed2c
      Raphael Isemann authored
      [lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values
      We still have some leftovers of the old completion API in the internals of
      LLDB that haven't been replaced by the new CompletionRequest. These leftovers
      * The return values (int/size_t) in all completion functions.
      * Our result array that starts indexing at 1.
      * `WordComplete` mode.
      I didn't replace them back then because it's tricky to figure out what exactly they
      are used for and the completion code is relatively untested. I finally got around
      to writing more tests for the API and understanding the semantics, so I think it's
      a good time to get rid of them.
      A few words why those things should be removed/replaced:
      * The return values are really cryptic, partly redundant and rarely documented.
        They are also completely ignored by Xcode, so whatever information they contain will end up
        breaking Xcode's completion mechanism. They are also partly impossible to even implement
        as we assign negative values special meaning and our completion API sometimes returns size_t.
        Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
        in some untested code path to expand the history repeat character to the full command, but
        I haven't figured out why that doesn't work at the moment.
        Completion functions return -1 to 'insert the completion character', but that isn't implemented
        (even though we seem to activate this feature in LLDB sometimes).
        All positive values have to match the number of results. This is obviously just redundant information
        as the user can just look at the result list to get that information (which is what Xcode does).
      * The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
        reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
        that we calculate this to make the life of the API caller easier, but obviously forcing people to have
        1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
        0-based like Xcode has to do).
      * The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
        idea is that we let the top-level API know that we just provided a full completion. Interestingly we
        `WordComplete` is just a single bool that somehow represents all N completions. And we always
        provide full completions in LLDB, so in theory it should always be true.
        The only use it currently serves is providing redundant information about whether we have a single
        definitive completion or not (which we already know from the number of results we get).
      This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
      It also removes all return values from all internal completion functions. The only non-redundant information
      they contain is about rewriting the current line (which is broken), so that functionality was moved
      to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
      to do the same.
      For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
      prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
      didn't even implement them in the Editline handler (e.g. -1).
      I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
      but I would prefer doing this in follow-up NFC commits
      Reviewers: JDevlieghere
      Reviewed By: JDevlieghere
      Subscribers: arphaman, abidh, lldb-commits
      Tags: #lldb
      Differential Revision:
      llvm-svn: 369624
  30. 16 Aug, 2019 1 commit
  31. 14 Aug, 2019 1 commit
  32. 07 Aug, 2019 1 commit
  33. 02 Aug, 2019 1 commit
  34. 28 Jul, 2019 1 commit
    • Raphael Isemann's avatar
      [lldb] Also include the array definition in · bd68a052
      Raphael Isemann authored
      Right now our only generates the initializer for the options list but
      not the array declaration boilerplate around it. As the array definition is identical for all arrays,
      we might as well also let the generate it alongside the initializers.
      This patch will also allow us to generate additional declarations related to that option list in
      the future (e.g. a enum class representing the specific options which would make our
      handling code less prone).
      This patch also fixes a few option tables that didn't follow our naming style.
      Reviewers: JDevlieghere
      Reviewed By: JDevlieghere
      Subscribers: abidh, lldb-commits
      Tags: #lldb
      Differential Revision:
      llvm-svn: 367186
  35. 18 Jul, 2019 1 commit
  36. 08 May, 2019 1 commit
    • Jonas Devlieghere's avatar
      Propagate command interpreter errors from lldlbinit · c0b48ab6
      Jonas Devlieghere authored
      This patch ensures that we propagate errors coming from the lldbinit
      file trough the command/script interpreter. Before, if you did something
      like command script import, and the python file
      contained a syntax error, lldb wouldn't tell you about it. This changes
      with the current patch: errors are now propagated by default.
      PS: Jim authored this change and I added testing.
      Differential revision:
      llvm-svn: 360216