zturner added a comment.
As for the test, this could be a good candidate for a unit test. It's not
advertised very well so there's definitely some work for us to do on that
front, but basically you can run `ninja check-lldb-unit`. Seems like you could
just create a `ModuleSpec` on the stack, construct it the way you want, and
pass it to this function, and verify the output in a couple of different
scenarios. At a minimum the one you ran into this segfault with, but if you
can think of a couple of other useful scenarios to test it wouldn't hurt to
have a couple go in at the same time.
================
Comment at: source/Host/common/Symbols.cpp:238-250
@@ -237,15 +237,15 @@
// Add /usr/lib/debug directory.
debug_file_search_paths.AppendIfUnique (FileSpec("/usr/lib/debug",
true));
std::string uuid_str;
const UUID &module_uuid = module_spec.GetUUID();
if (module_uuid.IsValid())
{
// Some debug files are stored in the .build-id directory like
this:
//
/usr/lib/debug/.build-id/ff/e7fe727889ad82bb153de2ad065b2189693315.debug
uuid_str = module_uuid.GetAsString("");
uuid_str.insert (2, 1, '/');
uuid_str = uuid_str + ".debug";
}
----------------
enlight wrote:
> zturner wrote:
> > Can you do all of this only if the target is not Windows?
> You mean if the **host** is not Windows? Skipping `/usr/lib/debug` on Windows
> makes sense, but it seems like the `uuid_str` stuff could still apply if the
> symbol files are copied to or shared with Windows.
You're right, the host. Also seems reasonable about the `uuid_str` stuff.
Repository:
rL LLVM
http://reviews.llvm.org/D13201
_______________________________________________
lldb-commits mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
