On 31 May 2017 at 19:40, Jim Ingham <jing...@apple.com> 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
