[lldb-dev] Bug fixes for release_38 branch

Tue May 3 10:26:20 PDT 2016

+Tom who owns the 3.8.1 release

On Tue, May 3, 2016 at 10:04 AM, Francis Ricci via lldb-dev
<lldb-dev at 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 <labath at 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 at 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
>> > <tberghammer at 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 at 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 at lists.llvm.org
>> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> >
>> >
>> > _______________________________________________
>> > lldb-dev mailing list
>> > lldb-dev at lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> >
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>