[Lldb-commits] [PATCH] D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files.

Wed Sep 1 12:40:06 PDT 2021

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