<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Guys,<br>
<p> <a class="moz-txt-link-freetext" href="https://wiki.eclipse.org/TCF#Where_can_I_Read_Documentation.3F">https://wiki.eclipse.org/TCF#Where_can_I_Read_Documentation.3F</a><br>
</p>
<br>
I hope you don't mind me chiming in I've been following this thread.
I am a little familiar with the Eclipse Target Communications
Framework (TCF).<br>
<hr width="100%" size="2"><br>
From <a class="moz-txt-link-freetext" href="https://www.eclipse.org/tcf/">https://www.eclipse.org/tcf/</a><br>
<p>
TCF is a vendor-neutral lightweight, extensible network protocol
for driving embedded systems (targets).
</p>
<p>
On top of the protocol, TCF provides a complete modern debugger
for C/C++ and Ada, as well as the "Target Explorer"
for system management. TCF works out of the box for Intel, PPC and
ARM Linux targets
including the Raspberry Pi. It supports Proxying and Tunneling for
IoT devices, and is particularly strong
for multi-process debugging even with slow communication links. <br>
</p>
<hr width="100%" size="2">
<p>Wind River was one of the original developers. The TCF
specification defines a set of services one of which is a symbols
service. The protocol was designed to support asynchronous
communications. It has been around a while. Eclipse contains a
Java client plug in implementation and there is an example 'TCF
Agent' which is a server implementation in C. For more details you
can read up here. <br>
</p>
<p> <a class="moz-txt-link-freetext" href="https://wiki.eclipse.org/TCF#Where_can_I_Read_Documentation.3F">https://wiki.eclipse.org/TCF#Where_can_I_Read_Documentation.3F</a><br>
</p>
<p>I notice on the LLDB project page
<a class="moz-txt-link-freetext" href="http://lldb.llvm.org/projects.html">http://lldb.llvm.org/projects.html</a> item "3 Make a high speed
asynchronous communication channel to replace the gdb-remote
protocol". <br>
</p>
<p>The full TCF specification can also replace the MI.<br>
</p>
Thanks,
<pre class="moz-signature" cols="72">J.R.</pre>
<div class="moz-cite-prefix">On 3/1/2019 13:43, Zachary Turner via
lldb-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAAErz9jfRtnT5oAU3BaqYkjkofMFO1sjGDv32Yk4vFf5jPewew@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr"><br>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Feb 27, 2019 at 4:35
PM Frédéric Riss <<a href="mailto:friss@apple.com"
moz-do-not-send="true">friss@apple.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div
style="word-wrap:break-word;line-break:after-white-space">
<div><br>
<blockquote type="cite">
<div>On Feb 27, 2019, at 3:14 PM, Zachary Turner <<a
href="mailto:zturner@google.com" target="_blank"
moz-do-not-send="true">zturner@google.com</a>>
wrote:</div>
<br
class="m_8609333047654749787Apple-interchange-newline">
<div>
<div dir="ltr"><br>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Feb
27, 2019 at 2:52 PM Frédéric Riss <<a
href="mailto:friss@apple.com"
target="_blank" moz-do-not-send="true">friss@apple.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div
style="word-wrap:break-word;line-break:after-white-space">
<div>
<blockquote type="cite">
<div>On Feb 27, 2019, at 10:12 AM,
Zachary Turner <<a
href="mailto:zturner@google.com"
target="_blank"
moz-do-not-send="true">zturner@google.com</a>>
wrote:</div>
</blockquote>
</div>
</div>
<br>
<div
style="word-wrap:break-word;line-break:after-white-space">
<div><br>
<blockquote type="cite">
<div dir="ltr"
style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
<div class="gmail_quote">
<div>For what it's worth, in an
earlier message I mentioned that I
would probably build the server by
using mostly code from LLVM, and
making sure that it supported the
union of things currently
supported by LLDB and LLVM's DWARF
parsers. Doing that would
naturally require merging the two
(which has been talked about for a
long time) as a pre-requisite, and
I would expect that for testing
purposes we might want something
like llvm-dwarfdump but that dumps
a higher level description of the
information (if we change our
DWARF emission code in LLVM for
example, to output the exact same
type in slightly different ways in
the underlying DWARF, we wouldn't
want our test to break, for
example). So for example imagine
you could run something like
`lldb-dwarfdump -lookup-type=foo
a.out` and it would dump some
description of the type that is
resilient to insignificant changes
in the underlying DWARF.</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</div>
</div>
<div
style="word-wrap:break-word;line-break:after-white-space">
<div>
<div>At which level do you consider the
“DWARF parser” to stop and the debugger
policy to start? In my view, the DWARF
parser stop at the DwarfDIE boundary.
Replacing it wouldn’t get us closer to a
higher-level abstraction.</div>
</div>
</div>
</blockquote>
<div>At the level where you have an alternative
representation that you no longer have to
access to the debug info. In LLDB today, this
"representation" is a combination of LLDB's
own internal symbol hierarchy (e.g.
lldb_private::Type, lldb_private::Function,
etc) and the Clang AST. Once you have
constructed those 2 things, the DWARF parser
is out of the picture.</div>
<div><br>
</div>
<div>A lot of the complexity in processing raw
DWARF comes from handling different versions
of the DWARF spec (e.g. supporting DWARF 4
& DWARF 5), collecting and interpreting
the subset of attributes which happens be
present, following references to other parts
of the DWARF, and then at the end of all this
(or perhaps during all of this), dealing with
"partial information" (e.g. something that
would have saved me a lot of trouble was
missing, now I have to do extra work to find
it).</div>
<div>
<div><br
class="m_8609333047654749787inbox-inbox-Apple-interchange-newline">
I'm treading DWARF expressions as an
exception though, because it would be
somewhat tedious and not provide much value
to convert those into some text format and
then evaluate the text representation of the
expression since it's already in a format
suitable for processing. So for this case,
you could just encode the byte sequence into
a hex string and send that.</div>
<br
class="m_8609333047654749787inbox-inbox-Apple-interchange-newline">
</div>
<div>I hinted at this already, but part of the
problem (at least in my mind) is that our
"DWARF parser" is intermingled with the code
that *interprets the parsed DWARF*. We parse
a little bit, build something, parse a little
bit more, add on to the thing we're building,
etc. This design is fragile and makes error
handling difficult, so part of what I'm
proposing is a separation here, where "parse
as much as possible, and return an
intermediate representation that is as
finished as we are able to make it".</div>
<div><br>
</div>
<div>This part is independent of whether DWARF
parsing is out of process however. That's
still useful even if DWARF parsing is in
process, and we've talked about something like
that for a long time, whereby we have some
kind of API that says "give me the thing,
handle all errors internally, and either
return me a thing which I can trust or an
error". I'm viewing "thing which I can trust"
as some representation which is separate from
the original DWARF, and which we could test --
for example -- by writing a tool which dumps
this representation</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</div>
</div>
<div
style="word-wrap:break-word;line-break:after-white-space">
<div>
<div>Ok, here we are talking about something different
(which you might have been expressing since the
beginning and I misinterpreted). If you want to
decouple dealing with DIEs from creating ASTs as a
preliminary, then I think this would be super valuable
and it addresses my concerns about duplicating the AST
creation logic.</div>
<div><br>
</div>
<div>I’m sure Greg would have comments about the
challenges of lazily parsing the DWARF in such a
design.</div>
</div>
</div>
</blockquote>
<div>Well, I was originally talking about both lumped into one
thing. Because this is a necessary precursor to having it
be out of process :)</div>
<div><br>
</div>
<div>Since we definitely agree on this portion, the question
then becomes: Suppose we have this firm API boundary across
which we either return errors or things that can be
trusted. What are the things which can be trusted? Are
they DIEs? I'm not sure they should be, because we'd have
to synthesize DIEs on the fly in the case where we got
something that was bad but we tried to "fix" it (in order to
sanitize the debug info into something the caller can make
basic assumptions about). And additionally, it doesn't
really make the client's job much easier as far as parsing
goes.</div>
<div><br>
</div>
<div>So, I think it should build up a little bit higher
representation of the debug info, perhaps by piecing
together information from multiple DIEs and sources, and
return that. Definitely laziness will have to be
maintained, but I don't think that's inherently more
difficult with a design where we return something higher
level than DIEs.</div>
<div><br>
</div>
<div>Thoughts?</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
lldb-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>