Re: [lldb-dev] Bug fixes for release_38 branch
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
Re: [lldb-dev] LTO debug info
> On Apr 28, 2016, at 8:11 AM, Philippe Lavoie > wrote: > > > What made me suspect a data corruption issue were asserts triggered in the > VC++ vector implementation when we use an LTO binary with a DEBUG lldb build > on Windows. > > For example, > at source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp:624, > > File: C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE\vector > Line: 240 > Expression: vector iterators incompatible > > Digging deeper, the assertion is triggered by accesses to > DWARFCompileUnit::m_die_array > > In the 'parser_fn' lambda in SymbolFileDWARF::Index() that indexes each > compile unit in parallel, DWARFCompileUnit::ExtractDIEsIfNeeded(..) , > DWARFCompileUnit::Index(..) and DWARFCompileUnit::ClearDIEs() are called in > sequence. > > 'ExtractDIEsIfNeeded' and 'ClearDIEs' respectively populates and clears > DWARFCompileUnit::m_die_array. > > But when DWARFCompileUnit::Index(..) looks up a DIE in another CU and that CU > is running 'ExtractDIEsIfNeeded' or 'ClearDIEs', it will access a stale or > invalid DWARFCompileUnit::m_die_array ... So the main question is why is anything that is indexing the current CU only, accessing anything from another CU? It can't and shouldn't. That is the bug. > -Philippe > > > From: Greg Clayton [gclay...@apple.com] > Sent: Monday, April 25, 2016 7:59 PM > To: Philippe Lavoie > Cc: lldb-dev@lists.llvm.org > Subject: Re: [lldb-dev] LTO debug info > >> On Apr 25, 2016, at 1:37 PM, Philippe Lavoie via lldb-dev >> wrote: >> >> Hello, >> >> We noticed an issue with dwarf parsing when debugging a large application >> compiled with LTO. >> >> Since an LTO application's debug info can have inter-compile-unit >> references, (for example: a type defined in one compile-unit and used in >> another) we noticed that the "m_type_index" vector in SymbolFileDWARF can >> get corrupted. This is because many index structures in SymbolFileDWARF are >> generated in parallel. >> >> Is is a bug or is it expected to be the compiler's/linker's job to generate >> self-contained DWARF data without inter-CU references? >> >> -Philippe > > TEach SymbolFileDWARF should generate its own accelerator tables in a self > contained way. No SymbolFileDWARF should be adding references to their > accelerator maps that actually refer to DIEs from another SymbolFileDWARF. We > might need to look at the indexing function that make sure if they see and > DW_FORM_ref_addr attributes, that they don't add any of them to their index. > That seems like the bug? > > Greg > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Bug fixes for release_38 branch
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 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 "Mak
[lldb-dev] google/stable branch on git mirror?
Hi all. First post...new to the mailing list. I was looking for the lldb/branches/google/stable/ branch on a git mirror, but was unable to find it. I was specifically looking at http://llvm.org/git/lldb.git, but didn't see it anywhere else either (github, etc). Is it only available from the svn repo? Would it be useful for anyone else for that branch to be mirrored to the git repo as well? Thanks, Jeff ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Bug fixes for release_38 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. pl On 29 April 2016 at 19:03, Francis Ricci via lldb-dev 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 > 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 >> 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 d
Re: [lldb-dev] LTO debug info
> So the main question is why is anything that is indexing the current CU only, > accessing anything from another CU? It can't and shouldn't. That is the bug. Indexing is accessing another CU because there is a reference (offset) to another CU. For example, in the 2nd compile unit below, the DW_AT_type of DW_TAG_formal_parameter at offset 0x1772 is referencing the 1st compile unit (offset 0x1741). Compilation Unit @ offset 0x16f9: Length:0x4c (32-bit) Version: 4 Abbrev Offset: 0x763 Pointer Size: 4 <0><1704>: Abbrev Number: 1 (DW_TAG_compile_unit) <1705> DW_AT_producer: (indirect string, offset: 0x0): clang version 3.9.0 (trunk) <1709> DW_AT_language: 12 (ANSI C99) <170b> DW_AT_name: (indirect string, offset: 0x4be): main.c <170f> DW_AT_stmt_list : 0x1329 <1713> DW_AT_comp_dir: (indirect string, offset: 0x4c5): C:\Users\phlav\Documents\opus studio 2013\Projects\OpusProject9 <1717> Unknown AT value: 3fe1: 1 <1717> DW_AT_low_pc : 0x40 <171b> DW_AT_high_pc : 0x8 <1><171f>: Abbrev Number: 2 (DW_TAG_subprogram) <1720> DW_AT_low_pc : 0x40 <1724> DW_AT_high_pc : 0x8 <1728> Unknown AT value: 3fe7: 1 <1728> DW_AT_frame_base : 1 byte block: 51 (DW_OP_reg1 (r1)) <172a> DW_AT_name: (indirect string, offset: 0xab): main <172e> DW_AT_decl_file : 1 <172f> DW_AT_decl_line : 4 <1730> DW_AT_type: <0x1741> <1734> DW_AT_external: 1 <1734> Unknown AT value: 3fe1: 1 <2><1734>: Abbrev Number: 3 (DW_TAG_variable) <1735> DW_AT_const_value : 55 <1736> DW_AT_name: (indirect string, offset: 0xd9): x <173a> DW_AT_decl_file : 1 <173b> DW_AT_decl_line : 7 <173c> DW_AT_type: <0x1741> <1><1741>: Abbrev Number: 4 (DW_TAG_base_type) <1742> DW_AT_name: (indirect string, offset: 0x8f): int <1746> DW_AT_encoding: 5 (signed) <1747> DW_AT_byte_size : 4 Compilation Unit @ offset 0x1749: Length:0x32 (32-bit) Version: 4 Abbrev Offset: 0x763 Pointer Size: 4 <0><1754>: Abbrev Number: 5 (DW_TAG_compile_unit) <1755> DW_AT_producer: (indirect string, offset: 0x0): clang version 3.9.0 (trunk) <1759> DW_AT_language: 12 (ANSI C99) <175b> DW_AT_name: (indirect string, offset: 0x505): Source1.c <175f> DW_AT_stmt_list : 0x1362 <1763> DW_AT_comp_dir: (indirect string, offset: 0x50f): C:\Users\phlav\Documents\opus studio 2013\Projects\OpusLibrary <1767> Unknown AT value: 3fe1: 1 <1><1767>: Abbrev Number: 6 (DW_TAG_subprogram) <1768> DW_AT_name: (indirect string, offset: 0x54e): lib <176c> DW_AT_decl_file : 1 <176d> DW_AT_decl_line : 3 <176e> DW_AT_prototyped : 1 <176e> DW_AT_type: <0x1741> <1772> DW_AT_external: 1 <1772> Unknown AT value: 3fe1: 1 <2><1772>: Abbrev Number: 7 (DW_TAG_formal_parameter) <1773> DW_AT_name: (indirect string, offset: 0xd9): x <1777> DW_AT_decl_file : 1 <1778> DW_AT_decl_line : 3 <1779> DW_AT_type: <0x1741> From: Greg Clayton [gclay...@apple.com] Sent: Friday, April 29, 2016 2:02 PM To: Philippe Lavoie Cc: lldb-dev@lists.llvm.org Subject: Re: [lldb-dev] LTO debug info > On Apr 28, 2016, at 8:11 AM, Philippe Lavoie > wrote: > > > What made me suspect a data corruption issue were asserts triggered in the > VC++ vector implementation when we use an LTO binary with a DEBUG lldb build > on Windows. > > For example, > at source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp:624, > > File: C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE\vector > Line: 240 > Expression: vector iterators incompatible > > Digging deeper, the assertion is triggered by accesses to > DWARFCompileUnit::m_die_array > > In the 'parser_fn' lambda in SymbolFileDWARF::Index() that indexes each > compile unit in parallel, DWARFCompileUnit::ExtractDIEsIfNeeded(..) , > DWARFCompileUnit::Index(..) and DWARFCompileUnit::ClearDIEs() are called in > sequence. > > 'ExtractDIEsIfNeeded' and 'ClearDIEs' respectively populates and clears > DWARFCompileUnit::m_die_array. > > But when DWARFCompileUnit::Index(..) looks up a DIE in another CU and that CU > is running 'ExtractDIEsIfNeeded' or 'ClearDIEs', it will access a stale or > invalid DWARFCompileUnit::m_die_array ... So the main question is why is anything that is indexing the current CU only, accessing anything from another CU? It can't and shouldn't. That is the bug. > -Philippe > > > From: Greg Clayton
[lldb-dev] [Bug 27515] TestBitfields hits assert on OS X: Assertion failed: (Offset >= Size), function insertPadding, CGRecordLayoutBuilder.cpp
https://llvm.org/bugs/show_bug.cgi?id=27515 Greg Clayton changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Greg Clayton --- Fixed with: % svn commit Sendingpackages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py Sendingsource/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp Transmitting file data .. Committed revision 268110. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
