I am fine with a new plug-in to handle this, but I want to verify a few things
first:
Can this core dump file format basically allow debugging of multiple targets?
For example could you for example want to examine the kernel itself as is, but
also provide a view into any of the user space proce
On Tue, 14 Dec 2021 at 10:58, Pavel Labath via lldb-dev
wrote:
>
> So how would this be represented in lldb? Would there be any threads,
> registers? Just a process with a bunch of modules ?
Using GDB (kgdb) as an example - it lists a thread for every
kernel/userspace thread. For example,
...
5
On 10/12/2021 11:12, Michał Górny wrote:
On Mon, 2021-12-06 at 14:28 +0100, Pavel Labath wrote:
The live kernel debugging sounds... scary. Can you explain how would
this actually work? Like, what would be the supported operations? I
presume you won't be able to actually "stop" the kernel, but wh
On Mon, 2021-12-06 at 14:28 +0100, Pavel Labath wrote:
> The live kernel debugging sounds... scary. Can you explain how would
> this actually work? Like, what would be the supported operations? I
> presume you won't be able to actually "stop" the kernel, but what will
> you actually be able to d
On 30/11/2021 14:49, Michał Górny via lldb-dev wrote:
Hi,
I'm working on a FreeBSD-sponsored project aiming at improving LLDB's
support for debugging FreeBSD kernel to achieve feature parity with
KGDB. As a part of that, I'd like to improve LLDB's ability of working
with kernel coredumps ("vmco
> 1. The (older) "full memory" coredumps that use an ELF container.
>
> 2. The (newer) minidumps that dump only the active memory and use
a custom format.
Maybe a silly question, is the "minidumps" here the same sort of
minidump as lldb already supports
(https://chromium.googlesource.com/breakpad/
> Right now, the idea is that when the kernel crashes, the developer can
> take the vmcore file use LLDB to look the kernel state up.
Thanks for the explanation. (FWIW your first email is clear now that I
read it properly but this still helped me :))
> 2) How to integrate "live kernel" support in
On Thu, 2021-12-02 at 09:40 +, David Spickett wrote:
> Can you give an example workflow of how these core files are used by a
> developer? For some background.
Right now, the idea is that when the kernel crashes, the developer can
take the vmcore file use LLDB to look the kernel state up. Ini
Can you give an example workflow of how these core files are used by a
developer? For some background.
Most of my experience is in userspace, the corefile is "offline" debug
and then you have "live" debug of the running process. Is that the
same here or do we have a mix since you can access some o
Hi,
I'm working on a FreeBSD-sponsored project aiming at improving LLDB's
support for debugging FreeBSD kernel to achieve feature parity with
KGDB. As a part of that, I'd like to improve LLDB's ability of working
with kernel coredumps ("vmcores"), plus add the ability to read kernel
memory via sp
10 matches
Mail list logo