This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Speed up "gdb -tui" output
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Doug Evans <dje at google dot com>
- Cc: palves at redhat dot com, gdb-patches at sourceware dot org
- Date: Wed, 07 Jan 2015 21:11:16 +0200
- Subject: Re: [PATCH] Speed up "gdb -tui" output
- Authentication-results: sourceware.org; auth=none
- References: <83zj9v7urq dot fsf at gnu dot org> <CADPb22Q7oD3K-dYkngEPDBbV++mLCKifTEmvJczQ=0h2FX0yXA at mail dot gmail dot com> <54AD4E22 dot 1010106 at redhat dot com> <CADPb22RjhBGkbSjuFgGDy4qhRiXAcyaw_-DHdz4pY_-t42FJFQ at mail dot gmail dot com> <83k30y78ol dot fsf at gnu dot org> <CADPb22Tbf7kfTjBn1Ur4r1sY4sEeNrTGhid8yZWut0gvAihcBw at mail dot gmail dot com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Wed, 7 Jan 2015 10:56:11 -0800
> From: Doug Evans <dje@google.com>
> Cc: Pedro Alves <palves@redhat.com>, gdb-patches <gdb-patches@sourceware.org>
>
> >> So, yeah, it seems like gdb_flush for tui needs to do a wrefresh
> >> (for gdb_stdout/stderr (/stdlog?))
> >
> > At least, see my other message. And it should treat them differently,
> > since their buffering is different, and the rest of GDB relies on that
> > a lot. And tui_puts currently doesn't know which stream it serves.
>
> It's easy enough to make tui_puts know what stream it's serving though,
Yes, and then we'd need to figure out which stream to pass to it in
its other callers (there are 6 of them).
> >> One paints the window and then does a refresh.
> >
> > Except that for the command window, there's no such thing as "paint
> > the window", AFAICS.
>
> By "paint the window" I mean writing something into that part of the
> screen.
This is only known on the upper level of the GDB code, the one that
actually generates the stuff that is to be written on the screen.
Lower levels have no idea whether they were called to output a single
character that is just a single character, or a part of a string.
And since there are literally gazillions of calls to output functions
on the higher level, it is only natural to try to fix this in a
smaller number of places, which means on lower levels. I still hope
it's possible. Maybe I'm dreaming.
> > Various parts of GDB write out various text
> > strings whenever they feel like. You don't have a single point where
> > you can tell the window is done. Currently, we simply refresh every
> > character. My original suggestion to use a newline as such a point
> > was an attempt to find an easy solution, and we already know why that
> > is not good enough.
>
> There's no "single" point, but OTOH there aren't many points either.
Not sure what you mean here. Can you identify those points, or
explain how to identify them?
> >> We want to add scrolling of the command line window on
> >> top of that, but if the intent is for that to be handled by
> >> gdb's standard set height mechanism (which could use
> >> some TLC w.r.t. TUI), then the screen will be refreshed
> >> at the "Type <return> to continue, ..." prompt.
> >
> > Yes, of course. And this is part of the problem that needs to be
> > solved.
>
> Except that scrolling isn't straightforward in curses land.
> Do we "scroll" unfiltered output (that hasn't gone through
> the paginator) ?
We don't, but every text terminal window on any modern system has a
scroll-back buffer and a scroll bar to make use of it. When you are
in TUI mode, this is lost.
> >> And therefore, I think we don't need to do any call to
> >> gdb_flush here. Could be missing something though.
> >
> > Where's "there"?
>
> tui_puts, at least in its current implementation.
> It's just an implementation detail though, so
> depending on how we fix things that can change.
Again, I don't understand how else can you emulate the standard
buffering behavior of the standard streams, which we rely upon in too
many places.