jingham added a reviewer: clayborg.
jingham added a comment.

Greg originally designed the macOS equivalent of this, so I've added him.

I totally agree that you should only do wide searches for source files when 
there's no way to get a narrower context.  Even "source list" could use the 
current thread & frame as a start context, and only fall back to a full search 
when that fails.  In a big project with many shlibs, you might have multiple 
files of the same name, but if someone specifies foo.cpp while stopped in a 
method of libMyLib.dylib, they probably do mean the one in libMyLib.dylib, if 
it exists...

I'm not terribly happy with the way the module-level source-file remapping 
interacts with debug info.  It overrides the source-map without a way to undo 
that.  The dSYM's that Apple uses internally have module-level source remapping 
in them that point to some NFS mounted directory.  We've had problems where 
somebody has copied over one of these dSYM's and the associated sources, but 
doesn't want to remote mount the directories that host the sources.  The only 
way to point lldb at those is to either copy them over to a directory structure 
that matches the remote path, or edit the dSYM to remove the source  remapping. 
 That's pretty annoying.

On the other hand, I don't think we should show the build locations (or at 
least not as a primary thing) for source files that have come from debuginfod 
or from another module level remapping.  That's confusing to anyone who wants 
to open the file in some other way (for instance if you wanted to hand the file 
off to an external editor.)  If we a way to get at both pieces of information, 
the `source info` command could be used to show the "debug info path" and the 
"local path" for a given source file.  We might want some API (on SBFileSpec?) 
to get the original path - that would actually be useful when trying to figure 
out what you should use for a target.source-map.  But if we have a local copy 
of the file you need to be able to get to that path.

The test does seem like it would be much better as a Python test.

  rG LLVM Github Monorepo



lldb-commits mailing list

Reply via email to