[lldb-dev] C++ method declaration parsing

[Eugene Zemtsov via lldb-dev]

Hi, Everyone.

Current implementation of CPlusPlusLanguage::MethodName::Parse() doesn't
cover full extent of possible function declarations,
or even declarations returned by abi::__cxa_demangle.

Consider this code:
--

#include 
#include 
#include 

void func() {
  printf("func() was called\n");
}

struct Class
{
  Class() {
printf("ctor was called\n");
  }

  Class(const Class& c) {
printf("copy ctor was called\n");
  }

  ~Class() {
printf("dtor was called\n");
  }
};


int main() {
  std::function f = func;
  f();

  Class c;
  std::vector v;
  v.push_back(c);

  return 0;
}

--

When compiled It has at least two symbols that currently cannot be
correctly parsed by MethodName::Parse() .

void std::vector
>::_M_emplace_back_aux(Class const&)
void (* const&std::_Any_data::_M_access() const)() - a
template function that returns a reference to a function pointer.

It causes incorrect behavior in avoid-stepping and sometimes messes
printing of thread backtrace.

I would like to solve this issue, but current implementation of method name
parsing doesn't seem sustainable.
Clever substrings and regexs are fine for trivial cases, but they become a
nightmare once we consider more complex cases.
That's why I'd like to have code that follows some kind of grammar
describing function declarations.

As I see it, choices for new implementation of MethodName::Parse() are
1. Reuse clang parsing code.
2. Parser generated by bison.
3. Handwritten recursive descent parser.

I looked at the option #1, at it appears to be impossible to reuse clang
parser for this kind of zero-context parsing.
Especially given that we care about performance of this code. Clang C++
lexer on the other hand can be reused.

Option #2. Using bison is tempting, but it would require introduction of
new compile time dependency.
That might be especially inconvenient on Windows.

That's why I think option #3 is the way to go. Recursive descent parser
that reuses a C++ lexer from clang.

LLDB doesn't need to parse everything (e.g. we don't care about details of
function arguments), but it needs to be able to handle tricky return types
and base names.
Eventually new implementation should be able to parse signature of every
method generated by STL.

Before starting implementation, I'd love to get some feedback. It might be
that my overlooking something important.

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

Re: [lldb-dev] C++ method declaration parsing

[Eugene Zemtsov via lldb-dev]

Yes, it's a good idea to add cfe-dev.
It is totally possible that I overlooked something and clang can help with
this kind of superficial parsing.

As far as I can see even clang-format does it's own parsing
(UnwrappedLineParser.cpp) and clang-format has very similar need of roughly
understanding of code without knowing any context.

> are you certain that clang's parser would be unacceptably slow?

I don't have any perf numbers to back it up, but it does look like a lot of
clang infrastructure needs to be set up before actual parsing begins. (see
lldb_private::ClangExpressionParser). It's not important though, as at this
stage I don't see how we can reuse clang at all.



On Wed, Mar 15, 2017 at 5:03 PM, Zachary Turner  wrote:

