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> - 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
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.
Have been told `blocker' should be enough even after Friday the 1st deadline as it is RHEL4 regression.
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.
(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.
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]
Created attachment 143039 [details] Testcase modified from gdb's testsuite referenced in Comment 5 above
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.
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> - 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
*** Bug 215197 has been marked as a duplicate of this bug. ***
jkratoch: can you describe the impact if we go to GA without this fix? What is lost, what will customers be unable to do?
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.
QE ack for RHEL5.
* Thu Dec 14 2006 Jan Kratochvil <jan.kratochvil> - 6.5-16 - Fix "??" resolving of symbols with debuginfo packages installed (BZ 218471).
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.