site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GqdFb3WrqUgndm6kFP5DDNlrlnuN+87PKJtrCTsj+mg=; b=Rb0O9xC6fMGaebKgOI+G5TPVtqKlqRovqhgvwV0KnCKW99e/gGDkkZ07DY8mhfrcYn /HaSzStTSmqeVYL01KbD98TRohkbtoqI0KNdEbVwX2mXNBt50bpIPBnrP1hjo9qf+ADD 4lGMkFCJSoKUznj5M1Hxuo4RO2YAW0x2c2kxVbL23VOOvdR8NPsm+YMGx7Hhud2UsBPO YeYh+3CH8idDsYzhwXrTXQ1Umo4abIZYXpaAIe4ewwo2K4mcNLrNHVPP3UQRSI3Uku8o Oge3MxxUcLUG5SIuBa+vyewUpNW40wUQ0OrNUO/c13kkA/hXPHPIVoIo9n67CNLL9ZYA ieRQ== 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 <zohar.cabeli@gmail.com> 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 (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/ slava.imameev%40gmail.com
This email sent to slava.imameev@gmail.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com