Why does symfile.c use printf_filtered?

Why does symfile.c use printf_filtered?

[J. Johnston]

Does anybody know why symfile.c uses printf_filtered()?

This causes a couple of problems, most notably when you load a module with a lot 
of shared library references.  The messages for "Reading symbols from"... inside 
symfile.c are printed filtered so eventually we end up causing a page break.  I 
do not think this information is worthy of requiring user intervention.

Would anybody have an objection to me changing to use printf_unfiltered() in 
symfile.c?

-- Jeff J.

Re: Why does symfile.c use printf_filtered?

[Eli Zaretskii]

> Date: Tue, 21 Oct 2003 17:30:23 -0400
> From: "J. Johnston" <jjohnstn@redhat.com>
> 
> Does anybody know why symfile.c uses printf_filtered()?
> 
> This causes a couple of problems, most notably when you load a module with a lot 
> of shared library references.  The messages for "Reading symbols from"... inside 
> symfile.c are printed filtered so eventually we end up causing a page break.  I 
> do not think this information is worthy of requiring user intervention.

Unless there's some important situation where this is necessary, it
does seem silly to use printf_filtered in this case.

Re: Why does symfile.c use printf_filtered?

[Daniel Jacobowitz]

On Wed, Oct 22, 2003 at 08:17:22AM +0200, Eli Zaretskii wrote:
> > Date: Tue, 21 Oct 2003 17:30:23 -0400
> > From: "J. Johnston" <jjohnstn@redhat.com>
> > 
> > Does anybody know why symfile.c uses printf_filtered()?
> > 
> > This causes a couple of problems, most notably when you load a module with a lot 
> > of shared library references.  The messages for "Reading symbols from"... inside 
> > symfile.c are printed filtered so eventually we end up causing a page break.  I 
> > do not think this information is worthy of requiring user intervention.
> 
> Unless there's some important situation where this is necessary, it
> does seem silly to use printf_filtered in this case.

Very strongly agree.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Why does symfile.c use printf_filtered?

[Jim Blandy]

"J. Johnston" <jjohnstn@redhat.com> writes:

> Does anybody know why symfile.c uses printf_filtered()?
> 
> This causes a couple of problems, most notably when you load a module
> with a lot of shared library references.  The messages for "Reading
> symbols from"... inside symfile.c are printed filtered so eventually
> we end up causing a page break.  I do not think this information is
> worthy of requiring user intervention.
> 
> Would anybody have an objection to me changing to use
> printf_unfiltered() in symfile.c?

No, that'd be fine.

I have to wonder, though --- if one doesn't care whether the messages
are scrolling off the screen or not, should one print them at all?
What would folks think of just ditching the fprintf altogether, and
making sure there's some general message that says it's reading
symbols?

I suppose those messages are nice in that they provide a context for
any error messages that might come afterwards, but I think it'd be
better just to improve the error messages to mention the filename
involved, rather than spew stuff all the time on the off chance
something will go wrong.

Re: Why does symfile.c use printf_filtered?

[Andrew Cagney]

> Does anybody know why symfile.c uses printf_filtered()?
> 
> This causes a couple of problems, most notably when you load a module with a lot of shared library references.  The messages for "Reading symbols from"... inside symfile.c are printed filtered so eventually we end up causing a page break.  I do not think this information is worthy of requiring user intervention.
> 
> Would anybody have an objection to me changing to use printf_unfiltered() in symfile.c?

It certainly doesn't look right.

