[Lldb-commits] [PATCH] D83023: [lldb/ObjectFileMachO] Fetch shared cache images from our own shared cache

[Frederic Riss via Phabricator via lldb-commits]

friss added a comment.

In D83023#2129985 <https://reviews.llvm.org/D83023#2129985>, @labath wrote:

> In D83023#2128475 <https://reviews.llvm.org/D83023#2128475>, @friss wrote:
>
> > In D83023#2128298 <https://reviews.llvm.org/D83023#2128298>, @labath wrote:
> >
> > > I think this is a very interesting feature (lldb being able to load modules from memory; the mac shared cache thingy is interesting too, but in a different way). We have a feature request from people who are downloading modules from a network (from a proprietary symbol server, etc.) and would like to pass them to lldb without having to serialize them to disk. This would be a step towards making that happen. It could also be useful for our own unit tests which now have to do a similar thing.
> > >
> > > However, I think this could use some clean up. There's a lot of juggling of data/file/object offsets going on, and it all seems inconsistent and avoidable to me. Please see inline comments for details.
> >
> >
> > I'll see what can be done. My main goal while working on this was to avoid changing the semantics outside of the shared cache usecase. I understand fairly well the codepath that I added and then just moved some other bits around to keep the existing semantics for the rest. Happy to rework this.
>
>
> So, if an object file needs to access some data which is outside of "its" image then my idea about using sliced data buffers will probably not work. It that case, using the "object offset" field to communicate the location of the "object" might not be a bad idea (it's still different than the use in .a files, but maybe we can stretch that definition). The part that bugs me then is having this functionality key off of the "data" field being set. Ideally, these would be two orthogonal features:
>
> - the "data" would control whether you read the file system to obtain the object contents
> - the "object offset" would tell you where to locate the desired object inside these "jumbo" objects


I think this will work. And I can hide the ugliness inside ObjectFileMachO. A shared cache image only ever needs to access data after its start, so I can model images a stretching from their starting point to the end of the shared cache. I remember doing it this way first, and the reason I changed my mind was because of some checks in the ObjectFileMachO::CreateSections which fired because the load commands were relative to the full shared cache instead of just the image. This can be dealt with locally in this function (the rest of the code has to deal with it anyway, because once an ObjectFile plugin claims an input, the data gets clamped to not have a starting offset anymore

Take a look at https://reviews.llvm.org/D83512, it implements the generic part and it required basically no work to support ELF in-memory files.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83023