> If there is any way to re-use clang parser for this, it would be
> wonderful.  Even if it means adding support to clang for whatever you need
> in order to make it possible.  You mention performance, are you certain
> that clang's parser would be unacceptably slow?
>
> +cfe-dev as they may have some more input on what it would take to extend
> clang to make this possible.
>
> On Wed, Mar 15, 2017 at 4:48 PM Eugene Zemtsov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hi, Everyone.
>>
>> Current implementation of CPlusPlusLanguage::MethodName::Parse() doesn't
>> cover full extent of possible function declarations,
>> or even declarations returned by abi::__cxa_demangle.
>>
>> Consider this code:
>> --
>>
>> #include 
>> #include 
>> #include 
>>
>> void func() {
>>   printf("func() was called\n");
>> }
>>
>> struct Class
>> {
>>   Class() {
>> printf("ctor was called\n");
>>   }
>>
>>   Class(const Class& c) {
>> printf("copy ctor was called\n");
>>   }
>>
>>   ~Class() {
>> printf("dtor was called\n");
>>   }
>> };
>>
>>
>> int main() {
>>   std::function f = func;
>>   f();
>>
>>   Class c;
>>   std::vector v;
>>   v.push_back(c);
>>
>>   return 0;
>> }
>>
>> --
>>
>> When compiled It has at least two symbols that currently cannot be
>> correctly parsed by MethodName::Parse() .
>>
>> void std::vector >::_M_emplace_back_aux> const&>(Class const&)
>> void (* const&std::_Any_data::_M_access() const)() - a template 
>> function that returns a reference to a function pointer.
>>
>> It causes incorrect behavior in avoid-stepping and sometimes messes
>> printing of thread backtrace.
>>
>> I would like to solve this issue, but current implementation of method
>> name parsing doesn't seem sustainable.
>> Clever substrings and regexs are fine for trivial cases, but they become
>> a nightmare once we consider more complex cases.
>> That's why I'd like to have code that follows some kind of grammar
>> describing function declarations.
>>
>> As I see it, choices for new implementation of MethodName::Parse() are
>> 1. Reuse clang parsing code.
>> 2. Parser generated by bison.
>> 3. Handwritten recursive descent parser.
>>
>> I looked at the option #1, at it appears to be impossible to reuse clang
>> parser for this kind of zero-context parsing.
>> Especially given that we care about performance of this code. Clang C++
>> lexer on the other hand can be reused.
>>
>> Option #2. Using bison is tempting, but it would require introduction of
>> new compile time dependency.
>> That might be especially inconvenient on Windows.
>>
>> That's why I think option #3 is the way to go. Recursive descent parser
>> that reuses a C++ lexer from clang.
>>
>> LLDB doesn't need to parse everything (e.g. we don't care about details
>> of function arguments), but it needs to be able to handle tricky return
>> types and base names.
>> Eventually new implementation should be able to parse signature of every
>> method generated by STL.
>>
>> Before starting implementation, I'd love to get some feedback. It might
>> be that my overlooking something important.
>>
>> --
>> Thanks,
>> Eugene Zemtsov.
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>


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

Re: [lldb-dev] Remote debugging - unix socket and/or specific port

[Eugene Zemtsov via lldb-dev]

Hi Mark,

A quick look at PlatformPOSIX.cpp, PlatformLinux.cpp
and PlatformRemoteGDBServer.cpp shows that Pavel's description of port
forwarding situation is still accurate. On Linux currently there is no way
to know the port number before LLDB tries actually attach to something.

Mentioning of GDB server protocol shouldn't confuse you, it's just a name
of a text protocol LLDB client uses to talk to LLDB server [1]. LLDB tries
to be compatible with GDB in this aspect.


[1] https://sourceware.org/gdb/onlinedocs/gdb/Remote-Protocol.html




On Mon, Jul 24, 2017 at 8:19 AM, Mark Nelson via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Has there been any change in this since reported here :
>
> http://lists.llvm.org/pipermail/lldb-dev/2016-June/010616.html
>
> It is pretty clear that that the remote-linux platform is trying to open
> additional ports to talk to lldb-server, and if that server is in a
> container we need to expose them. But what ports, how many, how to specify?
> All uncertain.
>
> Looking at the source shows there are some (undocumented?) port commands
> in lldb-server platform, I'm wondering if this is a solved problem that
> just doesn't have an easy-to-search-for solution.
>
> BTW, I may be barking up the wrong tree. I am using lldb on the host and
> lldb-server on the remote, so the gdb-server protocol shouldn't be in play,
> at least I don't think so.
>
> But the problem I see in this configuration sure looks to be one of ports
> being firewalled.
>
> >Hi Adrien,
> >
> >I think your diagnosis is correct here. LLDB does indeed create an
> >additional connection to the gdb-server instance which is started by the
> >platform instance when you start debugging. In case of android platforms we
> >already include code to forward this port automatically, but there is no
> >such thing for linux -- we just expect the server to be reachable.
>
>
> 
> --
>
> Mark Nelson – ma...@ieee.org
>  -
> http://marknelson.us
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>


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