From: Phil Muldoon <pmuldoon@redhat.com>
To: Teresa Thomas <tthomas@redhat.com>
Cc: frysk@sourceware.org
Subject: Re: Debuginfo utilities added
Date: Wed, 01 Aug 2007 00:18:00 -0000 [thread overview]
Message-ID: <46AFD149.1030900@redhat.com> (raw)
In-Reply-To: <46AFB0B7.1040806@redhat.com>
Teresa Thomas wrote:
> I have just merged my branch with the main branch and committed the
> changes. As mentioned earlier, I've added two new related utilities in
> frysk/frysk-core/bindir:
>
> 1) fdebuginfo <pid(s)> - which lists the debuginfo paths for the
> (attached) process' modules. Its output format is a simple list of
> module names, followed by their debuginfo paths. Paths for ones that
> do not contain debuginfo, are shown as "---".
Awesome, these tools I've been looking forward to for awhile!
Future suggestion:
fdebuginfo <executable> that does the same as <pid> but for a latent,
inanimate executable on disk.
> 2) fdebugrpm <pid(s)> - which is a bash script that allows you to
> install the missing debuginfo packages using yum. This lists the
> missing debuginfo packages, and gives the user a choice to install them.
I tried this but got:
[pmuldoon@localhost bindir]$ sudo ./fdebugrpm 2788
Missing Debuginfo package(s)
============================
bash-debuginfo
glibc-debuginfo
ncurses-debuginfo
Do you wish to install the above packages? [y/n]: y
Loading "installonlyn" plugin
Setting up Install Process
Parsing package install arguments
Nothing to do
No debuginfo packages were installed.
I then noticed that in: /etc/yum.repos.d//fedora-updates.repo
The "enabled" flag was = 0. So I set it to 1. That installed the
glibc-debuginfo but not the ncurses and bash debuginfo packages.
I then looked at fedora.repo and the enabled flag was set to 0 there as
well. Set that to 1 and it all worked.
Anyway I mention this, as it seems debuginfo repos are off by default.
If that is so, then some blurb in the man page would be help the user here.
I really like this utility, though. Very useful!
One last item for improvement/discussion. Both fstack and fcore are very
thin wrappers around StrackTraceAction and CoredumpAction classes
respectively. The reason for this is that these classes can then be
called from other utilities, even triggered as part of an observable
action, or via fhpd. Would the same go for extruding classes from
fdebug*, and making the fdebug* executables a thin layer around a
utility class?
Regards
Phil
prev parent reply other threads:[~2007-08-01 0:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-31 21:59 Teresa Thomas
2007-08-01 0:18 ` Phil Muldoon [this message]
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=46AFD149.1030900@redhat.com \
--to=pmuldoon@redhat.com \
--cc=frysk@sourceware.org \
--cc=tthomas@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).