Bug fixes for release_38 branch

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.


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”

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.

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.

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.


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?


+Tom who owns the 3.8.1 release