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

[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
Nat!
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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 transparently this way.  It will say 
> that the "this" parameter is artificial, and that it is the "object pointer". 
>  But it doesn't so far as I can tell record the fact that elements of that 
> parameter can be transparently accessed.
>
> I think it would be confusing for the debug information to record the 
> transparently accessed ivars as pseudo-locals, the duplication would confuse 
> folks, and that isn't how they are understood by the person writing the code. 
>  It might be good to propose a "DW_AT_transparent" attribute, and mark the 
> ivars or maybe the parameter that way.  I guessing that wasn't done because 
> it was assumed that the debugger would know this sort of rule from the 
> language in question.
>
> As I understand it, problem here is that Nat's runtime has extra rules for 
> transparent access that lldb doesn't know about.
>

I understood the problem differently, although I can't really say
whether it was correct or not. My impression was that the members of
the "_param" struct were **parameters** to the method, which have
become (due to some source code transformations, or ABI
considerations) members of a single struct parameter. So a programmer
would write (i'm not going to try to write this in objc)

int foo(int x, int y) { return x+y; }

and the some frontend would transform this into:

struct foo_params {int x,y;};
int foo(foo_params *_param) { return _param->x + _param->y; }

before passing it into the real compiler.

If this is the case then I think it makes sense to have the dwarf
describe the original source code, and not the intermediate form.
However, if it's something else, then that's likely not a good idea,
and I should probably shut up, as I obviously don't know enough about
objc to be of help here.

cheers,
pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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 is artificial, and that it is the "object pointer".  But 
it doesn't so far as I can tell record the fact that elements of that parameter 
can be transparently accessed.

I think it would be confusing for the debug information to record the 
transparently accessed ivars as pseudo-locals, the duplication would confuse 
folks, and that isn't how they are understood by the person writing the code.  
It might be good to propose a "DW_AT_transparent" attribute, and mark the ivars 
or maybe the parameter that way.  I guessing that wasn't done because it was 
assumed that the debugger would know this sort of rule from the language in 
question.

As I understand it, problem here is that Nat's runtime has extra rules for 
transparent access that lldb doesn't know about.

Jim


> On May 31, 2017, at 3:20 AM, Pavel Labath  wrote:
> 
> 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 in a struct. Of course, this is
> assuming you are actually able to modify the compiler.
> 
> (disclaimer: I know next to nothing, when it comes to objc)
> 
> On 26 May 2017 at 23:25, Jim Ingham via lldb-dev
>  wrote:
>> 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 
>> category on the class, and put the expression text in a method in that 
>> category, and then compile all that and call the method.
>> 
>> That's done in ExpressionSourceCode::GetText.
>> 
>> The one hitch to this is that this works because the compiler that is linked 
>> into lldb knows about the ObjC model we are emulating.  An unmodified clang 
>> won't do transparent lookup into some random argument that happens to be 
>> called _param.  So you would have to build lldb with a version of clang that 
>> understands your lookup rules for this to work.
>> 
>> If that's not possible then you can try to do this by monkeying with the 
>> lookup rules implemented by lldb's ClangASTSource to return "_param.a" when 
>> it is just looking up "a".  That's how we inject variables and types that 
>> are present in the local context into the expression as it is getting 
>> parsed.  But at that point you are getting your hands into some fairly deep 
>> magic, and clang's Aslan is not as forgiving as Narnia's...
>> 
>> Jim
>> 
>> 
>>> On May 26, 2017, at 2:27 PM, Nat! via lldb-dev  
>>> wrote:
>>> 
>>> 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=0x7fff5fbff948) at multiple.m:15
>>>  12   char:(char) c
>>>  13  float:(float) d
>>>  14  {
>>>  15 printf( "%ld,%d,%c,%.2f\n", a, b, c, d);
>>> -> 16 }
>>>  17
>>>  18  @end
>>> (lldb) p *_param
>>> (p.long:int:char:float:) $2 = (a = -10, b = 10, c = 'v', d =
>>> 18.475)
>>> ```
>>> 
>>> You can see that the parameter values `a,b,c,d` are actually fields of
>>> a struct parameter `_param`. `_param` uniformly appears as the third
>>> parameter after `self` and `_cmd`. `p _param->a` works of course, but it
>>> would be nice to be able to say 'p a', since in the source code one sees
>>> only `a`. `_param` is more or less an implementation detail.
>>> 
>>> A clue how to achieve this, would be very much appreciated.
>>> 
>>> Ciao
>>>  Nat!
>>> 
>>> 
>>> [*] except, if it's a picture of thousand words :)
>>> 
>>> https://www.mulle-kybernetik.com/weblog/2015/mulle_objc_meta_call_convention.html
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> 
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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
> handle the lookup of some field in a struct. Of course, this is
> assuming you are actually able to modify the compiler.
> 
> (disclaimer: I know next to nothing, when it comes to objc)
> 

That would probably be ideal. I have to see if I can do this. But my
metaABI is somewhat "hacked" into clang. So I am not saying it wouldn't
work, but I suspect it won't, as I am relying on existing clang code.

Ciao
   Nat!

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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 in a struct. Of course, this is
assuming you are actually able to modify the compiler.

(disclaimer: I know next to nothing, when it comes to objc)

On 26 May 2017 at 23:25, Jim Ingham via lldb-dev
 wrote:
> 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 
> category on the class, and put the expression text in a method in that 
> category, and then compile all that and call the method.
>
> That's done in ExpressionSourceCode::GetText.
>
> The one hitch to this is that this works because the compiler that is linked 
> into lldb knows about the ObjC model we are emulating.  An unmodified clang 
> won't do transparent lookup into some random argument that happens to be 
> called _param.  So you would have to build lldb with a version of clang that 
> understands your lookup rules for this to work.
>
> If that's not possible then you can try to do this by monkeying with the 
> lookup rules implemented by lldb's ClangASTSource to return "_param.a" when 
> it is just looking up "a".  That's how we inject variables and types that are 
> present in the local context into the expression as it is getting parsed.  
> But at that point you are getting your hands into some fairly deep magic, and 
> clang's Aslan is not as forgiving as Narnia's...
>
> Jim
>
>
>> On May 26, 2017, at 2:27 PM, Nat! via lldb-dev  
>> wrote:
>>
>> 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=0x7fff5fbff948) at multiple.m:15
>>   12   char:(char) c
>>   13  float:(float) d
>>   14  {
>>   15 printf( "%ld,%d,%c,%.2f\n", a, b, c, d);
>> -> 16 }
>>   17
>>   18  @end
>> (lldb) p *_param
>> (p.long:int:char:float:) $2 = (a = -10, b = 10, c = 'v', d =
>> 18.475)
>> ```
>>
>> You can see that the parameter values `a,b,c,d` are actually fields of
>> a struct parameter `_param`. `_param` uniformly appears as the third
>> parameter after `self` and `_cmd`. `p _param->a` works of course, but it
>> would be nice to be able to say 'p a', since in the source code one sees
>> only `a`. `_param` is more or less an implementation detail.
>>
>> A clue how to achieve this, would be very much appreciated.
>>
>> Ciao
>>   Nat!
>>
>>
>> [*] except, if it's a picture of thousand words :)
>>
>> https://www.mulle-kybernetik.com/weblog/2015/mulle_objc_meta_call_convention.html
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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 category on 
the class, and put the expression text in a method in that category, and then 
compile all that and call the method.

That's done in ExpressionSourceCode::GetText.

The one hitch to this is that this works because the compiler that is linked 
into lldb knows about the ObjC model we are emulating.  An unmodified clang 
won't do transparent lookup into some random argument that happens to be called 
_param.  So you would have to build lldb with a version of clang that 
understands your lookup rules for this to work.

If that's not possible then you can try to do this by monkeying with the lookup 
rules implemented by lldb's ClangASTSource to return "_param.a" when it is just 
looking up "a".  That's how we inject variables and types that are present in 
the local context into the expression as it is getting parsed.  But at that 
point you are getting your hands into some fairly deep magic, and clang's Aslan 
is not as forgiving as Narnia's...

Jim


> On May 26, 2017, at 2:27 PM, Nat! via lldb-dev  
> wrote:
> 
> 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=0x7fff5fbff948) at multiple.m:15
>   12   char:(char) c
>   13  float:(float) d
>   14  {
>   15 printf( "%ld,%d,%c,%.2f\n", a, b, c, d);
> -> 16 }
>   17  
>   18  @end
> (lldb) p *_param
> (p.long:int:char:float:) $2 = (a = -10, b = 10, c = 'v', d =
> 18.475)
> ```
> 
> You can see that the parameter values `a,b,c,d` are actually fields of
> a struct parameter `_param`. `_param` uniformly appears as the third
> parameter after `self` and `_cmd`. `p _param->a` works of course, but it
> would be nice to be able to say 'p a', since in the source code one sees
> only `a`. `_param` is more or less an implementation detail.
> 
> A clue how to achieve this, would be very much appreciated.
> 
> Ciao
>   Nat!
> 
> 
> [*] except, if it's a picture of thousand words :)
> 
> https://www.mulle-kybernetik.com/weblog/2015/mulle_objc_meta_call_convention.html
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[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=0x7fff5fbff948) at multiple.m:15
   12char:(char) c
   13   float:(float) d
   14   {
   15  printf( "%ld,%d,%c,%.2f\n", a, b, c, d);
-> 16   }
   17   
   18   @end
(lldb) p *_param
(p.long:int:char:float:) $2 = (a = -10, b = 10, c = 'v', d =
18.475)
```

You can see that the parameter values `a,b,c,d` are actually fields of
a struct parameter `_param`. `_param` uniformly appears as the third
parameter after `self` and `_cmd`. `p _param->a` works of course, but it
would be nice to be able to say 'p a', since in the source code one sees
only `a`. `_param` is more or less an implementation detail.

A clue how to achieve this, would be very much appreciated.

Ciao
   Nat!


[*] except, if it's a picture of thousand words :)

https://www.mulle-kybernetik.com/weblog/2015/mulle_objc_meta_call_convention.html
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev