Description of problem: I found the PIE support in GDB broke debugging of some binaries. But I find GDB is IMHO correct and one should fix more prelink. As the sections ordering in stripped<->.debug file is different GDB matches their addresses by their name. Should be GDB hacked for a single global prelink file offset or would prelink make the section names+addresses matching in both files? Version-Release number of selected component (if applicable): prelink-0.4.3-3.fc13.x86_64 FAIL gdb-7.1-28.fc13.x86_64 PASS <= FSF GDB 7.0 FAIL >= FSF GDB 7.1 elfutils-0.148-1.fc13.x86_64 How reproducible: Always. Steps to Reproduce: (set -ex;echo 'int optind,v,*p=&v;main(){return optind;}'|gcc -o 1.built -g -x c -;eu-strip --remove-comment -o 1.strip -f 1.debug 1.built;cp 1.strip 1.strip.prelink;prelink -N 1.strip.prelink;echo OK) # That is create a conflict to force .dynbss section. readelf -a 1.strip.prelink + readelf -a 1.debug (gdb) p p (gdb) p &v Actual results: [25] .dynbss PROGBITS 0000000000600850 00000850 0000000000000004 0000000000000000 WA 0 0 8 [26] .bss PROGBITS 0000000000600854 00000854 000000000000001c 0000000000000000 WA 0 0 8 + [25] .bss NOBITS 0000000000600850 00000250 0000000000000020 0000000000000000 WA 0 0 8 $1 = (int *) 0x600868 $2 = (int *) 0x60086c Expected results: [25] .bss PROGBITS 0000000000600850 00000850 0000000000000020 0000000000000000 WA 0 0 8 + [25] .bss NOBITS 0000000000600850 00000250 0000000000000020 0000000000000000 WA 0 0 8 $1 = (int *) 0x600868 $2 = (int *) 0x600868 Additional info:
GDB gets loaded for the test above by: $ gdb -q -nx ./1.strip.prelink Reading symbols from .../1.strip.prelink...Reading symbols from .../1.debug...done. done.
Prelink doesn't shift any of the SHT_PROGBITS allocated sections (other than .interp), it can't do that even if it wanted - the text section or data sections likely contain addresses of .bss vars. What prelink does is split .bss section into .dynbss and .bss - .dynbss is the first part, which during prelinking becomes SHT_PROGBITS, because it needs to be now initialized from the file, while .bss is the rest. So, there isn't really anything to change on the prelink side here I'm afraid.
I see the conflicting symbols are already ordered first in the ".bss" section. Even before prelink ever sees the file. Do you approve this GDB fix plan? Prefer ".dynbss" over ".bss" when matching their vaddr. ".dynstr" currently also gets bogus shift but it does not contain inferior debugger-addressable objects. Therefore there exist no symbols located in the ".dynstr" section. GDB can ignore any bogus shifts of ".dynstr". Thanks for info.
Using now .dynbss address instead. http://sourceware.org/ml/gdb-patches/2010-07/msg00237.html
.dynstr isn't a SHT_PROGBITS/SHT_NOBITS section, nothing can contain addresses into that section, so it is fine for prelink to move it around as it wants. Similarly for many other sections. Currently, prelink freely moves around SHT_HASH, SHT_GNU_HASH, SHT_DYNSYM, SHT_REL, SHT_RELA, SHT_STRTAB, SHT_NOTE, SHT_GNU_verdef, SHT_GNU_verneed, SHT_GNU_versym and SHT_GNU_LIBLIST sections plus .interp (which is SHT_PROGBITS, but nothing can point at it). .bss may be split into .dynbss/.bss, .sbss may be split into .sdynbss/.sbss (in both cases it is to prelink COPY relocations).
gdb-7.1-29.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/gdb-7.1-29.fc13
gdb-7.0.1-49.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/gdb-7.0.1-49.fc12
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.