Re: Debugging kext in lldb. Reading cpu_data_t offset 0x18 using %gs base address.
Re: Debugging kext in lldb. Reading cpu_data_t offset 0x18 using %gs base address.
- Subject: Re: Debugging kext in lldb. Reading cpu_data_t offset 0x18 using %gs base address.
- From: Slava Imameev <email@hidden>
- Date: Sun, 17 Jun 2018 02:12:27 +1000
Hi,
The GS register doesn't contain a virtual address for a segment. The GS
register contains an offset into a GDT that contains segment descriptors.
Actually, you don't need to access per-CPU data this way. Per-CPU data can
be found by dereferencing elements from an array of pointers
cpu_data_t *cpu_data_ptr[MAX_CPUS]
For example, per-cpu data for a core which has been assigned an index 0
(lldb) p *cpu_data_ptr[0]
(cpu_data_t) $2 = {
cpu_this = 0xffffff800ec0c900
cpu_active_thread = 0xffffff8019e017b0
cpu_nthread = 0xffffff8019e017b0
cpu_preemption_level = 4
cpu_number = 0
cpu_int_state = 0xffffff801604be40
cpu_active_stack = 0xffffff8016048000
cpu_kernel_stack = 0xffffff801604bfb0
cpu_int_stack_top = 0xffffff8081a2a000
cpu_interrupt_level = 1
cpu_signals = 0
cpu_prior_signals = 0
....
The above assumes that you have loaded a kernel dump or attached to a live
system with valid kernel symbols.
If you are not sure on which core a kext is running use showcurrentstacks
command.
Regards,
Slava Imameev
On Thu, Jun 14, 2018 at 6:14 PM, Zohar Cabeli <email@hidden>
wrote:
> Hi,
>
> I was wondering if you could give me some direction in lldb issue I'm
> currently struggling with ...
>
> I've got a kext that produce panic for "preemption level -1" in macOS
> Mojave (10.14), and I'd like to further investigate the issue.
> It looks like preemption_level is read from the per-cpu data which that be
> parsed using cpu_data_t struct (defined in xnu cpu_data.h).
>
> However, it seems like the memory is inaccessible using memory read of
> %gs+0x18:
>
> register read gs
>
> gs = 0x000000009da40000
>
>
> memory read 0x000000009da40018
>
> error: kdp read memory failed (error 4)
>
> perhaps there is another way of reading the cpu data ?
>
>
> I also tried another approach by looking how could the preemption level be
> negative. I guess that when using spin lock, it blocks the preemption of
> the cpu... however, I've tried to look for such locks in all threads (using
> `showallstacks` lldb command) but couldn't find any.
>
> Perhaps do you know better way to checking in lldb if spin lock is
> currently active on any cpu ?
>
> Thanks,
> Zohar
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Darwin-kernel mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
> email@hidden
>
> This email sent to email@hidden
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden