<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Oct 26, 2017, at 9:34 AM, Zachary Turner <<a href="mailto:zturner@google.com" class="">zturner@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Note that $ is a valid character in a MSVC-mangled symbol name. So, I don't think it will work for that reason alone. FWIW, I also don't like the {,,} syntax very much, but if you read on there's a simpler ! syntax that is pretty nice.<div class=""><br class=""></div><div class="">libfoo!symbolname</div></div></div></blockquote><div class=""><br class=""></div><div class="">lldb uses the initial $ to distinguish keep user defined and result variables and keep them from colliding with program variables (well beyond this particular requirement). For instance, lldb uses the fact that you did:</div><div class=""><br class=""></div><div class="">(lldb) expr int $my_string_ptr = nullptr</div><div class=""><br class=""></div><div class="">to tell itself that this is a persistent result variable that you can refer to in other expressions. So this is a well established practice in lldb. The proposal to extend it to scoping is just a natural extension of that.</div><div class=""><br class=""></div><div class="">Are mangled names with initial $’s common in Windows? If so we may need to abstract this initial character and choose a different one for Windows. Or at least we’ll have to add code to look up the name (or try to demangle it) before deciding it is a persistent variable. Again, it doesn’t matter if $ can be used internally, we always trigger off an initial $.</div><div class=""><br class=""></div><div class="">Note that it is also possible to allow $’s in regular symbol names with a clang compiler flag. But we’ve always treated that as a caveat emptor type thing, and we haven’t gotten any reports of this causing real problems.</div><div class=""><br class=""></div><div class="">Jim</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Oct 26, 2017 at 9:30 AM Greg Clayton <<a href="mailto:clayborg@gmail.com" class="">clayborg@gmail.com</a>> wrote:<br class=""></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" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Oct 25, 2017, at 6:05 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank" class="">zturner@google.com</a>> wrote:</div><br class="m_-4296231386631588951Apple-interchange-newline"><div class=""><div class=""><div dir="auto" class=""><br class=""></div><br class=""><div class="gmail_quote"><div dir="auto" class="">On Wed, Oct 25, 2017 at 4:59 PM Jim Ingham via Phabricator <<a href="mailto:reviews@reviews.llvm.org" target="_blank" class="">reviews@reviews.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">jingham added a comment.<br class="">
<br class="">
Note, BTW, we absolutely need some way to say "this symbol from this library". But first of all, if we're going to do this you need to be able to mix & match within an expression which you can't do with a flag to expr. Instead you need something like:<br class="">
<br class="">
(lldb) expr $$MyDylib$my_symbol + $$MyOtherDylib$my_other_symbol<br class="">
<br class="">
That syntax is ugly, we should try to think of something better. But the main point is this should only be necessary when lldb can't find a unique symbol. When we can no intervention should be required.<br class="">
</blockquote><div dir="auto" class=""><br class=""></div><div dir="auto" class=""><div dir="auto" class="">+1, this is very useful. The Microsoft syntax for this is here:</div><div dir="auto" class=""><br class=""></div><div dir="auto" class=""><a href="https://docs.microsoft.com/en-us/visualstudio/debugger/context-operator-cpp" target="_blank" class="">https://docs.microsoft.com/en-us/visualstudio/debugger/context-operator-cpp</a></div></div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Which is pretty nice imo</div></div></div>
</div></blockquote></div><br class=""></div><div style="word-wrap:break-word" class=""><div class="">The main reason for using $ decorated names is because clang will accept them as identifiers and ask us about them. So "$$MyOtherDylib$my_other_symbol" is just a valid identifier and would result in a find external lexical decl call that we can fill in with whatever we want. </div><div class=""><br class=""></div><div class="">We don't really want to muck with clang by overloading stuff with symbols that would hose up clang (like the MSVC examples "{,,EXAMPLE.dll}SomeFunction", "EXAMPLE.dll!SomeFunction", and "{,,"a long, long, library name.dll"}g_Var". The { } and , characters would hose up the expression parser. So I would vote to use the $ decoration as Jim suggested.</div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class="">Greg</div></div></blockquote></div>
</div></blockquote></div><br class=""></div></body></html>