<div dir="ltr">I needed to have a (recent) branch of lldb which was stable for debugging across platforms (native darwin, native linux, android, etc). I originally tried using the google/stable branch (which I assume is what ships with Android Studio), but that had some crashes with darwin debugging. I had assumed that the branch shipped with xcode was a private release branch. Since using either google/stable or release_38 would require stabilization, I decided that going ahead and stabilizing release_38 would probably be worthwhile. I assume that this would be beneficial for non-developers who use lldb outside of xcode/android studio as well, given that they may install the linux package for the most recent stable release branch.</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Apr 29, 2016 at 5:28 AM Tamas Berghammer <<a href="mailto:tberghammer@google.com">tberghammer@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Is there any reason you want to use the release_38 branch specifically? As far as I know nobody tested it or using it in the LLDB community so it is approximately as good as any random commit on master. If you are looking for a reasonably stable LLDB then I think you are better off with asking for the version number shipped with xcode or with Android Studio as those versions are a bit more tested and it is used by some users as well.</div><br><div class="gmail_quote"></div><div class="gmail_quote"><div dir="ltr">On Thu, Apr 28, 2016 at 8:57 PM Francis Ricci via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Over the last month or two, I've been working to stabilize the release_38 branch of lldb, and there are commits which fix bugs on this branch that I'd like to cherry-pick down. They're listed at the bottom of this message.<br><br>One thing to note - r251106 is a commit I'd like to revert, instead of a cherry-pick. When we use this commit (multithreaded dwarf parsing) on the 3.8 branch, I run into a lot of dwarf assertion failures, even after cherry-picking all the dwarf fixes I could find from master. I don't see these assertion failures on master, so it's definitely an issue that's been fixed since the branch cut, but I think the best solution for the release_38 branch is to disable it for now.<br><br>r264810 will have a small merge conflict due to an indentation change in lldbpexpect.py<br>r263735 will have a small merge conflict due to a whitespace change on master. Everything else should apply cleanly.<br><div><br>Commits:<br><div>r267741 Use absolute module path when possible if sent in svr4 packets<br>r264810 Fixed the failing test TestCommandScriptImmediateOutput on MacOSX</div><div>r267468 Maintain register numbering across xml include features</div><div>r267467 Properly unload modules from target image list when using svr4 packets</div><div>r267466 Use Process Plugin register indices when communicating with remote</div><div>r267463 Store absolute path for lldb executable in dotest.py</div><div>r267462 Create _lldb python symlink correctly when LLVM_LIBDIR_SUFFIX is used</div><div>r265422 Fix dotest.py '-p' option for multi-process mode</div><div>r265420 Print environment when dumping arch triple</div><div>r265419 Make sure to update Target arch if environment changed</div><div>r265418 Allow gdbremote process to read modules from memory</div><div>r264476 Fix FILE * leak in Python API</div><div>r264351 Make File option flags consistent for Python API</div><div>r263824 Fixed a bug where DW_AT_start_scope would fall through to DW_AT_artificial in SymbolFileDWARF::ParseVariableDIE(). This was caught by the clang warning that catches unannotated case fall throughs.</div><div>r263735 Fix deadlock due to thread list locking in 'bt all' with obj-c</div><div>r261858 Handle the case when a variable is only valid in part of the enclosing scope</div><div>r261598 Fixed a problem where the DWARF for inline functions was mis-parsed.</div><div>r261279 Make sure code that is in the middle of figuring out the correct architecture <span style="line-height:1.5">on attach uses the architecture it has figured out, rather than the Target's </span><span style="line-height:1.5">architecture, which may not have been updated to the correct value yet.</span></div><div>r260626 Don't crash if we have a DIE that has a DW_AT_ranges attribute and yet the SymbolFileDWARF doesn't have a DebugRanges. If this happens print a nice error message to prompt the user to file a bug and attach the offending DWARF file so we can get the correct compiler fixed.</div><div>r260618 Removed a bad assertion:</div><div>r260322 Added code that was commented out during testing to stops template member functions from being added to class definitions (see revision 260308 for details).</div><div>r260308 Fixed many issues that were causing differing type definition issues to show up when parsing expressions.</div><div>r259962 Fix "thread backtrace -s": option was misparsed because of a missing break.</div><div>r258367 Fix a problem where we were not calling fcntl() with the correct arguments for F_DUPFD</div><div>r257786 Fixed a crasher when dealing with table entries that have blank names.</div><div>r257644 Fix an issue where scripted commands would not actually print any of their output if an immediate output file was set in the result object via a Python file object</div><div>REVERT - r251106 Re-commit "Make dwarf parsing multi-threaded"</div></div></div></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
</blockquote></div>
</blockquote></div>