Bug 493969 - elf files on sparc (and almost certainly ppc) have odd data_start symbols
Summary: elf files on sparc (and almost certainly ppc) have odd data_start symbols
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 491163 (view as bug list)
Depends On:
Blocks: 491163
TreeView+ depends on / blocked
 
Reported: 2009-04-03 14:38 UTC by Tom "spot" Callaway
Modified: 2009-04-18 08:46 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-04-18 08:46:18 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Fix for data_start issues on sparc (and ppc) (1.75 KB, patch)
2009-04-03 14:40 UTC, Tom "spot" Callaway
no flags Details | Diff

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.


Note You need to log in before you can comment on or make changes to this bug.