Re: [lldb-dev] [llvm-dev] [monorepo] Downstream branch zipping tool available
David Greene via llvm-dev writes: > Now that I think about it, what you really want is something that runs > migrate-downstream-fork.py on the commits in llvm and something that > runs zip-downstream-fork.py on commits in other projects, but they have > to ruin simultaneously to keep the commits in the proper order. After pondering this overnight, I think a better approach might be to do the enhancement of zip-downstream-fork.py described in the comments: # - The script requires a history with submodule updates. It should # be fairly straightforward to enhance the script to take a revlist # directly, ordering the commits according to the revlist. Such a # revlist could be generated from an umbrella repository or via # site-specific mechanisms. This would be passed to # fast_filter_branch.py directly, rather than generating a list via # expand_ref_pattern(self.reflist) in Zipper.run as is currently # done. Changes would need to be made to fast_filter_branch.py to # accept a revlist to process directly, bypassing its invocation of # git rev-list within do_filter. If that were done, then it should be possible to write a tool to generate such a revlist from your llvm master project. The tool would examine each commit in llvm and if it were a commit to llvm, it would add its hash to the revlist. If it were a submodule update it would traverse the gitlink to find the commit in the corresponding project (see find_submodules_in_entry in zip-downstream-fork.py). It would then add that commit's hash to the revlist. If a commit updates multiple submodules then you just have to pick an arbitrary order. All of the code to do the traversal is already in zip-downstream-fork.py. You could enhance it to output a revlist in the same way fast_filter_branch can output a revmap and have it not actually rewrite any commits. You would have to tell it to not skip non-submodule-update commits as described in my previous message. This all assumes that each submodule update only adds one new commit from the project linked by the submodule (zip-downstream-fork.py also makes this assumption). If a submodule update represents moving a submodule up multiple commits, then you'd need something that can walk that history and add hashes to the revlist. The more I think about it, the more it seems to me that this is the easiest way to go. It's much less work that refactoring two tools and should require relatively minimal changes to migrate-downstream-fork.py. -David ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 38373] [lldbsuite] Several tests are flakey on windows and will fail every several dozen runs
https://bugs.llvm.org/show_bug.cgi?id=38373 Stella Stamenova changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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
[lldb-dev] [Bug 21550] lldb reports values for null pointers on Windows -- test_expr_null (TestAnonymous.AnonymousTestCase)
https://bugs.llvm.org/show_bug.cgi?id=21550 Stella Stamenova changed: What|Removed |Added Status|NEW |RESOLVED CC||sti...@microsoft.com Resolution|--- |FIXED --- Comment #5 from Stella Stamenova --- At some point this test started passing on Windows, but it was never un-xfailed. Doing that now. -- 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
[lldb-dev] OperatingSystem plugin
Hi lldb-dev, Could someone explain me why do we use python (OperatingSystemPython) to describe OS objects like threads? What are the advantages of such an approach in comparison to C++ used in Platform plugin for example? IMO, the OperatingSystem plugin could be more like the Platform one, it could have a separate directory for each OS with its own implementation inside. -- Alexander ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] OperatingSystem plugin
You would use an operating system plugin in cases where the underlying process interface doesn't tell the complete story for the OS threads. For instance, a lot of kernel and bare board OS'es have a gdb-remote stub that just describes the state of the threads currently running on the cores of the machine. Any swapped out threads are unknown to it. So the Operating system plugin reconstructs the swapped out threads by looking at OS specific data structures. We didn't think that lldb should own the support for every variant of every OS which might want to reconstruct threads from some data structures in the OS. After all, this isn't dealing with fairly stable API's - like the Platforms do. The OS plugins deal with internal data structures, which tend to change fairly frequently. So trying to package them with lldb doesn't seem supportable. By making the OS plugin something that comes from outside lldb, we allow the kernel developers to provide this knowledge on demand. That is very convenient. For instance, on macOS, the dSYM bundle for the mach kernel contains the Operating System plugin for that kernel. When lldb is used for kernel debugging, it finds the dSYM associated with the kernel it is targeting and loads in the python support from the dSYM. That way it is ensured to get the correct plugin for that kernel. It also means that lldb can support kernel versions that didn't even exist when it was made. As for why this is done with Python and not the C++ SB API's, there's nothing to stop it from also being in C++, you can actually write loadable C++ plugins with the SB API's for data formatters, for instance. But there's generally no significant performance advantage to doing that, and its less convenient, so there just hasn't been much demand for it. Jim > On Dec 19, 2018, at 12:44 PM, Alexander Polyakov via lldb-dev > wrote: > > Hi lldb-dev, > > Could someone explain me why do we use python (OperatingSystemPython) to > describe OS objects like threads? What are the advantages of such an approach > in comparison to C++ used in Platform plugin for example? IMO, the > OperatingSystem plugin could be more like the Platform one, it could have a > separate directory for each OS with its own implementation inside. > > -- > Alexander > ___ > 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] 7.0.1-final has been tagged
Hi, I've tagged the 7.0.1 final release. Testers may begin uploading binaries. -Tom ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 24600] TestHelloWorld can't get a valid callstack after attaching
https://bugs.llvm.org/show_bug.cgi?id=24600 Stella Stamenova changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||sti...@microsoft.com --- Comment #1 from Stella Stamenova --- This test is now passing on Windows -- 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
