Description of problem:

If analyzing a core dump on a different machine from the one on which it was generated, it may be necessary to install a number of debuginfo packages corresponding to binary packages on the machine where the core was generated.

gdb helpfully suggests yum commands to find the right debuginfo packages by build-id.  However installing *just* the debuginfo package, and not the package containing the actual executable or library binary, causes gdb to print an extremely misleading suggestion.

Version-Release number of selected component (if applicable):

gdb-7.2-60.el6_4.1.x86_64

Steps to Reproduce:
1. Obtain a core file from a binary in package foo
2. Move that core file to another (RHEL6) machine which does not have package foo installed.
3. Attempt gdb -c core on the new machine.  This will give a message something like:

Missing separate debuginfo for 
Try: yum --disablerepo='*' --enablerepo='*-debug*' install /usr/lib/debug/.build-id/d6/c129cc385340a2e2c512f3c6c189704197e3ab

4. Run the suggested command, which will install a -debuginfo package, but *not* the corresponding package containing the actual binary.  Or, install the package binary but in a different version (i.e. build-id) from the debuginfo.

5. Attempt gdb -c core again.  This will now give a message something like:

Missing separate debuginfo for 
Try: yum --disablerepo='*' --enablerepo='*-debug*' install /usr/lib/debug/.build-id/d6/c129cc385340a2e2c512f3c6c189704197e3ab.1

(Same as previous message but with added ".1")

6. The suggested command will not help.

Additional info:

After step (4) above, /usr/lib/debug/.build-id/d6/c129cc385340a2e2c512f3c6c189704197e3ab exists as a broken link.  gdb correctly looks for this file based on the build-id in the core.  It appears to lstat() this file, then readlink() it, and attempt to open the target.  When this fails, it unhelpfully falls back to the adding the ".1" to the build-id based location.