Bug 218471
Summary: | unresolved symbols for libs prelinked && debuginfo installed | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Jan Kratochvil <jan.kratochvil> |
Component: | gdb | Assignee: | Jan Kratochvil <jan.kratochvil> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 5.0 | CC: | aoliva, cagney, jakub, jan.kratochvil, jlaska |
Target Milestone: | --- | Keywords: | Patch, Regression |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | RC | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-02-08 01:20:50 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Attachments: |
Description
Jan Kratochvil
2006-12-05 16:33:52 UTC
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. |