So you would save the file, create a target:
const char *core_path = ...; // Save STDIN to a file and put path in
"core_path"
const bool source_init_files = false;
debugger = lldb::SBDebugger::Create(source_init_files);
target = debugger.CreateTarget(None);
process = target.LoadCore(core_path);
if (process.IsValid())
{
// Do any symbolication you need to on your process core file
// as it will behave just like a real process, you just can't run it
}
> On Nov 3, 2015, at 4:34 PM, Greg Clayton via lldb-dev
> <lldb-dev@lists.llvm.org> wrote:
>
> One different approach is to have your tool write all STDIN to a file (the
> core file comes into the tool as STDIN bytes) and then hand LLDB the core
> file and do any needed backtracing and data gathering from the core file
> instead of actually attaching to the process for real. All executable and
> shared library object files (ELF files) from the core file are still on disk
> so you can get symbols and use the debug info, so LLDB should be able to load
> all frames up and symbolicate up the crash location. It should be just as
> good as having the process around without any bad side affects. Core files
> are less useful if they must be archived and symbolicated later because the
> executable files might not be around anymore since things like test suites
> might produce binaries for testing and remove them after the test is run or
> crashed.
>
> What do you think about this approach?
>
> Greg Clayton
>
>
>> On Nov 2, 2015, at 5:54 PM, Mark Chandler via lldb-dev
>> <lldb-dev@lists.llvm.org> wrote:
>>
>> So im trying to write a core handler program and use lldb to attach and dump
>> important information about it. This works if a use my tool to attach to an
>> existing one but I found that lldb-server will hang in a waitpid call if the
>> kernel has invoked the tool after another process has cored.
>>
>> Example:
>> · /proc/sys/kernel/core_pattern is set to |/opt/core_tool
>> · Run a.out and it segfaults
>> · Kernel invokes core_tool that uses lldb AttachToProcess and a.out
>> is in state “S+”
>> · lldb-server hangs in
>> source\Plugins\Process\Linux\NativeProcessLinux.cpp:867
>> · if I remove the waitpid it doesn’t hang but fails to attach
>>
>> Looks like gdb had a similar problem as well:
>> http://www.sourceware.org/ml/gdb-patches/2008-04/msg00224.html
>> Any ideas on how to fix this?
>>
>> Mark Chandler
>> Battle.Net Engineering Systems | Blizzard Entertainment
>> (P) 949-955-1380 x15353
>>
>> _______________________________________________
>> 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
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
