Bug 614659

Summary: prelink shifts .bss address by .dynbss breaking gdb
Product: [Fedora] Fedora Reporter: Jan Kratochvil <jan.kratochvil>
Component: gdbAssignee: Jan Kratochvil <jan.kratochvil>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: jakub, jan.kratochvil, pmuldoon, swagiaal
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 614806 (view as bug list) Environment:
Last Closed: 2010-12-03 13:15:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 614806, 614808    

Description Jan Kratochvil 2010-07-14 22:27:04 UTC
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):
FAIL gdb-7.1-28.fc13.x86_64

How reproducible:

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:

Comment 1 Jan Kratochvil 2010-07-14 22:29:19 UTC
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.

Comment 2 Jakub Jelinek 2010-07-14 22:39:14 UTC
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.

Comment 3 Jan Kratochvil 2010-07-14 22:51:42 UTC
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.

Comment 4 Jan Kratochvil 2010-07-15 09:57:18 UTC
Using now .dynbss address instead.

Comment 5 Jakub Jelinek 2010-07-15 10:03:57 UTC
.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).

Comment 6 Fedora Update System 2010-07-20 17:33:54 UTC
gdb-7.1-29.fc13 has been submitted as an update for Fedora 13.

Comment 7 Fedora Update System 2010-07-20 18:07:17 UTC
gdb-7.0.1-49.fc12 has been submitted as an update for Fedora 12.

Comment 8 Bug Zapper 2010-11-03 11:57:27 UTC
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: 

Comment 9 Bug Zapper 2010-12-03 13:15:04 UTC
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.