From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965293AbcCNOkM (ORCPT ); Mon, 14 Mar 2016 10:40:12 -0400 Received: from mail-wm0-f51.google.com ([74.125.82.51]:36783 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965265AbcCNOkG (ORCPT ); Mon, 14 Mar 2016 10:40:06 -0400 Subject: Re: [PATCHv3 00/13] scripts/gdb: Linux awareness debug commands To: Jan Kiszka , linux-kernel@vger.kernel.org References: <1457005267-843-1-git-send-email-kieran.bingham@linaro.org> <56E596DE.7040707@siemens.com> Cc: lee.jones@linaro.org, peter.griffin@linaro.org, maxime.coquelin@st.com From: Kieran Bingham Message-ID: <56E6CD43.3010400@linaro.org> Date: Mon, 14 Mar 2016 14:40:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56E596DE.7040707@siemens.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13/03/16 16:35, Jan Kiszka wrote: > On 2016-03-03 12:40, Kieran Bingham wrote: >> Hi Jan, >> >> V3 of the patchset respun. Now finally adding the lx-interrupts command >> after I resolved my issues with the Radix Tree parsing. >> >> This command only provides the interrupts that are available generically, >> and it seems that the /proc/interrupts function calls into arch specific >> layers to add extra information about arch specific interrupts. >> >> I'm not sure what to do about this yet - The values returned appear to be >> accurate - but it's just a subset of the information returned by proc. >> > > I didn't test this (due to the breakage in patch 10): Can you give > examples of what is missing, e.g. on ARM or x86? On ARM this is : (gdb) lx-interrupts CPU0 CPU1 18: 587828 150187 36: 66574 0 41: 8 0 42: 106 0 43: 100 0 (gdb) c vs root@ArmACookieMonster:~# cat /proc/interrupts CPU0 CPU1 18: 588057 150274 GIC-0 27 Edge arch_timer 20: 0 0 GIC-0 34 Level timer 36: 66599 0 GIC-0 47 Level eth0 39: 0 0 GIC-0 41 Level mmci-pl18x (cmd) 40: 0 0 GIC-0 42 Level mmci-pl18x (pio) 41: 8 0 GIC-0 44 Level kmi-pl050 42: 106 0 GIC-0 45 Level kmi-pl050 43: 112 0 GIC-0 37 Level uart-pl011 49: 0 0 GIC-0 36 Level rtc-pl031 IPI0: 0 1 CPU wakeup interrupts IPI1: 0 0 Timer broadcast interrupts IPI2: 15867 281362 Rescheduling interrupts IPI3: 0 6 Function call interrupts IPI4: 0 0 CPU stop interrupts IPI5: 0 0 IRQ work interrupts IPI6: 0 0 completion interrupts Err: 0 So quite a substantial subset :( > >> lx_thread_info_by_pid has been useful to me while looking at thread >> awareness, so I've included it into this patch set now. It makes finding >> internal thread information much more convenient. >> >> dentry_name has been moved to the utils module, as I am already using it >> in another command, so it's just not appropriate to be in proc.py >> >> The cpu_list mask iterators make calling for cpu in each_online_cpu() read >> nicely, and I've left the print_cpus() function in for now as a hidden >> helper. It can be used by calling: >> python linux.cpus.print_cpus() >> to check these generators, which I thought was quite nice - but I didn't >> know if it warranted a full command class for this. >> >> For convenience, this patch set submission can be found at >> http://git.linaro.org/people/kieran.bingham/linux.git gdb-scripts-2016-03-03-lkml-submission >> >> Patchset Changelog: >> v3: >> - Radix Tree parser introduced >> - cpu_list mask iterators added >> - lx-interrupts command implemented >> - dentry_name function moved to utils >> - lx-meminfo command PEP8 warnings fixed >> - lx_thread_info_by_pid introduced >> >> v2: >> - Reworked iterators with improved versions from Jeff Mahoney >> - Fixed !CONFIG_MODULES and !CONFIG_MMU support >> - Improvements on lx-meminfo >> - constants.py generated by Kbuild >> - IS_BUILTIN facility used to provide LX_CONFIG values >> >> v1: >> - Introduced lx-iomem, lx-ioports, lx-mounts, lx-meminfo >> >> Kieran Bingham (13): >> scripts/gdb: Provide linux constants >> scripts/gdb: Provide kernel list item generators >> scripts/gdb: Convert modules usage to lists functions >> scripts/gdb: Provide exception catching parser >> scripts/gdb: Support !CONFIG_MODULES gracefully >> scripts/gdb: Provide a dentry_name VFS path helper >> scripts/gdb: Add io resource readers >> scripts/gdb: Add mount point list command >> scripts/gdb: Add meminfo command >> scripts/gdb: Add cpu iterators >> scripts/gdb: Add a Radix Tree Parser >> scripts/gdb: Add interrupts command >> scripts/gdb: Add lx_thread_info_by_pid helper >> >> Kbuild | 10 + >> scripts/gdb/linux/Makefile | 12 +- >> scripts/gdb/linux/constants.py.in | 93 ++++++++ >> scripts/gdb/linux/cpus.py | 21 ++ >> scripts/gdb/linux/lists.py | 20 ++ >> scripts/gdb/linux/modules.py | 22 +- >> scripts/gdb/linux/proc.py | 449 ++++++++++++++++++++++++++++++++++++++ >> scripts/gdb/linux/radixtree.py | 74 +++++++ >> scripts/gdb/linux/tasks.py | 19 ++ >> scripts/gdb/linux/utils.py | 15 ++ >> scripts/gdb/vmlinux-gdb.py | 2 + >> 11 files changed, 724 insertions(+), 13 deletions(-) >> create mode 100644 scripts/gdb/linux/constants.py.in >> create mode 100644 scripts/gdb/linux/radixtree.py >> > > Besides the required rebase and, thus, the missing adjustment of the cpu > masks, I only have minor remarks. Maybe I will have more once I can play > with lx-interrupts ;). Ok - well it's fixed up locally, it's just a matter of prefixing the strings with two underscores. I should be able to get the updated patches out soon I hope. > However, I have a growing concern - I think we already discussed this > offline: Without automated tests, all these helpers may quickly fall > apart as the kernel changes. This should not block these patches, but > maybe you can think about some testing approaches before we have dozens > of helpers which can only be validated manually. Yes, indeed - and the breakage already seen between v4.4 and v4.5 only solidifies the need! I was able to chat to a few of the Linaro LAVA guys on this topic while I was at Connect, and they already have virtual kernels being boot tested. This should provide a good infrastructure to run some automated tests on. So we have the infrastructure - we just need to get the tests written, and included. -- Kieran > Thanks, > Jan >