+Tom who owns the 3.8.1 release
On Tue, May 3, 2016 at 10:04 AM, Francis Ricci via lldb-dev <lldb-dev@lists.llvm.org> wrote: > I didn't have any luck with r266423, these dwarf issues can get pretty > tricky. > > 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. > > Hans, can we get these commits cherry-picked onto release_38? > > Thanks! > Francis > > > On Fri, Apr 29, 2016 at 11:40 AM Pavel Labath <lab...@google.com> wrote: >> >> As Tamas said, little effort has gone into the to stabilization of the >> 3.8 branch. Right now, you're the only one looking into it, so I think >> we'll just defer to your judgement. It is a bit of a duplication of >> effort but, I think it is very worthwhile for lldb project as a whole. >> >> For the multithreaded dwarf parsing thing, if you are feeling >> adventurous, you might want to try if r266423 fixes your problems, but >> I think the idea of reverting that part is very reasonable as well. >> >> pl >> >> >> On 29 April 2016 at 19:03, Francis Ricci via lldb-dev >> <lldb-dev@lists.llvm.org> wrote: >> > 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. >> > >> > On Fri, Apr 29, 2016 at 5:28 AM Tamas Berghammer >> > <tbergham...@google.com> >> > wrote: >> >> >> >> 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. >> >> >> >> On Thu, Apr 28, 2016 at 8:57 PM Francis Ricci via lldb-dev >> >> <lldb-dev@lists.llvm.org> wrote: >> >>> >> >>> 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. >> >>> >> >>> 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. >> >>> >> >>> r264810 will have a small merge conflict due to an indentation change >> >>> in >> >>> lldbpexpect.py >> >>> r263735 will have a small merge conflict due to a whitespace change on >> >>> master. Everything else should apply cleanly. >> >>> >> >>> Commits: >> >>> r267741 Use absolute module path when possible if sent in svr4 packets >> >>> r264810 Fixed the failing test TestCommandScriptImmediateOutput on >> >>> MacOSX >> >>> r267468 Maintain register numbering across xml include features >> >>> r267467 Properly unload modules from target image list when using svr4 >> >>> packets >> >>> r267466 Use Process Plugin register indices when communicating with >> >>> remote >> >>> r267463 Store absolute path for lldb executable in dotest.py >> >>> r267462 Create _lldb python symlink correctly when LLVM_LIBDIR_SUFFIX >> >>> is >> >>> used >> >>> r265422 Fix dotest.py '-p' option for multi-process mode >> >>> r265420 Print environment when dumping arch triple >> >>> r265419 Make sure to update Target arch if environment changed >> >>> r265418 Allow gdbremote process to read modules from memory >> >>> r264476 Fix FILE * leak in Python API >> >>> r264351 Make File option flags consistent for Python API >> >>> 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. >> >>> r263735 Fix deadlock due to thread list locking in 'bt all' with obj-c >> >>> r261858 Handle the case when a variable is only valid in part of the >> >>> enclosing scope >> >>> r261598 Fixed a problem where the DWARF for inline functions was >> >>> mis-parsed. >> >>> r261279 Make sure code that is in the middle of figuring out the >> >>> correct >> >>> architecture on attach uses the architecture it has figured out, >> >>> rather than >> >>> the Target's architecture, which may not have been updated to the >> >>> correct >> >>> value yet. >> >>> 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. >> >>> r260618 Removed a bad assertion: >> >>> 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). >> >>> r260308 Fixed many issues that were causing differing type definition >> >>> issues to show up when parsing expressions. >> >>> r259962 Fix "thread backtrace -s": option was misparsed because of a >> >>> missing break. >> >>> r258367 Fix a problem where we were not calling fcntl() with the >> >>> correct >> >>> arguments for F_DUPFD >> >>> r257786 Fixed a crasher when dealing with table entries that have >> >>> blank >> >>> names. >> >>> 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 >> >>> REVERT - r251106 Re-commit "Make dwarf parsing multi-threaded" >> >>> >> >>> _______________________________________________ >> >>> lldb-dev mailing list >> >>> lldb-dev@lists.llvm.org >> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> > >> > >> > _______________________________________________ >> > lldb-dev mailing list >> > lldb-dev@lists.llvm.org >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> > > > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
