[lldb-dev] Symbolicate user processes when kernel debugging
Greg Clayton via lldb-dev
lldb-dev at lists.llvm.org
Mon Jun 20 15:57:34 PDT 2016
The right way to do this is to say "I want a GDB server port for user space process 123". The python would then start up a socket that can be connected to that can vend the information about the user space process directly through a dedicated GDB server port. Memory reads would translate the memory asked for through the GDB server port into a physical address and do the read for you as if the memory read came from user space process 123. I know someone had this code working here at Apple, but I am not sure if it made it into the macros. You might check around for such a thing as it might already be in there. Then you can also read memory and read registers just as you would with a core file. Then you can skip all of the manual symbolication stuff as the process will set itself up correctly if the GDB server is responding to all the right questions.
So check around and make sure this isn't already checked into the code.
> On Jun 16, 2016, at 1:38 AM, John Otter via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> I'm using lldb to debug the OS X kernel, and it works great.
> I would like to have more flexibility in analysing user programs while
> debugging the kernel itself,
> and specifically symbolicate the code of the user programs.
> For example I often use the command showthreaduserstack defined here
> to take
> a look at the user stack of a process running in kernel mode that just
> scripts the process of
> obtaining the thread saved state, but the output unfortunately isn't
> Is there a way to add symbols for a user process (programs and shared libs?)
> I looked into the target modules add command, but when I try to add a
> copy of the executable
> it just says that the file I pick doesn't exist (even though it clearly exist).
> Also I'm not entirely sure how that would work since the user space
> addressing space changes
> for every process, even if I manually set the loading address.
> Would that work only for that specific process and execution?
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
More information about the lldb-dev