| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
because EP could be escaped.
|
|
|
|
|
|
Notes:
Merged-By: jemmaissroff
|
|
[ci skip]
|
|
|
|
|
|
It was actually harder to type `cfp + 1`. `cfp 1` also works and is more
useful.
|
|
Somehow my gdb stopped recognizing VM_BLOCK_HANDLER_NONE (macro) today.
Just changing it to a safer code.
|
|
|
|
|
|
|
|
|
|
|
|
This works like:
```
(gdb) cfp
CFP (count=3, addr=0x7ffff73fef50):
$1 = {pc = 0x555556bf7818, sp = 0x7ffff72ff078, iseq = 0x7ffff2603270, self = 140737344619296, ep = 0x7ffff72ff058, block_code = 0x0,
__bp__ = 0x7ffff72ff060, jit_return = 0x555558c2b000}
Stack (size=3):
[0] FIXNUM: 1
[1] T_STRING: "" bytesize:0 (embed) encoding:1 coderange:7bit $2 = (struct RString *) 0x7ffff249ea80
[2] [PROMOTED] T_OBJECT: $3 = {flags = 21474844769, klass = 140737344040416}
$4 = {0x24, 0x24, 0x24}
(gdb) cfp + 1
CFP (count=3, addr=0x7ffff73fef90):
$5 = {pc = 0x5555567a78f8, sp = 0x7ffff72ff040, iseq = 0x7ffff26032d0, self = 140737344619296, ep = 0x7ffff72ff038, block_code = 0x0,
__bp__ = 0x7ffff72ff040, jit_return = 0x555558c2b000}
Stack (size=0):
```
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7632
|
|
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6448
|
|
|
|
For now, the old function still exists as `old_rp`, in order to debug
issues with this command.
Notes:
Merged: https://github.com/ruby/ruby/pull/7531
|
|
Notes:
Merged-By: peterzhu2118 <peter@peterzhu.ca>
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7271
|
|
They are needed very often but it's hard to remember. I thought it'd be
useful to just copy that to /.vscode and edit that.
Usage:
cp -r misc/.vscode .vscode
Don't symlink it because you'd edit it but not want to commit it.
|
|
When we copy instance variables, it is possible for the GC to be kicked
off. The GC looks at the shape to determine what slots to mark inside
the object. If the shape is set too soon, the GC could think that there
are more instance variables on the object than there actually are at
that moment.
|
|
This reverts commit 9a6803c90b817f70389cae10d60b50ad752da48f.
|
|
This reverts commit 68bc9e2e97d12f80df0d113e284864e225f771c2.
|
|
Object Shapes is used for accessing instance variables and representing the
"frozenness" of objects. Object instances have a "shape" and the shape
represents some attributes of the object (currently which instance variables are
set and the "frozenness"). Shapes form a tree data structure, and when a new
instance variable is set on an object, that object "transitions" to a new shape
in the shape tree. Each shape has an ID that is used for caching. The shape
structure is independent of class, so objects of different types can have the
same shape.
For example:
```ruby
class Foo
def initialize
# Starts with shape id 0
@a = 1 # transitions to shape id 1
@b = 1 # transitions to shape id 2
end
end
class Bar
def initialize
# Starts with shape id 0
@a = 1 # transitions to shape id 1
@b = 1 # transitions to shape id 2
end
end
foo = Foo.new # `foo` has shape id 2
bar = Bar.new # `bar` has shape id 2
```
Both `foo` and `bar` instances have the same shape because they both set
instance variables of the same name in the same order.
This technique can help to improve inline cache hits as well as generate more
efficient machine code in JIT compilers.
This commit also adds some methods for debugging shapes on objects. See
`RubyVM::Shape` for more details.
For more context on Object Shapes, see [Feature: #18776]
Co-Authored-By: Aaron Patterson <tenderlove@ruby-lang.org>
Co-Authored-By: Eileen M. Uchitelle <eileencodes@gmail.com>
Co-Authored-By: John Hawthorn <john@hawthorn.email>
|
|
Revert "* expand tabs. [ci skip]"
This reverts commit 830b5b5c351c5c6efa5ad461ae4ec5085e5f0275.
Revert "This commit implements the Object Shapes technique in CRuby."
This reverts commit 9ddfd2ca004d1952be79cf1b84c52c79a55978f4.
|
|
Object Shapes is used for accessing instance variables and representing the
"frozenness" of objects. Object instances have a "shape" and the shape
represents some attributes of the object (currently which instance variables are
set and the "frozenness"). Shapes form a tree data structure, and when a new
instance variable is set on an object, that object "transitions" to a new shape
in the shape tree. Each shape has an ID that is used for caching. The shape
structure is independent of class, so objects of different types can have the
same shape.
For example:
```ruby
class Foo
def initialize
# Starts with shape id 0
@a = 1 # transitions to shape id 1
@b = 1 # transitions to shape id 2
end
end
class Bar
def initialize
# Starts with shape id 0
@a = 1 # transitions to shape id 1
@b = 1 # transitions to shape id 2
end
end
foo = Foo.new # `foo` has shape id 2
bar = Bar.new # `bar` has shape id 2
```
Both `foo` and `bar` instances have the same shape because they both set
instance variables of the same name in the same order.
This technique can help to improve inline cache hits as well as generate more
efficient machine code in JIT compilers.
This commit also adds some methods for debugging shapes on objects. See
`RubyVM::Shape` for more details.
For more context on Object Shapes, see [Feature: #18776]
Co-Authored-By: Aaron Patterson <tenderlove@ruby-lang.org>
Co-Authored-By: Eileen M. Uchitelle <eileencodes@gmail.com>
Co-Authored-By: John Hawthorn <john@hawthorn.email>
Notes:
Merged: https://github.com/ruby/ruby/pull/6386
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6254
|
|
|
|
by moving it fully into RbBaseCommand
Notes:
Merged: https://github.com/ruby/ruby/pull/6129
|
|
Push the newly refactored lldb files into a sub-directory so that we're
not cluttering up the misc directory
Notes:
Merged: https://github.com/ruby/ruby/pull/6129
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6129
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6129
|
|
`lldb_cruby.py` manages lldb custom commands using functions. The file
is a large list of Python functions, and an init handler to map some of
the Python functions into the debugger, to enable execution of custom
logic during a debugging session.
Since LLDB 3.7 (September 2015) there has also been support for using
python classes rather than bare functions, as long as those classes
implement a specific interface.
This PR Introduces some more defined structure to the LLDB helper
functions by switching from the function based implementation to the
class based one, and providing an auto-loading mechanism by which new
functions can be loaded.
The intention behind this change is to make working with the LLDB
helpers easier, by reducing code duplication, providing a consistent
structure and a clearer API for developers.
The current function based approach has some advantages and
disadvantages
Advantages:
- Adding new code is easy.
- All the code is self contained and searchable.
Disadvantages:
- No visible organisation of the file contents. This means
- Hard to tell which functions are utility functions and which are
available to you in a debugging session
- Lots of code duplication within lldb functions
- Large files quickly become intimidating to work with - for example,
`lldb_disasm.py` was implemented as a seperate Python module because
it was easier to start with a clean slate than add significant amounts
of code to `lldb_cruby.py`
This PR attempts, to fix the disadvantages of the current approach and
maintain, or enhance, the benefits. The new structure of a command looks
like this;
```
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
```
If the command fulfils the following criteria it will then be
auto-loaded when an lldb session is started:
- The package file must exist inside the `commands` directory and the
filename must end in `_command.py`
- The package must implement a class whose name ends in `Command`
- The class inherits from `RbBaseCommand` or at minimum a class that
shares the same interface as `RbBaseCommand` (at minimum this means
defining `__init__` and `__call__`, and using `__call__` to call
`call` which is defined in the subclasses).
- The class must have a class variable `package` that is a String. This
is the name of the command you'll call in the `lldb` debugger.
Notes:
Merged: https://github.com/ruby/ruby/pull/6129
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6134
|
|
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6052
|
|
This commit makes `rp` report the correct array length in lldb.
When USING_RVARGC is set we use 7 bits of the flags to store the array
len rather than the usual 2, so they need to be part of the mask when
calculating the length in lldb.
When calculating whether rvargc is enabled I've used the same approach
that's used by `GC.using_rvargc?` which is to detect whether there is
more than one size pool in the current objspace.
Notes:
Merged: https://github.com/ruby/ruby/pull/6033
|
|
rb_backtrace relies on the existend of RUBY_T_MASK. This is set up by
the global loading code in lldb_init()
rb_backtrace does not call lldb_init previously, and therefore would
only work if called after another lldb function that _did_ load the
globals.
Notes:
Merged: https://github.com/ruby/ruby/pull/6026
|
|
Now that classes are using VWA, the RCLASS_PTR uses an offset to get the
rb_classext_t object. Doing this all the time in lldb is boring. So
script lldb to do it for us
Notes:
Merged: https://github.com/ruby/ruby/pull/6024
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6020
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/5957
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/5883
|
