On 2016-03-14 18:18, Kieran Bingham wrote: > On 14/03/16 15:09, Jan Kiszka wrote: >> On 2016-03-14 15:40, Kieran Bingham wrote: >>> 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 :( >> >> Indeed. Given this delta, I'm reluctant to include that command at this >> point. > > Ok, understandable... > > I think the radix-tree lookup could be useful for people though. > This is used across filesystems, and other places. > > Perhaps I should wrap this up into a gdb.Function rather than drop it? >
Sounds good. Maybe also augment Documentation/gdb-kernel-debugging.txt with a nice example for this (and for other non-obvious features). Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux
