Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2019-11-05T10:41:20+00:00 2019-11-05T10:41:20+00:00 Pavel Labath pavel@labath.sk 2019-11-05T10:37:59+00:00 urn:sha1:f71e35dc1f3ea9b368b1d4626ee9bf7993839084 2019-10-31T10:24:55+00:00 Pavel Labath pavel@labath.sk 2019-10-16T08:38:10+00:00 urn:sha1:193a7bfb697b5d2adb1c3d37a9d624aa8131ec35 Summary: Not all minidumps contain information about memory permissions. However, it is still important to know which regions of memory contain potentially executable code. This is particularly important for unwinding on win32, as the default unwind method there relies on scanning the stack for things which "look like" code pointers. This patch enables ProcessMinidump to reconstruct the likely permissions of memory regions using the sections of loaded object files. It only does this if we don't have a better source (memory info list stream, or linux /proc/maps) for this information, and only if the information in the object files does not conflict with the information in the minidump. Theoretically that last bit could be improved, since the permissions obtained from the MemoryList streams is also only a very rough guess, but it did not seem worthwhile to complicate the implementation because of that because there will generally be no overlap in practice as the MemoryList will contain the stack contents and not any module data. The patch adds a test checking that the module section permissions are entered into the memory region list, and also a test which demonstrate that now the unwinder is able to correctly find return addresses even in minidumps without memory info list streams. There's one TODO left in this patch, which is that the "memory region" output does not give any indication about the "don't know" values of memory region permissions (it just prints them as if they permission bit was set). I address this in a follow up. Reviewers: amccarth, clayborg Subscribers: mgrang, lldb-commits Differential Revision: https://reviews.llvm.org/D69105 2019-10-18T13:49:40+00:00 Pavel Labath pavel@labath.sk 2019-10-18T13:49:40+00:00 urn:sha1:ea8b8fdf90d3d72db04b07950e913536a2116608 llvm-svn: 375234 2019-10-10T14:01:59+00:00 Pavel Labath pavel@labath.sk 2019-10-10T14:01:59+00:00 urn:sha1:390accea83c099b256c48f218fac0900478b761b llvm-svn: 374353 2019-10-09T19:22:02+00:00 Jonas Devlieghere jonas@devlieghere.com 2019-10-09T19:22:02+00:00 urn:sha1:87aa9c9e4d41ed881453e2fab85b3d25f648bb55 The original patch got reverted because it broke `check-lldb` on a clean build. This fixes that. llvm-svn: 374201 2019-10-09T17:35:43+00:00 Adrian Prantl aprantl@apple.com 2019-10-09T17:35:43+00:00 urn:sha1:0115c10328281567391855766fef8fbe57a1d4cc as it appears to have broken check-lldb. This reverts r374184 (git commit 22314179f0660c172514b397060fd8f34b586e82) llvm-svn: 374187 2019-10-09T16:38:47+00:00 Jonas Devlieghere jonas@devlieghere.com 2019-10-09T16:38:47+00:00 urn:sha1:22314179f0660c172514b397060fd8f34b586e82 LLDB has three major testing strategies: unit tests, tests that exercise the SB API though dotest.py and what we currently call lit tests. The later is rather confusing as we're now using lit as the driver for all three types of tests. As most of this grew organically, the directory structure in the LLDB repository doesn't really make this clear. The 'lit' tests are part of the root and among these tests there's a Unit and Suite folder for the unit and dotest-tests. This layout makes it impossible to run just the lit tests. This patch changes the directory layout to match the 3 testing strategies, each with their own directory and their own configuration file. This means there are now 3 directories under lit with 3 corresponding targets: - API (check-lldb-api): Test exercising the SB API. - Shell (check-lldb-shell): Test exercising command line utilities. - Unit (check-lldb-unit): Unit tests. Finally, there's still the `check-lldb` target that runs all three test suites. Finally, this also renames the lit folder to `test` to match the LLVM repository layout. Differential revision: https://reviews.llvm.org/D68606 llvm-svn: 374184