Re: [PATCHv3 00/13] scripts/gdb: Linux awareness debug commands

From: Jan Kiszka
Date: Mon Mar 14 2016 - 13:32:56 EST


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