[Lldb-commits] [PATCH] D62505: Fix multiple module loaded with the same UUID

Greg Clayton via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Tue May 28 07:25:27 PDT 2019


clayborg added a comment.

In D62505#1518833 <https://reviews.llvm.org/D62505#1518833>, @labath wrote:

> I agree we need to support a module being loaded multiple times, but I'm not sure if this is the right way to achieve that. I mean, if two files are exactly the same, then it should be fine (and even preferable) to download them just once, store them under a single entry (based on the UUID) in the module cache, and parse their symbols just once. It seems like somebody even intended for us to support a module being loaded multiple times as there is this TODO https://github.com/llvm-mirror/lldb/blob/1b2170d0116d52a219574780e7eb01043c3712e1/source/Target/SectionLoadList.cpp#L50 in the SectionLoadList class.
>
> However, this is not an area I'm super familiar with. Maybe @jingham knows more about this?


So I am familiar with this code and I was working with Antonio on this. I suggested the same thing, but then the amount of work we would need to do to support loading the same file in different areas was a lot more intrusive. What we really want is to have the same module loaded in two places, but each module would need to have its own platform path, one with /system/lib/libcutils.so and one with /system/lib/vndk-sp/libcutils.so. If we don't do this, then we show the user one of those file paths twice which doesn't match reality. That led us to think about a BaseModule class that wouldn't contain the platform file spec, and then we could have two Module instances that share the same BaseModule class. The BaseModule would always contain the local FileSpec that was uniqued. That seemed like a lot of hassle for not much gain. If we allow a lldb_private::Section to be loaded multiple times, there are a lot of places that would need to change in LLDB code where anytime someone tries to resolve a lldb_private::Address to a load address, it will need to be able to deal with multiple results. That will change many locations around the LLDB code base. That is the right fix IMHO, but it will make this code change quite large. So we decided to post this diff up for review so we could talk about the different solutions.

So if we end up going with one module, how do we propose to get around the fact that there are multiple platform paths ("/system/lib/libcutils.so" and "/system/lib/vndk-sp/libcutils.so") for this module? Just make platform path be an array instead of a single path?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62505/new/

https://reviews.llvm.org/D62505





More information about the lldb-commits mailing list