Bug 218471 - unresolved symbols for libs prelinked && debuginfo installed
unresolved symbols for libs prelinked && debuginfo installed
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gdb (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jan Kratochvil
David Lawrence
: Patch, Regression
: 215197 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-05 11:33 EST by Jan Kratochvil
Modified: 2007-11-30 17:07 EST (History)
5 users (show)

See Also:
Fixed In Version: RC
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-07 20:20:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Assumed related eu-strip(1) change by Bug 203000 (6.64 KB, patch)
2006-12-07 02:36 EST, Jan Kratochvil
no flags Details | Diff
Testcase modified from gdb's testsuite referenced in Comment 5 above (818 bytes, application/octet-stream)
2006-12-07 02:38 EST, Jan Kratochvil
no flags Details
Upstream flexible matching_bfd_sections() function - prerequisited. (6.76 KB, patch)
2006-12-09 12:14 EST, Jan Kratochvil
no flags Details | Diff

  None (edit)
Description Jan Kratochvil 2006-12-05 11:33:52 EST
Description of problem:
.so.debug files are not prelinked to the same address as their .so counterparts.
If no -debuginfo is installed everything is fine.
After you install -debuginfo symbols from those .so files stop to be resolved.

Other possibility would be to let `prelink' also update the .debug files.

Did not check why the .so files symbols are discarded in the favor of the .debug
ones.

On RHEL-4 the problem was not present, not investigated why.

Version-Release number of selected component (if applicable):
gdb-6.5-15.el5.i386

How reproducible:
Always.

Steps to Reproduce:
0. yum -y install glibc-debuginfo
1. Take small.c of Bug 211744 Attachment 139061 [details].
2. gcc -o small small.c -ggdb3
3. gdb ./small
4. run
5. bt

Actual results:
default (echo 1 >/proc/sys/kernel/vdso):
#0  0x00e01402 in __kernel_vsyscall ()
#1  0x005da036 in ?? () from /lib/libc.so.6
#2  0x0804845f in handle_alrm (signo=14) at small.c:9
#3  <signal handler called>
#4  0x00e01402 in __kernel_vsyscall ()
#5  0x0063e806 in ?? () from /lib/libc.so.6
#6  0x080484b9 in main () at small.c:17

echo 0 >/proc/sys/kernel/vdso :
#0  0x005947f2 in ?? () at rtld.c:782 from /lib/ld-linux.so.2
#1  0x005da036 in ?? () from /lib/libc.so.6
#2  0x0804845f in handle_alrm (signo=14) at small.c:9
#3  <signal handler called>
#4  0x005947f2 in ?? () at rtld.c:782 from /lib/ld-linux.so.2
#5  0x0063e806 in ?? () from /lib/libc.so.6
#6  0x080484b9 in main () at small.c:17

Expected results:
default (echo 1 >/proc/sys/kernel/vdso):
#0  0x0013f402 in __kernel_vsyscall ()
#1  0x005da036 in kill () from /lib/libc.so.6
#2  0x0804845f in handle_alrm (signo=14) at small.c:9
#3  <signal handler called>
#4  0x0013f402 in __kernel_vsyscall ()
#5  0x0063e806 in __pause_nocancel () from /lib/libc.so.6
#6  0x080484b9 in main () at small.c:17

echo 0 >/proc/sys/kernel/vdso :
#0  0x005947f2 in _dl_sysinfo_int80 () at rtld.c:782
#1  0x005da036 in kill () from /lib/libc.so.6
#2  0x0804845f in handle_alrm (signo=14) at small.c:9
#3  <signal handler called>
#4  0x005947f2 in _dl_sysinfo_int80 () at rtld.c:782
#5  0x0063e806 in __pause_nocancel () from /lib/libc.so.6
#6  0x080484b9 in main () at small.c:17

(these were produced by gdb-6.5-18.fc7.i386)

Additional info:
Patch in RawHide fixing this issue:
* Sat Nov  2 2006 Jan Kratochvil <jan.kratochvil@redhat.com> - 6.5-14
- Fix "??" resolving of symbols from (non-prelinked) debuginfo packages.

Patch posted upstream (no response, people do not use prelink?):
http://sources.redhat.com/ml/gdb-patches/2006-10/msg00305.html
Comment 1 RHEL Product and Program Management 2006-12-05 12:30:57 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 2 Jan Kratochvil 2006-12-05 15:58:48 EST
Have been told `blocker' should be enough even after Friday the 1st deadline as
it is RHEL4 regression.
Comment 3 Andrew Cagney 2006-12-05 16:14:23 EST
Regression in existing functionality when compared to RHEL 4 - backtrace of
running process broken.   Fix has been in rawhide for 1 months.

Testcase being added.
Comment 4 Andrew Cagney 2006-12-05 16:15:20 EST
(oops missed dev+)
Regression in existing functionality when compared to RHEL 4 - backtrace of
running process broken.   Fix has been in rawhide for 1 months.
Comment 5 Jan Kratochvil 2006-12-07 02:36:39 EST
Created attachment 143038 [details]
Assumed related eu-strip(1) change by Bug 203000

If it would get checked by Jakub:

[i386, others not checked]
glibc is currently using `-g' option for eu-strip(1) unlike standard
`/usr/lib/rpm/find-debuginfo.sh' RPM packaging.
If this option is used the resuling .so.debug files contain:
  [78] .symtab		 NOBITS 	 00000000 538410 01f8f0 10     79 5853 
4
  [79] .strtab		 NOBITS 	 00000000 538410 018961 00	0   0 
1
Using `elfutils-0.124-1.el5.i386' - patched after Bug 203000.
I believed it should no longer stip .symtab/.strtab from .so.debug binaries
after the Bug 203000 CLOSE but it still happens for libc.
This .symtab/.strtab stripping can be reproduced for other libraries but the
resuling binaries do not cause any problems to gdb's backtracing (tried also
existing readline(3)):
gcc -fPIC -ggdb3 -Wall -nostdlib -o gdb.base/prelink.so
-fasynchronous-unwind-tables -shared gdb.base/prelink-lib.c
gcc -nostdlib -o gdb.base/prelinkt gdb.base/prelink.c -ggdb3
gdb.base/prelink.so
cp -p gdb.base/prelink.so gdb.base/prelink.so-orig
eu-strip -g -f gdb.base/prelink.so.debug gdb.base/prelink.so
prelink -v -fNR -c /dev/null -C /dev/null gdb.base/prelink.so gdb.base/prelinkt

# -nostdlib and -c /dev/null + -C /dev/null used to avoid failing prelinking
# /lib/libc* due to permissions.
gdb ./gdb.base/prelinkt
run
bt
#1  0x006cd1db in g (p=0) at gdb.base/prelink-lib.c:23
#2  0x006cd1fa in f (p=0) at gdb.base/prelink-lib.c:28
# while there would be only "??" in the libc case.

I did not precisely analyse the symbols resolving logic in gdb why it succeeds
in the `gdb.base/prelink' case above and as the patch above looks correct to me
and suggested by Roland yesterday (flexibility on the prelinked .so vs. its
.so.debug) I hope it can go to RHEL5.

It looks to me `eu-strip -g' stripping of .symtab/.strtab sections may be the
cause causing libbfd/gdb incompatiblity but this also was not verified.
[sorry but mostly PTO today]
Comment 6 Jan Kratochvil 2006-12-07 02:38:06 EST
Created attachment 143039 [details]
Testcase modified from gdb's testsuite referenced in Comment 5 above
Comment 7 Jan Kratochvil 2006-12-08 14:29:25 EST
qa_ack: Manual testcase above.

Automated testcase not provided as I did not found in a reasonable time a shared
library build usable for reproducibility of this Bug. Any custom library built
does not need the patch above. I did not analyse why does it work with gdb(1).

yum install glibc-debuginfo
# Check if /lib/libc.so.6 is already prelinked
if [ `readelf 2>/dev/null -S /lib/libc.so.6 /usr/lib/debug/lib/libc.so.6.debug
|awk '/[.]text/{print $4}'|uniq|wc -l` = 2 ];then echo TESTABLE - PRELINKED;else
echo UNTESTABLE - NOT PRELINKED;fi
# Otherwise:
yum install prelink
/etc/cron.daily/prelink

Later try gdb(1) `backtrace' of any binary if it shows the functions in libc,
you may follow `Steps to Reproduce' above.
Comment 8 Jan Kratochvil 2006-12-09 12:14:03 EST
Created attachment 143219 [details]
Upstream flexible matching_bfd_sections() function - prerequisited.

I forgot before this patch needs a prerequisited backport from CVS upstream,
attaached here.

* Sat Nov  2 2006 Jan Kratochvil <jan.kratochvil@redhat.com> - 6.5-14
# Fix "??" resolving of symbols from (non-prelinked) debuginfo packages.
# "gdb-6.5-matching_bfd_sections.patch" is a prerequisited CVS backport.
Patch205: gdb-6.5-matching_bfd_sections.patch
Comment 9 Jan Kratochvil 2006-12-09 12:24:48 EST
*** Bug 215197 has been marked as a duplicate of this bug. ***
Comment 10 James Laska 2006-12-13 16:11:01 EST
jkratoch: can you describe the impact if we go to GA without this fix?  What is
lost, what will customers be unable to do?
Comment 11 Jan Kratochvil 2006-12-13 16:33:55 EST
jlaska:
Backtraces do not show some names of the glibc functions.
Other libraries besides glibc may be affected but it is not confirmed.

As (I believe) the most common use of gdb(1) is to get backtrace - even if the
user/customer is not using gdb as a programmer - and the backtrace names
resolving is limited by this bug it reduces the bugreports usability.

Bug present, customer's bugreport of a simple read(2)ing program shows:
(gdb) bt
#0  0x00d58402 in __kernel_vsyscall ()
#1  0x0097c853 in ?? () at ../stdlib/stdlib.h:342 from /lib/i686/nosegneg/libc.so.6
#2  0x08048386 in main () at /tmp/read.c:7

Bug fixed, customer's bugreport of a simple read(2)ing program shows:
(gdb) bt
#0  0x00d23402 in __kernel_vsyscall ()
#1  0x0097c853 in __read_nocancel () at ../stdlib/stdlib.h:342
#2  0x08048386 in main () at /tmp/read.c:7

Unfortunately just the address 0x0097c853 in the dump is not resolvable locally
as each system uses a different/random address due to prelink(8).

gstack(1) program (part of the gdb package) is also affected the same way.
On the other hand the equivalent fstack(1) (part of a frysk package) works fine.
Comment 12 Jay Turner 2006-12-13 22:19:58 EST
QE ack for RHEL5.
Comment 13 Jan Kratochvil 2006-12-14 14:21:14 EST
* Thu Dec 14 2006 Jan Kratochvil <jan.kratochvil@redhat.com> - 6.5-16
- Fix "??" resolving of symbols with debuginfo packages installed (BZ 218471).
Comment 14 RHEL Product and Program Management 2007-02-07 20:20:50 EST
A package has been built which should help the problem described in 
this bug report. This report is therefore being closed with a resolution 
of CURRENTRELEASE. You may reopen this bug report if the solution does 
not work for you.

Note You need to log in before you can comment on or make changes to this bug.