dblaikie added a comment. In D97786#2976549 <https://reviews.llvm.org/D97786#2976549>, @pfaffe wrote:
> In D97786#2974879 <https://reviews.llvm.org/D97786#2974879>, @dblaikie wrote: > >> Not fixable? Not sure I follow. In the case of cwd-relative (old behavior) >> you can fix the behavior by changing where you invoke the debugger from, and >> in the case of exe-relative you can fix the behavior by moving the >> executable? (once both source and dwo lookup is implemented consistently, at >> least) > > Thanks, I totally missed the fact that the patch intended to keep > cwd-relative lookup working! Hmm, sorry, I didn't mean to imply that/didn't know the patch did that (perhaps it only does by accident, I'm not sure). What I meant was - no matter which interpretation (binary relative or cwd relative) is provided by a DWARF consumer, there's a way to make it work (assuming the paths in the DWARF/across all the CUs are consistently relative to the same thing) - either you move the binary, or you move where you invoke the binary from/your cwd. So I don't think either interpretation makes something unworkable/unusable, depending on where you define the constraints of the problem (if you define it as "there's something you can do when compiling/linking the binary to get a certain behavior to work" (ie: you can always get cwd-relative if that's what you want), then yes, there's no solution if the change is made to make it binary-relative - but if you define the problem as "there's a way to debug this binary given these relative paths" - then yes, I think there's an answer either way: move the binary, or move the cwd). Then it's a question of backwards compatibility (I don't know of anyone relying on the cwd-relative behavior, do you? the only place using this functionality that I know of is Chromium) and a general "which is the better behavior", which, again, if it's basically only Chromium using it/built for that situation, I think it's fair to say they probably get to say which is more suitable for their use case. (all this said: Chromium already had a debugger configuration (at least for gdb?) to set the `directories` property ( https://sourceware.org/gdb/onlinedocs/gdb/Source-Path.html ) - which basically overrides/implements the comp_dir relative searching (by initializing the `directories` property, by default, with `$cdir;$cwd` (so it searches a given DWARF-specified-comp_dir-relative-path relative to DW_AT_comp_dir, and if that fails, searches relative to $cwd) - which meant that it really didn't matter what DW_AT_comp_dir they used, it could've been complete garbage and wouldn't've mattered) - but that hadn't extended to dwo searching, so they had a problem with dwo searching, which, imho, the right solution would've been to extend gdb's use of its `directories` property to be used also for dwo searching, since it's the mechanism for comp_dir relative path resolution and dwo paths are comp_dir relative - then there wouldn't've been much need to change anything, so far as I know... (and some similar functionality for lldb would be nice too)) Repository: rG LLVM Github Monorepo 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
