Re: [patch] GDB 7.2: new feature for "backtrace" that cuts path to file (remain filename)

[Phil Muldoon <pmuldoon@redhat.com>]

Tom Tromey <tromey@redhat.com> writes:


> Joel> Yeah, I am wondering which way would be best. It seems like a Python
> Joel> backtrace decorator would already work, or could be made to work.
>
> We have a plan to implement "frame filters" in Python.  The idea here is
> basically pretty-printing for backtraces -- let libraries ship Python
> code to modify frames while they are being displayed.  E.g., the Python
> interpreter could replace C frames with synthetic frames representing
> the Python stack.
>
> Full details are available somewhere -- either archer or gdb list
> archives.  If you want to read them and can't find them, let me know,
> and I will either dig them up or write them again.
>
> Phil would have to say the status of this work.


This is long term work.  I hope to have it for 7.4.  The task is
complex, because I think the backtrace code right now is not too callback
friendly.  That being said, every new Python feature requires one to
become somewhat of an expert in that area. This is happy, if sometimes
long work.

Okay, enough excuses.  We need more GDB-Python hackers! I  don't want to
disappear down this hole for too long as there are other tasks that
are shorter term that I think are more important, and bugs that also
need addressing.  Tom and other have been doing a super job reviewing
existing Python patches, but I really need to do more of that.  If only
not to collide (like I did this week!) with the few others working in
this space. Anyway, the backtrace work is neat stuff.  It will be
implemented sooner rather than later.

> Joel> So, there are pluses and minuses on both ends.  I am wondering
> Joel> what everyone else thinks...
>
> I am happy adding any vaguely sensible setting that people want to the
> core.  Why not?  The time more minimalism has long passed.

Me too. Feature rich at this point.  Everyone wants something different
out of GDB, and debugging scenarios tend to be unique.  But I think some
features offer a common-ground, and this is one of them.

> Whether this one meets the bar, I don't know.  Is basename really the
> obvious transform to apply?  What about just dropping the compilation
> directory?

Well in this context, user-driven needs, to me, are the best bar.  If
this contributor has written this patch, with a specific need (not
super-specialised) in mind that is great.  I wish I had the backtrace
Pythonic interface ready, but, OTOH, every use-case is great to mould
that functionality. 

Cheers,

Phil