> On Apr 10, 2018, at 3:21 PM, Leonard Mosescu <mose...@google.com> wrote: > > > No. Each binary knows how to tell LLDB what target triple it is. PECOFF files > will always map to the host windows platform or remote-windows when not on a > Windows host computer. If you say "file a.out" and give it a PECOFF file, > just do "target list" and see the platform was selected for you. Since the > Minidump is specific to Windows, it should select the right platform for you. > If it doesn't we will need to fix that. > > Thanks for the clarification. A small side note: yes, the minidump format > originates on Windows, but Breakpad/Crashpad use it across all supported > platforms (including Linux and macOS).
Ahh. So then hopefully it extracts the triple from the mini dump file and sets it correctly which gets us right platform set? > > Does the mini dump format have the UUID or some sort of checksum of the file > in it? > > Yes, the minidump has both the checksum for modules and UUID for the debug > information. Good to hear. > > On Tue, Apr 10, 2018 at 3:12 PM, Greg Clayton <clayb...@gmail.com > <mailto:clayb...@gmail.com>> wrote: > > >> On Apr 10, 2018, at 2:30 PM, Leonard Mosescu <mose...@google.com >> <mailto:mose...@google.com>> wrote: >> >> Thanks Greg! It makes sense and looking at the code it's already implemented >> along those lines: Target::GetSharedModule() defaults to >> Platform::GetSharedModule() if the initial attempt to get the module fails. >> >> The part I'd like to understand is if there's a precedence for modules which >> don't have any accessible file image (local or remote). Is everything >> expected to work if we create placeholder Module & ModuleSpecs? > > No, it is up to the platform to be able to track down files that don't exist > locally. Most platforms do nothing and will return an empty module shared > pointer. We need a file to use or we will just not have any info. > >> (it seems that the current implementation assumes that we have a file >> somewhere. Ex. even creating a Module from a ModuleSpec will still try to >> map the source ModuleSpec to some files). > > Yes. Right now with only the path, we will load the file if it exists on disk > since no UUID was specified in the ModuleSpec which is really bad and can > lead to incorrect info being displayed. > >> >> At Apple, we call "dsymForUUID <UUID>" which, if global defaults were set to >> point at Apple's build servers, would go out and download the correct file >> for us and store it locally in a cache for future use. >> >> Just curious, what happens if the download fails? Is the corresponding >> module skipped? (is this strictly about the dSYMs or the same mechanism >> works for the Mach-O binaries?) > > It will block until the module is downloaded, and it can and often does fail > and returns an error that can be displayed. When we need to download large > debug info files, it creates delays with no user interaction and often leads > to people wondering what is going on. Not optimal, but it does work if you > wait for it. > >> >> That way if you create a target that is a minidump on a different system >> (macOS, linux, etc), the platform would be remote-windows. >> >> Not sure if I understand this one, core & minidumps are currently not using >> any of the the remote debugging machinery, right? Are you suggesting >> changing that? > > No. Each binary knows how to tell LLDB what target triple it is. PECOFF files > will always map to the host windows platform or remote-windows when not on a > Windows host computer. If you say "file a.out" and give it a PECOFF file, > just do "target list" and see the platform was selected for you. Since the > Minidump is specific to Windows, it should select the right platform for you. > If it doesn't we will need to fix that. > > Does the mini dump format have the UUID or some sort of checksum of the file > in it? > >> >> On Tue, Apr 10, 2018 at 11:56 AM, Greg Clayton <clayb...@gmail.com >> <mailto:clayb...@gmail.com>> wrote: >> >> >>> On Apr 10, 2018, at 11:32 AM, Leonard Mosescu via lldb-dev >>> <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote: >>> >>> I'm looking at how the LLDB minidump reader creates the list of modules: >>> >>> void ProcessMinidump::ReadModuleList() { >>> ... >>> const auto file_spec = FileSpec(name.getValue(), true); >>> ModuleSpec module_spec = file_spec; >>> Status error; >>> lldb::ModuleSP module_sp = GetTarget().GetSharedModule(module_spec, >>> &error); >>> if (!module_sp || error.Fail()) { >>> continue; >>> } >>> ... >>> } >>> >>> LLDB currently will insist on finding a local image for the module, which >>> is usually not the case for postmortem debugging on machines different than >>> the the the one where the minidump was created. >>> >>> I don't see an obvious way to model modules which have no local image >>> (which is still different than the remote scenario where there is a remote >>> module image), am I missing anything? >> >> The lldb_private::Platform is responsible for digging up any binaries for a >> given target, so this code should be grabbing the platform from the target >> and using that to get the shared module. That way if you create a target >> that is a minidump on a different system (macOS, linux, etc), the platform >> would be remote-windows. >> >> That being said "ModuleSpec" should be filled in with more than just the >> path. It should specify the UUID info from the mini dump that specifies >> exactly which version the file that you want. That way if the file on the >> current system exists, it won't return it unless the path matches. I assume >> the mini dump has each module's UUID information? If so, set it. If not the >> file format assumes you will be running the dumping the same machine and it >> should be updated to include this information. The platform code can then >> use this UUID info to possible go and fetch the right version from a UUID >> database, or how ever the platform wants to provide access to certain >> binaries. At Apple, we call "dsymForUUID <UUID>" which, if global defaults >> were set to point at Apple's build servers, would go out and download the >> correct file for us and store it locally in a cache for future use. >> >> So fill in the UUID in ModuleSpec and modify the Platform::GetSharedModule() >> for your platform to do the right thing is the correct way to go. >> ProcessMinidump should switch over to using the Platform::GetSharedModule() >> instead of the target one, or use it after the target one if the target >> returns an invalid module. >> >> Let me know if you have any more questions, >> >> Greg >> >>> >>> Thanks! >>> Lemo. >>> >>> >>> >>> _______________________________________________ >>> lldb-dev mailing list >>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>> <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
