It's going to be quite difficult for lldb to do anything reasonable with the core file if we can't seek around in it. So for practical purposes it is going to have to get stored somehow, either in a file or in some memory that lldb can do random access on. So practically whoever is getting this stream will need to store it somewhere and hand the results to lldb. So from lldb, adding an API that takes the core file from a chunk of memory seems fine. But I'd leave it up to the clients to figure out how to cons up such a thing as they know their situation better (and most times just writing it to disk first is going to seem reasonable.)
BTW, if your platform has a network connection maybe you could stream the core out to a core server that has disk space. That would lessen the need for heroics on the lldb running on this limited resource platform? Jim > On Nov 4, 2015, at 10:14 AM, Mark Chandler via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > Im not sure, but I assume that the kernel writes the core out as the process > reads it. Will need to dig into the kernel code to confirm. > > > Mark Chandler > Battle.Net Engineering Systems | Blizzard Entertainment > (P) 949-955-1380 x15353 > > -----Original Message----- > From: Greg Clayton [mailto:gclay...@apple.com] > Sent: Wednesday, November 04, 2015 10:13 AM > To: Mark Chandler <mchand...@blizzard.com> > Cc: Todd Fiala <todd.fi...@gmail.com>; Pavel Labath <lab...@google.com>; > lldb-dev@lists.llvm.org > Subject: Re: [lldb-dev] Attaching to a stopped (cored) process hangs > lldb-server > > So the entire core file is in memory somehow and when it is read from STDIN > will be then be freed? Seems like a really lame way to pass the core file > around as it requires up to 2x the size of the core in memory. We could add a > new version of SBTarget::LoadCore() like: > > SBProcess > SBTarget::LoadCoreFromData(const void *data, uint64_t data_len); > > But this will be a memory hog depending on if the memory from STDIN > containing the core file gets freed immediately after it is consumed, or if > the data is still around. > > >> On Nov 4, 2015, at 10:05 AM, Mark Chandler <mchand...@blizzard.com> wrote: >> >> The problem becomes when the core data on stdin is gigabytes in size and >> there is little to no diskspace or memory (as the process is still around) >> to store/process the data. >> >> >> Mark Chandler >> Battle.Net Engineering Systems | Blizzard Entertainment >> (P) 949-955-1380 x15353 >> >> -----Original Message----- >> From: Greg Clayton [mailto:gclay...@apple.com] >> Sent: Wednesday, November 04, 2015 10:01 AM >> To: Todd Fiala <todd.fi...@gmail.com> >> Cc: Mark Chandler <mchand...@blizzard.com>; Pavel Labath >> <lab...@google.com>; lldb-dev@lists.llvm.org >> Subject: Re: [lldb-dev] Attaching to a stopped (cored) process hangs >> lldb-server >> >> >>> On Nov 4, 2015, at 9:47 AM, Todd Fiala <todd.fi...@gmail.com> wrote: >>> >>> Although doing any kind of waitpid() in the case of a core file doesn't >>> make sense. >> >> The process is still around. The process is being handed the core file via >> STDIN, but the process is still around and this tool is attaching to that >> process and ignoring the core file data. I would vote to use the core file >> data if the tool is checked in, or at least provide an option to either >> attach to the process or use the core file data... >> >> Greg > > _______________________________________________ > 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
