Messages in this thread | | | Subject | Re: [PATCH 3/4] scripts/gdb: Add rb tree iterating utilities | From | Kieran Bingham <> | Date | Wed, 27 Mar 2019 10:37:44 +0000 |
| |
Hi Stephen,
On 26/03/2019 17:05, Stephen Boyd wrote: > Quoting Kieran Bingham (2019-03-26 01:52:10) >> Hi Stephen, >> >> On 25/03/2019 18:45, Stephen Boyd wrote: >>> Implement gdb functions for rb_first(), rb_last(), rb_next(), and >>> rb_prev(). These can be useful to iterate through the kernel's red-black >>> trees. >> >> I definitely approve of getting data-structure helpers into scripts/gdb, >> as it will greatly assist debug options but my last attempt to do this >> was with the radix-tree which I had to give up on as the internals were >> changing rapidly and caused continuous breakage to the helpers. > > Thanks for the background on radix-tree. I haven't looked at that yet, > but I suppose I'll want to have that too at some point.
Sure, it will be useful to get going again, if you get round to it - feel free to either dig out my old patches from the list, or git-history. (I believe they actually made it into the kernel but I had to revert them because of the breakage, and no time to continue that development).
Or of course - start from scratch might also be a good option :D
>> Do you foresee any similar issue here? Or is the corresponding RB code >> in the kernel fairly 'stable'? >> >> >> Please could we make sure whomever maintains the RBTree code is aware of >> the python implementation? >> >> That said, MAINTAINERS doesn't actually seem to list any ownership over >> the rb-tree code, and get_maintainers.pl [0] seems to be pointing at >> Andrew as the probable route in for that code so perhaps that's already >> in place :D > > I don't think that the rb tree implementation is going to change. It > feels similar to the list API. I suppose this problem of keeping things > in sync is a more general problem than just data-structures changing. > The only solution I can offer is to have more testing and usage of these > scripts. Unless gdb can "simulate" or run arbitrary code for us then I > think we're stuck reimplementing kernel internal code in gdb scripts so > that we can get debug info out.
I agree - RB seems a lot more stable than the radix-tree was back when I tried to mirror that implementation.
I would hope at some point we could get some automated tests going for scripts/gdb as we see more and more functionality.
Everything should be automatable using GDB hooked up to QEmu.
GDB can 'run' arbitrary functions - but it's not a good idea as we won't know the state of the target, and of course in the case of crash-dump examination - the target won't even exist.
Anyway, I'm glad this is all useful to you - let us know if there's anything we can do to help. Myself and Jan are trying to take care of scripts/gdb - but there's not a lot of active development of new features currently - so I'm very pleased to see your contributions !
-- Kieran
| |