[lldb-dev] Ubuntu nightly package for lldb 3.8 has no binary
I'm trying to install lldb-3.8 on Ubuntu (trusty), but installing the lldb-3.8 packages doesn't appear to install a binary (only symlinks). According to dpkg -L, I have the following symlinks: /usr/bin/lldb-3.8 -> ../lib/llvm-3.8/bin/lldb /usr/lib/llvm-3.8/bin/lldb -> lldb-3.8.0 /usr/lib/llvm-3.8/bin/lldb-3.8.0 does not exist, and dpkg doesn't show any other possible lldb binaries. I'm using: deb http://llvm.org/apt/trusty/ llvm-toolchain-trusty-3.8 main deb-src http://llvm.org/apt/trusty/ llvm-toolchain-trusty-3.8 main Installing lldb-3.9 works without a problem. Is this a known problem? If you can point me to the scripts used by the nightly builds, I can look into it. Francis ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Ubuntu nightly package for lldb 3.8 has no binary
CC-ing llvm-dev. On Wed, Apr 27, 2016 at 1:57 AM Pavel Labath wrote: > Hi, > > last time I tried the prebuilt packages (it was quite a while ago), > they did not work, but I had no time to figure out what's wrong with > them. I think it would be super-great if someone would take a look and > make sure the prebuilt lldb packages work. I haven't seen any mention > of these scripts in this forum though, so you may need to ask on > llvm-dev instead... > > pl > > > On 27 April 2016 at 02:05, Francis Ricci via lldb-dev > wrote: > > I'm trying to install lldb-3.8 on Ubuntu (trusty), but installing the > > lldb-3.8 packages doesn't appear to install a binary (only symlinks). > > According to dpkg -L, I have the following symlinks: > > /usr/bin/lldb-3.8 -> ../lib/llvm-3.8/bin/lldb > > /usr/lib/llvm-3.8/bin/lldb -> lldb-3.8.0 > > > > /usr/lib/llvm-3.8/bin/lldb-3.8.0 does not exist, and dpkg doesn't show > any > > other possible lldb binaries. > > > > I'm using: > > deb http://llvm.org/apt/trusty/ llvm-toolchain-trusty-3.8 main > > deb-src http://llvm.org/apt/trusty/ llvm-toolchain-trusty-3.8 main > > > > Installing lldb-3.9 works without a problem. > > > > Is this a known problem? If you can point me to the scripts used by the > > nightly builds, I can look into it. > > > > Francis > > > > ___ > > 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] 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. 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
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&quo
Re: [lldb-dev] Ubuntu nightly package for lldb 3.8 has no binary
Bumping this. If someone could point me to the build scripts used or some documentation for how the nightly builds run, I can investigate the lldb package issues on my own from there. Thanks! Francis On Wed, Apr 27, 2016 at 9:22 AM Francis Ricci wrote: > CC-ing llvm-dev. > > On Wed, Apr 27, 2016 at 1:57 AM Pavel Labath wrote: > >> Hi, >> >> last time I tried the prebuilt packages (it was quite a while ago), >> they did not work, but I had no time to figure out what's wrong with >> them. I think it would be super-great if someone would take a look and >> make sure the prebuilt lldb packages work. I haven't seen any mention >> of these scripts in this forum though, so you may need to ask on >> llvm-dev instead... >> >> pl >> >> >> On 27 April 2016 at 02:05, Francis Ricci via lldb-dev >> wrote: >> > I'm trying to install lldb-3.8 on Ubuntu (trusty), but installing the >> > lldb-3.8 packages doesn't appear to install a binary (only symlinks). >> > According to dpkg -L, I have the following symlinks: >> > /usr/bin/lldb-3.8 -> ../lib/llvm-3.8/bin/lldb >> > /usr/lib/llvm-3.8/bin/lldb -> lldb-3.8.0 >> > >> > /usr/lib/llvm-3.8/bin/lldb-3.8.0 does not exist, and dpkg doesn't show >> any >> > other possible lldb binaries. >> > >> > I'm using: >> > deb http://llvm.org/apt/trusty/ llvm-toolchain-trusty-3.8 main >> > deb-src http://llvm.org/apt/trusty/ llvm-toolchain-trusty-3.8 main >> > >> > Installing lldb-3.9 works without a problem. >> > >> > Is this a known problem? If you can point me to the scripts used by the >> > nightly builds, I can look into it. >> > >> > Francis >> > >> > ___ >> > 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] Bug fixes for release_38 branch
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 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 > 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 memor
[lldb-dev] Release_38 cherry-picks
Hi all, I'd like to merge a few more small bugfixes onto the 38 release branch. I'll plan to do it tomorrow (3/7) in the evening if I don't hear any objections. Thanks! r259433 - Fix getCompiler in unit testing framework on compiler symlinks r267459 - Add missing qRegisterInfo option to gdbremote testcase r271899 - Don't remove PIE executables when using svr4 packets Francis ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Returning multiple values in Python API function
Hi all, I'm looking to add Platform::LaunchGDBServer() to the SBPlatform API, but it requires two return values - an lldb::pid_t and a string url. Internally, we just pass by reference, but we can't do that in the API. Any suggestions on how to do this, since we can't pass primitives by reference from Python? My current thinking was to use the pid_t as the return value, and then figure out a way to communicate the string information as an "out" function parameter. Ideas there included using an SBStream&, as the GetDescription() functions do, but that doesn't seem optimal. In standard Python, we'd just use a tuple return value, but I don't see any way to do that using the swig interface. The reasoning behind adding this API function is to prevent the platform-mode GdbRemote tests from launching the gdbserver using an 'A' packet instead of the standard 'qLaunchGDBServer' packet. Thanks, Francis ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Returning multiple values in Python API function
On Fri, Oct 21, 2016 at 3:30 PM, Greg Clayton wrote: > >> On Oct 21, 2016, at 1:03 PM, Francis Ricci via lldb-dev >> wrote: >> >> Hi all, >> >> I'm looking to add Platform::LaunchGDBServer() to the SBPlatform API, >> but it requires two return values - an lldb::pid_t and a string url. >> Internally, we just pass by reference, but we can't do that in the >> API. Any suggestions on how to do this, since we can't pass primitives >> by reference from Python? >> >> My current thinking was to use the pid_t as the return value, and then >> figure out a way to communicate the string information as an "out" >> function parameter. Ideas there included using an SBStream&, as the >> GetDescription() functions do, but that doesn't seem optimal. >> >> In standard Python, we'd just use a tuple return value, but I don't >> see any way to do that using the swig interface. >> >> The reasoning behind adding this API function is to prevent the >> platform-mode GdbRemote tests from launching the gdbserver using an >> 'A' packet instead of the standard 'qLaunchGDBServer' packet. > > I am still unclear as to why you want this? An lldb-server that is launched > in platform mode shouldn't use the 'A' packet at all. Right. The problem is that our test suite (specifically the lldb-server tests) uses the 'A' packet to spawn the inferior for lldb-server's which are launched in platform mode. > Can you elaborate on why you need this more? Why do we need to prevent it > from using an 'A' packet in the first place? What is leading to this > happening? gdbremote_testcase.py, in launch_debug_monitor, calls self.spawnSubprocess() on the lldb-server exe. This in turn calls _RemoteProcess.launch() in lldbtest.py, which calls lldb.remote_platform.Launch(), which will use the 'A' packet, with the path to the lldb-server. I think this is broken, and the qLaunchGDBServer packet should be used instead. The problem is that there currently isn't a good way to use this packet from the Python API. It is somewhat odd to me that the platform-mode lldb-server even accepts the 'A' packet, but it appears to, given that the `Handle_A` method is contained in `GDBRemoteCommunicationServerCommon` and not `GDBRemoteCommunicationServerLLGS`. > Why do you want to launch on manually? As far as I know, the lldb-server tests send packets manually in general, since they don't run with the full lldb, and just a python stub to test the remote protocols. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
