(lldb) v
Traceback (most recent call last):
File "./tmp/crystal-debug/etc/lldb/crystal_formatters.py", line 51, in CrystalString_SummaryProvider
byteSize = int(value.child[0].value)
TypeError: int() argument must be a string, a bytes-like object or a number, not 'NoneType'
(Foo *) self = 0x00000001000000a1
(String *) x = 0x0000000400000001
Looking at this more closely, the problem might be related to another problem. Here is my small test program:
class Foo
def foo(x)
puts x
end
end
foo = Foo.new
foo.foo("test")
I’m compiling this ("./crystal-debug/bin/crystal build --debug foo.cr") and running it (“lldb foo”). Then I load the formatters, set a breakpoint at line #3 (the puts), and run. The error occurs when I list the local variables in the frame (“v”).
When I try to deference x directly, I see this:
(lldb) p *x
error: Couldn't apply expression side effects : Couldn't dematerialize a result variable: couldn't read its memory
(Foo *) self = 0x00000001000000a1
(String *) x = 0x0000000400000001
the address is not correct as LLDB is trying to dereference self and then dereference it again. It is double dereferencing issue.
I think I may have some idea why it is happening and probably may solve it. Let me try it and I will let you know if this is successful.
If not, then you will have to use my LLDB patch that I described above but it will take you some time to build patched LLDB
I am trying to find how I can create a pointer to the function argument in llvm.dbg.declare()
By some reason it is not creating extra pointer for function arguments as it does for local variables. Because of that this bug that @tsundsted is described is happening as debugger is trying to dereference the actual value but not the address of that value on the stack.
Ok, I cheated a little. I just dumped .ll code from llvm_ext.o code with full debug information
by llvm-dis llvm_ext.o and I found interesting thing (I was actually thinking to try it as a last resort): clang uses store command to load the arg pointer and only then it calls llvm.dbg.declare on that pointer:
Phi’s can only happen at the very beginning of the blocks. No other instructions can appear between the start of the block and the last phi than other phis.
I see. I may have llvm.dbg.declare at the beginning of block because of some cases if I will keep them in alloca they may dominate some values (2 cases in crweb.cr example, mostly on signal vars as it happens after GEP)
To solve it I had to add it as it allocates on the fly in the current block and not alloca.
I keep only local variables in alloca block.
Will try to figure out if I can declare them before phi not on the top of the blocks.
Just a quick note: I enjoy following this thread even though you might as well be talking about the innards of steam trains.
Please feel free to keep updating with in-progress stuff, maybe I’ll still learn something about steam engines
@mavu Steel trains and steam engines are all history now. We are talking about innards of the rocket engines as we are all rocket scientists here, right?
You probably saw the “Back to the Future” when Doc flew the steel train with the antigrav engine.
This is what we want to achieve here
This is my stigma of being a chatterbox as I love to share gathered information that may be interested to other people.
Ok. I just committed my changes that should work in LLDB and GDB without my patch.
If someone feels adventurous please try it and let me know if it works okay for you. try to use both LLDB and GDB.
Refactoring work is still in progress but it works at least.
Please disregard LLDB bug part as it is not relevant anymore (that was my overlook as LLDB is working just okay, the same way as GDB) so these current changes are making Crystal debug support to work normally with LLDB and GDB without any patching.
Strings will be shown (inside of lldb only for now) if you will load the format helper that I made and it stored in crystal’s source code folder etc/lldb/crystal_formatters.py
It will show strings in CodeLLDB and strings and arrays in raw LLDB command line when you will type v command.
Class variables are not shown yet.
Instance variables are stored in self object but by some reason it is not shown in your example. I will have to figure it out. I will type your example and see what is wrong.
