Re: [RFA 2/2] PR cli/19551 - change formatting of "Reading symbols" messages

[Tom Tromey <tom at tromey dot com>]

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

>> It modifies the DWARF reader(s) to update the progress.  

Pedro> What does GDB show with the reader?  Is their output now broken, same,
Pedro> etc?
Pedro> Sorry, I meant, what does GDB show with the other readers.

I didn't update these, so it just prints, e.g.:

Reading symbols from outputs/gdb.stabs/weird/weirdx.o

I could take a look at the others I suppose.

>> Any printing is deferred until the first progress report, so the
>> messages no longer clash.

Pedro> Can you clarify what printing you're referring to?

This bit meant that the "Reading ..." message isn't emitted until the
first progress update.  This is what makes it so these messages don't
clash.

Pedro> What happens if gdb emits e.g., complaints while a progress bar
Pedro> is half full?

You get terrible-looking stuff like:

(gdb) file ../gdb
Reading symbols from ../gdb
[###################################                                          ]unsupported stack op: 'DW_OP_stack_value'...unsupported stack op: 'DW_OP_stack_va[####################################                                         ]u[####################################                                         ]u[######################################                                       ]u[##############################################                               ]unsupported stack op: 'DW_OP_stack_value'...unsupported stack op: 'DW_OP_stack_value'...unsupported stack op: 'DW_OP_stack_value'...unsupported stack op: 'DW_OP_[##############################################################               ]unsupported stack op: 'DW_OP_stack_value'...unsupported stack op: 'DW_OP_stack_va                                                                               


Maybe there's no easy way to improve this :( The issue is that the
complaint system just writes to the ui-file, bypassing ui-out entirely.
Complaints could be fixed, but this same problem would apply to any
possible output during symbol reading.

Though FWIW I don't think anybody other than gdb developers enables
complaints.

Pedro> I noticed that if you clear the screen such that the prompt is not at
Pedro> the bottom when gdb reads symbols (e.g., start gdb on itself,
Pedro> run to main, do ctrl-l to clear the screen, and do
Pedro> "nosharedlibrary / sharedlibrary"), and if symbol reading is quick, then
Pedro> the meter appears/disappears very quickly in what looks like an
Pedro> odd flash.  It looks a tiny bit annoying to me.  Though not a deal breaker
Pedro> and I'll get used to it for sure.  One way around it would be to
Pedro> not print the meter unless the operation is taking longer than some
Pedro> minimum time, like 1s or some such.

I'm wondering if you are seeing the case where the first notification is
at howmuch=1.0, causing printing of the progress bar followed by
immediately erasing it.

I can't see the effect myself, but that's an idea... I changed it to
avoid this case specifically.

>> +  /* Stack of progress meters.  */
>> +  std::vector<cli_progress_info> m_meters;

Pedro> I think it'd be good to have this comment expanded a bit to
Pedro> explain why we need a stack, and what happens when we're
Pedro> already printing a meter and a new stack level appears.

This case also doesn't really work.  If a meter is already printing, a
new meter will just confuse the output.  The current system relies on
the way that gdb does symbol reading, where it discovers separate
debuginfo before doing any work on the original objfile.

Pedro> If implementations can do nothing, shouldn't "nothing" be the
Pedro> default implementation?

I made the change; but I did it this way originally since the base class
looked purely abstract to me.

I made all the other changes.  I still didn't write the test for the
first patch, though, and I'm also experiencing a possible intermittent
with the buildbot (not sure, maybe it's my other patch series), so it
may be a little while before v2.

Tom