bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/19623] New: regression: missing relocation for symbols in discar


From: address@hidden
Subject: [Bug ld/19623] New: regression: missing relocation for symbols in discarded section
Date: Fri, 12 Feb 2016 13:08:55 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=19623

            Bug ID: 19623
           Summary: regression: missing relocation for symbols in
                    discarded section
           Product: binutils
           Version: 2.27 (HEAD)
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: address@hidden
  Target Milestone: ---

Created attachment 8981
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8981&action=edit
Patch that reverts 3a062fa1eeee8296dece36a9bb7ecc8d4500de18

Hi,

my target is i586-pc-sco3.2v4.2 and I recently upgraded binutils in Debian from
version 2.25 to 2.26. After that my SCO binaries would crash when I executed
them. I discovered that the reallocation of symbol addresses did not work
anymore. I bisected the issue the following commit:
3a062fa1eeee8296dece36a9bb7ecc8d4500de18

For my setup I am just reverting it (which is ironic since the commit itself is
a revert). From my limited understanding of the code at hand it seems to me
that
a) "sec->output_section->vma == 0" might be convered in the discarded_section
macro
b) the call to _bfd_clear_contents seems to be undesirable in my SCO scenario

Unfortunately I cannot provide you with the object files I am linking because
they are proprietary but If you are really need a test case, I might be able to
to program a minimal test case which reflects my problem. However I have not
created such a test case yet.

My linking setup looks like this:
I have a lot of object files, including an object with asm like this:

00006af4 <foo_patch>:                                                           
    6af4:       8b 4d 08                mov    0x8(%ebp),%ecx                   
    6af7:       8b 09                   mov    (%ecx),%ecx                      
    6af9:       03 01                   add    (%ecx),%eax                      
    6afb:       83 f8 ff                cmp    $0xffffffff,%eax                 
    6afe:       0f 84 39 e3 ff ff       je     4e3d <foo+0x15a>                 
    6b04:       e9 c5 e2 ff ff          jmp    4dce <foo+0xeb>                  
    6b09:       90                      nop                                     
    6b0a:       90                      nop                                     
    6b0b:       90                      nop                                     

00006b0c <bar_patch>:                                                           
    6b0c:       8b 45 fc                mov    -0x4(%ebp),%eax                  
    6b0f:       83 f8 00                cmp    $0x0,%eax                        
    6b12:       0f 8c 05 b9 ff ff       jl     241d <bar+0x403>                 
    6b18:       8b 45 f0                mov    -0x10(%ebp),%eax                 
    6b1b:       2b 45 fc                sub    -0x4(%ebp),%eax                  
    6b1e:       e9 e8 b8 ff ff          jmp    240b <bar+0x3f1>

After the linking the result looks like this:

00010e74 <foo_patch>:                                                           
   10e74:       8b 4d 08                mov    0x8(%ebp),%ecx                   
   10e77:       8b 09                   mov    (%ecx),%ecx                      
   10e79:       03 01                   add    (%ecx),%eax                      
   10e7b:       83 f8 ff                cmp    $0xffffffff,%eax                 
   10e7e:       0f 84 39 e3 ff ff       je     f1bd <foo+0x15a>                 
   10e84:       e9 c5 e2 ff ff          jmp    f14e <foo+0xeb>                  
   10e89:       90                      nop                                     
   10e8a:       90                      nop                                     
   10e8b:       90                      nop                                     

00010e8c <bar_patch>:                                                           
   10e8c:       8b 45 fc                mov    -0x4(%ebp),%eax                  
   10e8f:       83 f8 00                cmp    $0x0,%eax                        
   10e92:       0f 8c 85 15 ff ff       jl     241d <fail+0x45b>                
   10e98:       8b 45 f0                mov    -0x10(%ebp),%eax                 
   10e9b:       2b 45 fc                sub    -0x4(%ebp),%eax                  
   10e9e:       e9 68 15 ff ff          jmp    240b <fail+0x449> 

Note that all the jump addresses stayed the same. Fortunately for "foo_patch",
the relative offset is still accurate. However "bar_patch" now points to "fail"
instead of "bar", probably because the function changed its position because of
other objects linked in.

I attach my trivial revert of the commit (which makes my setup work again).

Regards,
Leon

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]