Sounds like a good idea to me.
(For testing I'd recommend a .ll file with the paths you need hard coded
and lldb-test breakpoint.)
On Wed, 14 Mar 2018 at 05:16, Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> When using "settings set target.source-map", when we try to set
> breakpoints by file and line, we try to undo any source remapping we did so
> we can set the breakpoint correctly:
>
> BreakpointSP Target::CreateBreakpoint(const FileSpecList
> *containingModules,
> const FileSpec &file, uint32_t
> line_no,
> lldb::addr_t offset,
> LazyBool check_inlines,
> LazyBool skip_prologue, bool
> internal,
> bool hardware,
> LazyBool move_to_nearest_code) {
> FileSpec remapped_file;
> ConstString remapped_path;
> if (GetSourcePathMap().ReverseRemapPath(ConstString(file.GetPath().c_str
> ()),
> remapped_path))
> remapped_file.SetFile(remapped_path.AsCString(), true);
> else
> remapped_file = file;
>
>
> Note that the "remapped_file.SetFile(remapped_path.AsCString(), true);"
> is saying to resolve the path. I don't believe we want this path to resolve
> itself right?
>
> I am currently running issues when using this with:
>
> (lldb) settings set target.source-map ./ /Users/me/source
>
> The debug info has all of the compilation directories set to "." and the
> resolving the path will cause the current working directory to be used when
> resolving the path and then we can't set breakpoints because the resolved
> path doesn't match. Any objections if I change the second argument to false
> so it doesn't resolve? I can't imagine we would want this reverse mapping
> to resolve??
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
