cmtice added a comment. In D97786#2607275 <https://reviews.llvm.org/D97786#2607275>, @labath wrote:
> In D97786#2603656 <https://reviews.llvm.org/D97786#2603656>, @cmtice wrote: > >> I'm not sure about using target.debug-file-search-paths, and what the >> changes Pavel is suggesting would entail. > > I imagine it would involve calling Symbols::LocateExecutableSymbolFile to > locate the dwo file, similar to how we do that for dwp files (see > `SymbolFileDWARF::GetDwpSymbolFile`). (Disclaimer: I have not tried doing > this, so I don't know if that function would work out-of-the-box.) > Note that I myself am not convinced that this is the right solution (that > function is rather heavy), but it does solve the problem of "how do we let > the user specify/choose the location of the dwo files" (answer: put the path > in the target.debug-file-search-paths setting), and it would search the cwd > and the module directory automatically. And the "heavy-ness" of the function > is moderated by the fact that it is a no-op for absolute paths to existing > files. > >> But the real question I am trying to resolve here is not "what are all the >> places we should be searching for the .dwo files?" but "When we're given a >> *relative path* in the DWARF for finding the files, what should it be >> relative TO?". > > I'm sorry, but what's the difference between those two questions? Is it about > the fact that the second question sort of implies that there should only be > one correct location where we should be searching? I think I'm saying this poorly (I apologize). Let me try a bit differently. It's a matter of defaults. If the user builds with split debug and relative paths, and does not ever move the built binary: 1). it seems wrong to me that the debugger will sometimes find the .dwo files and sometimes will not, depending on where the debugger was launched from. It ought, at the very least, to behave consistently no matter where the debugger was launched from. 2).It is not possible that the compiler could ever have intended that paths to be relative to the location from where the debugger was launched because the compiler could have absolutely no idea where that would be. So when the compiler generated the relative paths, whatever it was truly intended to be relative to, the location from which the debugger was launched could not be it. 3). Given statements 1 & 2, it seems reasonable that the *default* behavior of the debugger is to search relative to the location of the binary. Yes, the user could always use debugger settings to add or update search paths, but I don't think that should be required as part of the default behavior for finding the .dwo files. >> I still think the most correct answer to that question is "relative to the >> location of the binary" (I know, this is assuming that the binary has not >> been moved since it was built, or all bets are off). If you like, I can >> update this patch so that it continues to search relative to the cwd (where >> the debugger was launched), and IN ADDITION, will search relative to where >> the binary is. > > I don't really have a strong opinion either way -- the thing I'm mostly > interested in is some sort of consistency between lldb & gdb. Have you > already discussed this with the gdb folks? If they want to move to the > binary-relative mechanism, then I don't see a problem with us doing the same. > If they want to keep the existing behavior, then I think it would be good to > preserve that in lldb as well (but I don't have a problem with searching in > other places too; and `LocateExecutableSymbolFile` is one way to achieve > that). I have submitted a patch for this to GDB; it is currently under review. I am ok with waiting for this (LLDB) patch to be resolved until the GDB one is. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D97786/new/ https://reviews.llvm.org/D97786 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
