Re: [lldb-dev] A bit of extra-polish for my lldb plugin

2017-06-01 Thread Nat! via lldb-dev
Pavel, this is pretty much exactly what happens. (Except that there is no frontend. The substitution is done during CodeGen. But that is just a detail) I think a more general solution, that doesn't tie mulle-objc implicitly to the dwarf format would be better in the long term though. Ciao Na

Re: [lldb-dev] A bit of extra-polish for my lldb plugin

2017-06-01 Thread Pavel Labath via lldb-dev
On 31 May 2017 at 19:40, Jim Ingham wrote: > Pavel, can you say more about your idea? > > In both ObjC and C++ methods, you can refer to an ivar either as "this->ivar" > or just "ivar". But the DWARF for C++ doesn't tell lldb that a particular > language supports referring to ivars transparentl

Re: [lldb-dev] A bit of extra-polish for my lldb plugin

2017-05-31 Thread Jim Ingham via lldb-dev
Pavel, can you say more about your idea? In both ObjC and C++ methods, you can refer to an ivar either as "this->ivar" or just "ivar". But the DWARF for C++ doesn't tell lldb that a particular language supports referring to ivars transparently this way. It will say that the "this" parameter

Re: [lldb-dev] A bit of extra-polish for my lldb plugin

2017-05-31 Thread Nat! via lldb-dev
Pavel Labath schrieb: > I think the cleanest solution would be to actually modify the compiler > to emit "correct" dwarf (as in, dwarf representing the code as it > actually looks like to user, and not some internal intermediate > representation). The dwarf expression in DW_AT_location can easily >

Re: [lldb-dev] A bit of extra-polish for my lldb plugin

2017-05-31 Thread Pavel Labath via lldb-dev
I think the cleanest solution would be to actually modify the compiler to emit "correct" dwarf (as in, dwarf representing the code as it actually looks like to user, and not some internal intermediate representation). The dwarf expression in DW_AT_location can easily handle the lookup of some field

Re: [lldb-dev] A bit of extra-polish for my lldb plugin

2017-05-26 Thread Jim Ingham via lldb-dev
Because we try as much as possible to let the compiler figure this sort of thing out for us, we implement the transparent lookups for this & self by compiling our expression in a context that poses as a method of the class whose method we are stopped in. For instance, for ObjC, we construct a c

[lldb-dev] A bit of extra-polish for my lldb plugin

2017-05-26 Thread Nat! via lldb-dev
Let me show you a snippet of a lldb debug session in progress in my ObjC variant: ``` -10,10,v,18.48 Process 45774 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = step in frame #0: 0x00010e2a multiple.debug`+[Foo long:int:char:float:](self=Foo, _cmd=, _param