[lldb-dev] Bug fixes for release_38 branch

Fri Apr 29 11:40:07 PDT 2016

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
>