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.
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.