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