Bug 493969

Summary: elf files on sparc (and almost certainly ppc) have odd data_start symbols
Product: [Fedora] Fedora Reporter: Tom "spot" Callaway <tcallawa>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: dennis, drepper, jakub
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-18 08:46:18 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:
Bug Depends On:    
Bug Blocks: 491163    
Attachments:
Description Flags
Fix for data_start issues on sparc (and ppc) none

Description Tom "spot" Callaway 2009-04-03 14:38:34 UTC 
In Fedora 9, 10, and rawhide, glibc started including data_start (and __data_start) symbols in ELF binaries. This caused elfutils to fail two tests in its suite:

section [36] '.symtab': symbol 74: st_value out of bounds
section [36] '.symtab': symbol 93: st_value out of bounds
*** failure in ../src/addr2line
FAIL: run-elflint-self.sh

In troubleshooting this with David Miller, he noticed that for most architectures, the data_start definition in $arch/elf/start.S has a .long 0, but for sparc32/sparc64 (and ppc) it doesn't.

I made a patch to add these for sparc32/sparc64, rebuilt glibc, and elfutils then passes all of its tests.

Is this patch correct? If so, please take it upstream. We'd also need it applied to F-9, F-10, and rawhide branches (although, I can handle that if you'd prefer it be added as a patch).
Comment 1 Tom "spot" Callaway 2009-04-03 14:40:42 UTC 
Created attachment 338052 [details]
Fix for data_start issues on sparc (and ppc)
Comment 2 Tom "spot" Callaway 2009-04-03 14:51:23 UTC 
*** Bug 491163 has been marked as a duplicate of this bug. ***
Comment 3 Tom "spot" Callaway 2009-04-03 15:43:41 UTC 
There are more details in 491163, but I closed it as a dupe because this patch fixes that issue.
Comment 4 Jakub Jelinek 2009-04-10 13:50:19 UTC 
Working around this by forcing a non-empty .data section on every executable is very ugly, but then when x86_64 and i386 do this already, avoiding it at all costs just for sparc* and ppc* isn't worth it.  So I guess I can live with the patch.  Uli, is it ok for you too?  Who should be mentioned in ChangeLog entry for the patch?  spot or davem?
Comment 5 Ulrich Drepper 2009-04-10 15:41:56 UTC 
(In reply to comment #4)
> Uli, is it ok for you too? 

Sure, why not.  It's not that I care much of either architecture.
Comment 6 Tom "spot" Callaway 2009-04-10 21:46:10 UTC 
(In reply to comment #4)
> Working around this by forcing a non-empty .data section on every executable is
> very ugly, but then when x86_64 and i386 do this already, avoiding it at all
> costs just for sparc* and ppc* isn't worth it.  So I guess I can live with the
> patch.  Uli, is it ok for you too?  Who should be mentioned in ChangeLog entry
> for the patch?  spot or davem?  

DaveM had the idea, but I made the patch and tested it. Can you give us both credit? :) If not, just give it to Dave.
Comment 7 Ulrich Drepper 2009-04-18 08:46:18 UTC 
The rawhide glibc should have this changed.