https://sourceware.org/bugzilla/show_bug.cgi?id=25548
Pavel Labath <labath at google dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |labath at google dot com
--- Comment #3 from Pavel Labath <labath at google dot com> ---
The "soundness" that Konrad mentions in #c2 refers to the fact that "/FOO/../
-> /" transformation is correct only in case "FOO" is not a symlink. If it is,
then "FOO/.." can point to just about anywhere. The only way to know where it
will _really_ point to is to fetch the original value of the symlink, but this
may not be possible if one is dealing with paths which do not necessarily come
from the host system.
So, I think that doing these kinds of transformations in these cases (e.g. when
setting a breakpoint) is reasonable -- we don't need to a file to actually
exist in order to set a breakpoint, and we don't want to force the user to type
the exact path that happened to find its way into the debug info.
The part where this (IMO) becomes unsound is when lldb does these
transformations on _all_ paths, even those that definitely do refer to the host
filesystem (e.g. the file which we are about to execute).
Anyway, going back to this bug, I don't think it's unreasonable for debuginfod
to support queries with "canonicalized" paths, but I can also understand a
position which says that this canonicalization is bad, and that one should
perform queries with the original path. Indeed, one can envision a world where
lldb allows the user to set a breakpoint using the "canonicalized" path, but
then performs the file lookups using the "original" path instead. These lookups
would not even need to be limited to debuginfod -- using the original path for
host filesystem lookups would also improve correctness in certain obscure
scenarios. It's just that reaching this world in lldb will be tricky (but not
impossible), because this canonicalization happens at a very low layer (but
this is something I would want to change anyway).
--
You are receiving this mail because:
You are on the CC list for the bug.
