From: Jim Ingham <jingham@apple.com>
To: gdb@sources.redhat.com
Subject: Re: Why does symfile.c use printf_filtered?
Date: Wed, 22 Oct 2003 23:35:00 -0000 [thread overview]
Message-ID: <77974AB1-04E8-11D8-A22C-000A958F4C44@apple.com> (raw)
In-Reply-To: <1066860856.12586.ezmlm@sources.redhat.com>
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
next parent reply other threads:[~2003-10-22 23:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1066860856.12586.ezmlm@sources.redhat.com>
2003-10-22 23:35 ` Jim Ingham [this message]
2003-10-23 19:34 ` Jim Blandy
2003-10-24 17:14 ` Jim Ingham
2003-10-24 17:23 ` J. Johnston
2003-10-21 21:30 J. Johnston
2003-10-22 6:16 ` Eli Zaretskii
2003-10-22 13:30 ` Daniel Jacobowitz
2003-10-22 22:14 ` Jim Blandy
2003-10-24 17:55 ` Andrew Cagney
2003-10-24 18:51 ` Daniel Jacobowitz
2003-10-24 20:50 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=77974AB1-04E8-11D8-A22C-000A958F4C44@apple.com \
--to=jingham@apple.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox