Re: Debuginfo utilities added

[Phil Muldoon <pmuldoon at redhat dot 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