labath added a comment. In D62505#1519166 <https://reviews.llvm.org/D62505#1519166>, @aadsm wrote:
> Interesting, I did miss that comment when I checked that class. This is > something @clayborg was concerned with when I discussed this solution with > him. The main reason I was not keen in having multiple load addresses for a > section is because that would change the GetLoadAddress to return an array > instead of an addr_t or some kind of mechanism to be able to correctly > resolve the load address of an Address (felt like too big of a change for > what it looks like an edge case?). I wouldn't say this is specific to some class of samsung phones. It is easy to use dlmopen(3) to open the same library multiple times. Just try calling `dlmopen(LM_ID_NEWLM, "/lib64/libc.so.6", RTLD_NOW)` in a loop a couple of times and see what happens in /proc/<pid>/maps. (I believe this is the same function that android uses to implement vndk separation.) In D62505#1519178 <https://reviews.llvm.org/D62505#1519178>, @clayborg wrote: > 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? TBH, I'm not really convinced that the "platform path" should be a property of the Module. Imagine a situation where I have the same module loaded in multiple targets (maybe on different remote platforms, or maybe not). It makes sense that each target can have the module located at a different path. So maybe the "platform path" should be a property of the target, saying "where did this target load the module from"? Of course, this won't help when you have the same module loaded multiple times in the same target, so maybe this does need to be a list of paths? I'm not sure, I'm just thinking aloud here... Right now, I'm also lean towards making a Section be loadable multiple times, however this definitely needs more discussion. I'm interested to hear what @jingham thinks of this. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62505/new/ https://reviews.llvm.org/D62505 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
