[Lldb-commits] [PATCH] D33426: Introduce new command: thread backtrace unique

[Zachary Turner via lldb-commits]

Couple of things:

1) Unless you really really want iteration over this map to be in some
deterministic order, better to use unordered_map.  And if you do want it to
be in some deterministic order, you should provde a comparison function, as
the default one is probably not what you want.
2) std::map<std::vector<lldb::addr_t>, std::vector<uint32_t>> is pretty
horrible to read, and offers no insight into what the keys and values are.
At the very least, add some typedefs like:
typedef std::vector<lldb::addr_t> StackID;
typedef std::vector<tid_t> ThreadIDList;
std::unordered_map<StackID, ThreadIDList> TheMap;
3) If performance is a concern here (700+ threads seems like it could
exhibit slowdown when uniquing stacks), the best performance would be to
use DenseSet<std::unique_ptr<StackInfo>>, where StackInfo contains both the
address list and the thread is list as well as a pre-computed hash value,
and then use a custom implementation of DenseMapInfo that just returns the
hash value directly.  See llvm/lib/DebugInfo/CodeView/TypeSerializer.cpp
for an example.

On Tue, May 30, 2017 at 8:40 AM Greg Clayton via Phabricator via
lldb-commits <lldb-commits at lists.llvm.org> wrote:

> clayborg added a comment.
>
> The other option for fixing the problem with showing the wrong variables
> in the backtraces would be to make up a new frame-format string that is
> used for uniqued stack frames and use that format when showing uniqued
> stack frames:
>
>   (lldb) settings show frame-format-unique
>   frame-format (format-string) = "frame #${frame.index}: ${frame.pc}{
> ${module.file.basename}{`${function.name}{${frame.no-debug}${function.pc-offset}}}}{
> at ${line.file.basename}:${line.number}}{${function.is-optimized} [opt]}\n"
>
> The only difference in the format string is we use ${function.name}
> instead of ${function.name-with-args}.
>
>
> https://reviews.llvm.org/D33426
>
>
>
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20170530/10fc2639/attachment.html>