https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112022-07-23T02:08:29ZRuby Issue Tracking SystemRuby master - Feature #18910: Improve maintainability of LLDB helpershttps://bugs.ruby-lang.org/issues/18910?journal_id=984422022-07-23T02:08:29Zianks (Ian Ker-Seymer)
<ul></ul><p>On a related note, I’ve often found myself wanting access to these helpers when developing native extensions. I’ve copy-pasta’d them in the past, but I wonder if Ruby could support including them for debug builds?</p> Ruby master - Feature #18910: Improve maintainability of LLDB helpershttps://bugs.ruby-lang.org/issues/18910?journal_id=985012022-07-28T13:03:34Zeightbitraptor (Matthew Valentine-House)matt@eightbitraptor.com
<ul></ul><p>ianks (Ian Ker-Seymer) wrote in <a href="#note-1">#note-1</a>:</p>
<blockquote>
<p>On a related note, I’ve often found myself wanting access to these helpers when developing native extensions. I’ve copy-pasta’d them in the past, but I wonder if Ruby could support including them for debug builds?</p>
</blockquote>
<p>One thing that I'd like to do in a future PR is experiment with having these LLDB helpers inside a gem. Despite the slightly odd experience of having a Ruby gem that contained only Python code, we'd get a couple of benefits. 1) We'd be able to tie the helpers to a specific version of Ruby - they're very closely coupled to Ruby internals, and can be brittle when implementation details in the VM change. and 2) It would then be more easily usable for folks writing native extensions. What do you think?</p> Ruby master - Feature #18910: Improve maintainability of LLDB helpershttps://bugs.ruby-lang.org/issues/18910?journal_id=985662022-08-02T17:48:02Zianks (Ian Ker-Seymer)
<ul></ul><p>eightbitraptor (Matthew Valentine-House) wrote in <a href="#note-2">#note-2</a>:</p>
<blockquote>
<p>ianks (Ian Ker-Seymer) wrote in <a href="#note-1">#note-1</a>:</p>
<blockquote>
<p>On a related note, I’ve often found myself wanting access to these helpers when developing native extensions. I’ve copy-pasta’d them in the past, but I wonder if Ruby could support including them for debug builds?</p>
</blockquote>
<p>One thing that I'd like to do in a future PR is experiment with having these LLDB helpers inside a gem. Despite the slightly odd experience of having a Ruby gem that contained only Python code, we'd get a couple of benefits. 1) We'd be able to tie the helpers to a specific version of Ruby - they're very closely coupled to Ruby internals, and can be brittle when implementation details in the VM change. and 2) It would then be more easily usable for folks writing native extensions. What do you think?</p>
</blockquote>
<p>👍🏻</p> Ruby master - Feature #18910: Improve maintainability of LLDB helpershttps://bugs.ruby-lang.org/issues/18910?journal_id=987242022-08-18T17:25:59Zeightbitraptor (Matthew Valentine-House)matt@eightbitraptor.com
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li></ul><p>Applied in changeset <a class="changeset" title="[ci-skip][Feature #18910][lldb] Provide class framework for lldb commands `lldb_cruby.py` manage..." href="https://bugs.ruby-lang.org/projects/ruby-master/repository/git/revisions/f1ccfa0c2c200c9443fbfc3f1ac3acbdd3e35559">git|f1ccfa0c2c200c9443fbfc3f1ac3acbdd3e35559</a>.</p>
<hr>
<p>[ci-skip][Feature <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Improve maintainability of LLDB helpers (Closed)" href="https://bugs.ruby-lang.org/issues/18910">#18910</a>][lldb] Provide class framework for lldb commands</p>
<p><code>lldb_cruby.py</code> manages lldb custom commands using functions. The file<br>
is a large list of Python functions, and an init handler to map some of<br>
the Python functions into the debugger, to enable execution of custom<br>
logic during a debugging session.</p>
<p>Since LLDB 3.7 (September 2015) there has also been support for using<br>
python classes rather than bare functions, as long as those classes<br>
implement a specific interface.</p>
<p>This PR Introduces some more defined structure to the LLDB helper<br>
functions by switching from the function based implementation to the<br>
class based one, and providing an auto-loading mechanism by which new<br>
functions can be loaded.</p>
<p>The intention behind this change is to make working with the LLDB<br>
helpers easier, by reducing code duplication, providing a consistent<br>
structure and a clearer API for developers.</p>
<p>The current function based approach has some advantages and<br>
disadvantages</p>
<p>Advantages:</p>
<ul>
<li>Adding new code is easy.</li>
<li>All the code is self contained and searchable.</li>
</ul>
<p>Disadvantages:</p>
<ul>
<li>No visible organisation of the file contents. This means
<ul>
<li>Hard to tell which functions are utility functions and which are<br>
available to you in a debugging session</li>
<li>Lots of code duplication within lldb functions</li>
</ul>
</li>
<li>Large files quickly become intimidating to work with - for example,<br>
<code>lldb_disasm.py</code> was implemented as a seperate Python module because<br>
it was easier to start with a clean slate than add significant amounts<br>
of code to <code>lldb_cruby.py</code>
</li>
</ul>
<p>This PR attempts, to fix the disadvantages of the current approach and<br>
maintain, or enhance, the benefits. The new structure of a command looks<br>
like this;</p>
<pre><code>class TestCommand(RbBaseCommand):
# program is the keyword the user will type in lldb to execute this command
program = "test"
# help_string will be displayed in lldb when the user uses the help functions
help_string = "This is a test command to show how to implement lldb commands"
# call is where our command logic will be implemented
def call(self, debugger, command, exe_ctx, result):
pass
</code></pre>
<p>If the command fulfils the following criteria it will then be<br>
auto-loaded when an lldb session is started:</p>
<ul>
<li>The package file must exist inside the <code>commands</code> directory and the<br>
filename must end in <code>_command.py</code>
</li>
<li>The package must implement a class whose name ends in <code>Command</code>
</li>
<li>The class inherits from <code>RbBaseCommand</code> or at minimum a class that<br>
shares the same interface as <code>RbBaseCommand</code> (at minimum this means<br>
defining <code>__init__</code> and <code>__call__</code>, and using <code>__call__</code> to call<br>
<code>call</code> which is defined in the subclasses).</li>
<li>The class must have a class variable <code>package</code> that is a String. This<br>
is the name of the command you'll call in the <code>lldb</code> debugger.</li>
</ul>