bug-binutils
[Top][All Lists]
Advanced

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

RE: Odd ld behaviour starting at version 2.22


From: Douglas Graham
Subject: RE: Odd ld behaviour starting at version 2.22
Date: Mon, 3 Nov 2014 20:34:20 +0000

Thanks.  That got me pointed in the right direction.

The problem does appear to be in the linker script, and I'm fairly sure that it 
is related to the initialization order of
static constructors and/or destructors.

The 2.22 linker script does this:

  .init_array     :
  {
    KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*) 
SORT_BY_INIT_PRIORITY(.ctors.*)))
    KEEP (*(.init_array))
    KEEP (*(EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) 
.ctors))
  }
  .fini_array     :
  {
    KEEP (*(SORT_BY_INIT_PRIORITY(.fini_array.*) 
SORT_BY_INIT_PRIORITY(.dtors.*)))
    KEEP (*(.fini_array))
    KEEP (*(EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) 
.dtors))
  }

And this breaks our library.  If I change that to do what the 2.21.1 linker 
script did, while still using the 2.22 linker:

  .init_array     :
  {
    KEEP (*(SORT(.init_array.*)))
    KEEP (*(.init_array))
  }
  .fini_array     :
  {
    KEEP (*(SORT(.fini_array.*)))
    KEEP (*(.fini_array))
  }

it works.  I can't make the opposite change (use SORT_BY_INIT_PRIORITY with the 
2.21.1 linker) because I get a syntax error,
presumably because SORT_BY_INIT_PRIORITY is a new feature.

It's not clear to me yet how the order has changed, or why the order actually 
matters for this particular library.

Am I confused about what's actually in the .init_array and .fini_array 
sections?  There is also .ctors and .dtors
which I thought contains the static  ctors and dtors.

Thanks,
Doug

-----Original Message-----
From: Nicholas Clifton [mailto:address@hidden 
Sent: November-03-14 7:14 AM
To: Douglas Graham; address@hidden
Subject: Re: Odd ld behaviour starting at version 2.22

Hi Doug,

> I'm not actually sure that this is a linker bug, but it sure looks 
> like one.  Version 2.21.1a of ld works fine, but starting at version
> 2.22 and up to 2.24, we are seeing some odd behaviour that is hard to 
> pin down.

If you have a look at the ld/NEWS file in the sources you can see what changed 
with the introduction of release 2.22.  One item stands out:

   * --copy-dt-needed-entries is no longer enabled by default.  Instead
     --no-copy-dt-needed-entries is the default.

Maybe if you try adding -Wl,--copy-dt-needed-entries to your g++ command line 
you will get a different behaviour ?  (Just a guess, but worth a try).


> All versions of the linker were built and run on a x86_64
> RHEL 6.4 system specifying only --prefix to configure. The symptoms vary,

Are all the symptoms related to startup/shutdown code ?  If so then the 
problem could be related to the linker script used to combine all the 
object files and libraries together.  How about linking with the 2.21 
linker script but using the 2.24 linker ?


Just a couple of ideas.

Cheers
   Nick




reply via email to

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