Log messages are there to keep the user up-to-date on what GDB is doing 
(and confirm that GDB hasn't hung ...).  Just like other such messages 
(thread notifications, hosted output from the remote) they should halt 
GDB and hence shouldn't be paged.

This is different to something like "info registers" where GDB has 
stopped, and the user expects to be able to read the entire response.

enjoy,
Andrew

Re: Why does symfile.c use printf_filtered?

[Daniel Jacobowitz]

On Fri, Oct 24, 2003 at 01:55:35PM -0400, Andrew Cagney wrote:
> >Does anybody know why symfile.c uses printf_filtered()?
> >
> >This causes a couple of problems, most notably when you load a module with 
> >a lot of shared library references.  The messages for "Reading symbols 
> >from"... inside symfile.c are printed filtered so eventually we end up 
> >causing a page break.  I do not think this information is worthy of 
> >requiring user intervention.
> >
> >Would anybody have an objection to me changing to use printf_unfiltered() 
> >in symfile.c?
> 
> It certainly doesn't look right.

Which oesn't look right?

> Log messages are there to keep the user up-to-date on what GDB is doing 
> (and confirm that GDB hasn't hung ...).  Just like other such messages 
> (thread notifications, hosted output from the remote) they should halt 

                                                           "shouldn't"?
> GDB and hence shouldn't be paged.
> 
> This is different to something like "info registers" where GDB has 
> stopped, and the user expects to be able to read the entire response.
> 
> enjoy,
> Andrew
> 
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Why does symfile.c use printf_filtered?

[Andrew Cagney]

> Log messages are there to keep the user up-to-date on what GDB is doing 
>> (and confirm that GDB hasn't hung ...).  Just like other such messages 
>> (thread notifications, hosted output from the remote) they should halt 
> 
> 
>                                                            "shouldn't"?

Grr, yes.  "shouldn't".  Having the hosted output, fir instance, stop 
after 24 lines would (and did) drive people batty :-)

>> GDB and hence shouldn't be paged.
>> 
>> This is different to something like "info registers" where GDB has 
>> stopped, and the user expects to be able to read the entire response.

.

Re: Why does symfile.c use printf_filtered?

[Jim Ingham]

On Oct 22, 2003, at 3:14 PM, gdb-digest-help@sources.redhat.com wrote:

> "J. Johnston" <jjohnstn@redhat.com> writes:
>
>> Does anybody know why symfile.c uses printf_filtered()?
>>
>> This causes a couple of problems, most notably when you load a module
>> with a lot of shared library references.  The messages for "Reading
>> symbols from"... inside symfile.c are printed filtered so eventually
>> we end up causing a page break.  I do not think this information is
>> worthy of requiring user intervention.
>>
>> Would anybody have an objection to me changing to use
>> printf_unfiltered() in symfile.c?
>
> No, that'd be fine.
>
> I have to wonder, though --- if one doesn't care whether the messages
> are scrolling off the screen or not, should one print them at all?
> What would folks think of just ditching the fprintf altogether, and
> making sure there's some general message that says it's reading
> symbols?
>
> I suppose those messages are nice in that they provide a context for
> any error messages that might come afterwards, but I think it'd be
> better just to improve the error messages to mention the filename
> involved, rather than spew stuff all the time on the off chance
> something will go wrong.

These messages only show up when you set verbose on, so they don't 
appear in the normal case.  Then I think you just get one dot per 
shared library.  On a big application stack (like the Mac OS X 
framework stacks, for instance) there are lots of libraries to be read 
in.  Having the dots serves as a progress meter, so you know gdb is not 
just hung...

If you are working on the frameworks, you usually have the system copy 
in the regular install location, and then the copy you are working on.  
Instead of installing your working copy (which can mess up your whole 
machine) most folks use the environment variable (LD_LIBRARY_PATH, or 
on Mac OS X DYLD_FRAMEWORK_PATH) to point at the version they want to 
use.  I have noticed that the folks who  do this around here often keep 
the verbose setting on to make sure that they are indeed using the 
versions of the libraries that they intended.  I bet this is not all 
that uncommon.

So I think these messages are useful.

Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer

Re: Why does symfile.c use printf_filtered?

[Jim Blandy]

Jim Ingham <jingham@apple.com> writes:
> These messages only show up when you set verbose on, so they don't
> appear in the normal case.  Then I think you just get one dot per
> shared library.

No, that's not right:

symfile.c:symbol_file_add_with_addrs_or_offsets:

  if ((objfile->flags & OBJF_MAPPED) && (objfile->flags & OBJF_SYMS))
        ...
  else
    {
      /* We either created a new mapped symbol table, mapped an existing
         symbol table file which has not had initial symbol reading
         performed, or need to read an unmapped symbol table. */
      if (from_tty || info_verbose)
	{
	  if (pre_add_symbol_hook)
	    pre_add_symbol_hook (name);
	  else
	    {
	      printf_filtered ("Reading symbols from %s...", name);
	      wrap_here ("");
	      gdb_flush (gdb_stdout);
	    }
	}
      syms_from_objfile (objfile, addrs, offsets, num_offsets,
                         mainline, from_tty);
    }

So it shows up when invoked from a command, too.  And I don't see any
"dot per shared library code" here --- perhaps that's a local mod.

Perhaps the best behavior would be for GDB to print a dot per shlib,
unless 'set verbose on' is on, in which case it should print the full
filename.

Jeff, how does that sound?  Is that more trouble than you wanted to
get into, or would you be willing to put together a patch for that?

Re: Why does symfile.c use printf_filtered?

[Jim Ingham]

Oops, you are right, we print the "."'s down in the macosx shared 
library layer.  This is very useful...

Jim

On Oct 23, 2003, at 12:33 PM, Jim Blandy wrote:

>
> Jim Ingham <jingham@apple.com> writes:
>> These messages only show up when you set verbose on, so they don't
>> appear in the normal case.  Then I think you just get one dot per
>> shared library.
>
> No, that's not right:
>
> symfile.c:symbol_file_add_with_addrs_or_offsets:
>
>   if ((objfile->flags & OBJF_MAPPED) && (objfile->flags & OBJF_SYMS))
>         ...
>   else
>     {
>       /* We either created a new mapped symbol table, mapped an 
> existing
>          symbol table file which has not had initial symbol reading
>          performed, or need to read an unmapped symbol table. */
>       if (from_tty || info_verbose)
> 	{
> 	  if (pre_add_symbol_hook)
> 	    pre_add_symbol_hook (name);
> 	  else
> 	    {
> 	      printf_filtered ("Reading symbols from %s...", name);
> 	      wrap_here ("");
> 	      gdb_flush (gdb_stdout);
> 	    }
> 	}
>       syms_from_objfile (objfile, addrs, offsets, num_offsets,
>                          mainline, from_tty);
>     }
>
> So it shows up when invoked from a command, too.  And I don't see any
> "dot per shared library code" here --- perhaps that's a local mod.
>
> Perhaps the best behavior would be for GDB to print a dot per shlib,
> unless 'set verbose on' is on, in which case it should print the full
> filename.
>
> Jeff, how does that sound?  Is that more trouble than you wanted to
> get into, or would you be willing to put together a patch for that?
>
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer

Re: Why does symfile.c use printf_filtered?

[J. Johnston]

Jim Blandy wrote:
> Jim Ingham <jingham@apple.com> writes:
> 
>>These messages only show up when you set verbose on, so they don't
>>appear in the normal case.  Then I think you just get one dot per
>>shared library.
> 
> 
> No, that's not right:
> 
> symfile.c:symbol_file_add_with_addrs_or_offsets:
> 
>   if ((objfile->flags & OBJF_MAPPED) && (objfile->flags & OBJF_SYMS))
>         ...
>   else
>     {
>       /* We either created a new mapped symbol table, mapped an existing
>          symbol table file which has not had initial symbol reading
>          performed, or need to read an unmapped symbol table. */
>       if (from_tty || info_verbose)
> 	{
> 	  if (pre_add_symbol_hook)
> 	    pre_add_symbol_hook (name);
> 	  else
> 	    {
> 	      printf_filtered ("Reading symbols from %s...", name);
> 	      wrap_here ("");
> 	      gdb_flush (gdb_stdout);
> 	    }
> 	}
>       syms_from_objfile (objfile, addrs, offsets, num_offsets,
>                          mainline, from_tty);
>     }
> 
> So it shows up when invoked from a command, too.  And I don't see any
> "dot per shared library code" here --- perhaps that's a local mod.
> 
> Perhaps the best behavior would be for GDB to print a dot per shlib,
> unless 'set verbose on' is on, in which case it should print the full
> filename.
> 
> Jeff, how does that sound?  Is that more trouble than you wanted to
> get into, or would you be willing to put together a patch for that?
> 

I have already posted a patch that hasn't gotten any response yet.  Perhaps, you 
can comment on that patch with this suggestion and I can look at combining the 
changes or else it can be done after my other patch is approved/denied.

-- Jeff J.