Richard Chamberlain

http://apt.llvm.org/ says "...stable, qualification and development branches (currently 3.9, 4.0 and 5.0)...". Might be worth seeing if the fix could be back-ported to 3.9?

You do need to download the exact executable that was running when the dump was created, along with the core dump, and supply both to lldb (i.e.` lldb ./downloaded_node_binary -c...

Yes, we are going to need a 'collector' tool - as we have for Java - to identify and grab libraries

@vietkute02 if you are seeing a hang when you start loading a dump into lldb it may be this problem: https://bugs.llvm.org/show_bug.cgi?id=26322 You need to move up to lldb 4.0 to...

Trying LLDB/LLNODE on Windows. There seems to be a problem in API/SBDebugger.cpp (LLDB code). It has a hard-coded mangled name for the plugin entry point: ``` // TODO: mangle this...

Note for reference, re "getopt library isn’t on Windows" above. There is an alternative implementation inside LLDB, see getopt_internal() in lldb/source/Host/common/GetOptInc.cpp.

@langhuihui ah, that's clever, so you export a function name from the llnode DLL that matches that hard-coded mangled name in LLDB (which is probably a clang or gcc style...

@langhuihui Unfortunately I have not had time to work on this much this year. I have 2 branches, both quite old now (there has been quite a lot of other...

Re gcore dumps and the hang fix in lldb 4.0 see also the follow-up comments on https://github.com/nodejs/llnode/issues/61

I think that the `npm install` for llnode does extra work to construct the llnode shell script. Probably the `brew install` does not do that, though perhaps it could -...