1

When debugging in kernel space, I sometimes wish to search for thread according to its backtrace frames among a group of threads, like all the threads on a specific task.

For example, getting kernel_task id 

(lldb) showalltasks
task                 vm_map              ...command             
0xffffff800d828550   0xffffff800a1038d8  ...kernel_task

Dumping all threads belonged to kernel_task

(lldb) showtaskthreads 0xffffff800d828550
task                 vm_map               ipc_space            #acts flags    pid       process             io_policy  wq_state  command
0xffffff800d828550   0xffffff800a1038d8   0xffffff800d5d17c0     140            0   0xffffff8007abb460                -1 -1 -1    kernel_task         
thread                   thread_id  processor            base   pri    sched_mode      io_policy       state    ast          waitq                            wait_event           wmesg                thread_name         
    0xffffff8007acf098       0x65       0xffffff8007a8a7b8   92     92     fixed bound                     WU       L            0xffffff804119e550               0xffffff8007a87a30 <vm_page_free_wanted>                                          
    0xffffff800d83f4c0       0x66       0xffffff8007a8a7b8   0      0      fixed bound                     RI       L                                                                                                           
    0xffffff800d83f958       0x67       0xffffff8041ad6000   95     95     fixed                           WU       L            0xffffff804119c240               0xffffff8007303840 <sched_timeshare_maintenance_continue>                      sched_maintenance_thread
    0xffffff800d83fdf0       0x68       0xffffff8041ad6000   80     80     fixed                           WU       L            0xffffff804119e850               0xffffff8007acf9f0                                            
    0xffffff800d83f028       0x69       0xffffff8007a8a7b8   93     93     fixed                           WU                    0xffffff804119e5e0               0xffffff8007acfa08

Now I can see thread id's and lots of other information about the threads, but how can I observe the threads' backtrace ?

Tsyvarev
  • 60,011
  • 17
  • 110
  • 153
Zohar81
  • 4,554
  • 5
  • 29
  • 82

1 Answers1

1

For whatever reason, the xnu kernel debugging macros use both "thread" and "activation" (abbreviated "act") terminology when talking about threads. With this information, you'll quickly find:

showactstack <activation>

Where <activation> is the thread address (pointer value, not ID), so e.g. showactstack 0xffffff8007acf098.

Note also the following helpful commands:

showtaskstacks <task address>
showtaskstacks -F <taskname>

These show all the stacks corresponding to a task/process.

showallstacks

This prints the kernel stacks for all threads in the system. Be warned: this one can take a while to complete. (IIRC it's faster over Firewire than ethernet kdp, but can still take minutes.)

pmdj
  • 22,018
  • 3
  • 52
  • 103
  • thanks for the help ! by the way, I'm almost certain it's impossible, but is there a lldb command that also let you see the user-space threads ? – Zohar81 Dec 28 '17 at 16:46
  • I've never used them, but you could try `showtaskuserstacks`/`showthreaduserstack`. Prefix them with "help" to find out the arguments etc. I suspect the tricky thing there will be looking up symbols correctly. By the way, most of the kernel debugging macros start with 'show', so you can get a decent list of them by typing 'show' and pressing tab to attempt autocomplete. – pmdj Dec 28 '17 at 17:05
  • thanks man, those functions are working, but as you mentioned, the tricky part is figuring out the addresses because they belong to a different mapping. right now I'm seeking how to change to process context in order to get the symbols out of those addresses. – Zohar81 Jan 01 '18 at 11:13
  • @Zohar81 You're probably best off grabbing the symbol load addresses of any processes you want to inspect in user space before you hit the kernel debugger. – pmdj Jan 01 '18 at 11:52