Bug 461675 - Partial linking results in corrupt .eh_frame_hdr
Partial linking results in corrupt .eh_frame_hdr
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: binutils (Show other bugs)
9
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jan Kratochvil
Fedora Extras Quality Assurance
: Reopened
Depends On: 458950
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-09 15:56 EDT by Brad Settlemyer
Modified: 2009-02-04 21:16 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-04 21:11:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fix + testcase. (2.36 KB, patch)
2009-01-28 16:26 EST, Jan Kratochvil
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Sourceware 6893 None None None Never

  None (edit)
Description Brad Settlemyer 2008-09-09 15:56:08 EDT
Description of problem:
I use partial linking in my project.  No matter how I try to configure it, I seem to get a corrupt .eh_frame_hdr in the final (fully linked) executable.

Version-Release number of selected component (if applicable):


How reproducible:
Every Time.

Steps to Reproduce:
1.  ld -Ur --eh-frame-hdr $(RANDOM_CPP_OBJS) -o partial_obj.o 
2.  g++ -Wl,--export-dynamic $(MORE_OBJS) partial_obj.o -o final.exe
  
Actual results:
/usr/bin/ld: error in lib/partial_obj.o(.eh_frame); no .eh_frame_hdr table will be created.


Expected results:
n/t

Additional info:
The executable generated seems to work okay, though what happens on an actual excpetion is in doubt for me.
Comment 1 Jan Kratochvil 2008-09-16 10:11:40 EDT
Upstream post:
http://sourceware.org/ml/binutils/2008-09/msg00124.html
Comment 2 Jan Kratochvil 2008-09-16 10:12:38 EDT

*** This bug has been marked as a duplicate of bug 458950 ***
Comment 3 Brad Settlemyer 2009-01-27 10:28:06 EST
Please reopen this bug, it is not a duplicate of 458950 because that bug is fixed, and my problem still persists.  I will add a test case for reproducing the bug later.  That will take some time because the only system I've got that produces the bug is complicated, and I don't have an easy way to pare it down.
Comment 4 Jan Kratochvil 2009-01-27 10:44:55 EST
In fact some binary ball would be also useful as you write in your comment in Bug 458950 Comment 10.
Comment 5 Brad Settlemyer 2009-01-27 12:46:10 EST
Okay, here are the binaries in question, and a script that links the partial object, and then the final executable.  I realize we are well off into the woods on the linker features in use here.  I've never even seen .a's linked by anyone like that, but that is what the packagers of the libs I use did to me.

Here is a link:

http://www.parl.clemson.edu/~bradles/downloads/test_case.tar.gz

The download is 13MB, and it creates a single dedicated directory.  Nothing malicious in there, just a call to ld, followed by a call to g++.
Comment 6 Jan Kratochvil 2009-01-28 16:26:03 EST
Created attachment 330285 [details]
Fix + testcase.

My former patch was: http://sourceware.org/ml/binutils/2008-09/msg00124.html
Relaxed the check there with a comment:
+         /* For NULL RSEC (cleared FDE belonging to a discarded section)
+            the relocations are commonly cleared.  We do not sanity check if
+            all these relocations are cleared as (1) relocations to
+            .gcc_except_table will remain uncleared (they will get dropped
+            with the drop of this unused FDE) and (2) BFD already safely drops
+            relocations of any type to .eh_frame by
+            elf_section_ignore_discarded_relocs.
+            FIXME: The .gcc_except_table entries should be also filtered as
+            .eh_frame entries; moreover both could rather use COMDAT.  */

Fortunately the former patch had no regressions just its effect was incomplete.

Thanks for the bugreport, scratch build (-U --oldpackage, please) is at:
http://koji.fedoraproject.org/scratch/jkratoch/task_1089661/

After the multiarch regression tests going to post it upstream.
Comment 7 Jan Kratochvil 2009-01-31 06:04:25 EST
Post upstream with an updated testcase:
http://sourceware.org/ml/binutils/2009-01/msg00412.html
Comment 8 Fedora Update System 2009-02-04 21:11:09 EST
binutils-2.18.50.0.6-7.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 9 Fedora Update System 2009-02-04 21:16:12 EST
binutils-2.18.50.0.9-8.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

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