bug-binutils
[Top][All Lists]
Advanced

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

[Bug ld/4538] don't skip initializers with visible external side effects


From: cnmnzusoib at mailinator dot com
Subject: [Bug ld/4538] don't skip initializers with visible external side effects in static archives
Date: 9 Aug 2007 22:02:21 -0000

------- Additional Comments From cnmnzusoib at mailinator dot com  2007-08-09 
22:01 -------
> That is exactly the behaviour you get with --whole-archive.
Except that --whole-archive brings in *everything*.  Is there even a point to 
using the static archive at 
that point vs. doing an intermediate link to combine into a .o?  I'm actually 
kind of curious where 
whole-archive came from, as it seems like a quick hack to address this very 
problem...

What I'm driving at here is to find a way to get the benefit of faster links 
via static archive (by leaving 
unnecessary stuff out), without skipping initializers with side effects in 
translation units which *are* 
being used... (thus making those initializers implicitly referenced)

Ideally, only those with external side effects are needed, but I don't think 
that level of information is 
available to the linker...?

Assuming it isn't, you wind up importing anything with any kind of 
initialization section.  Still better 
than choosing between non-functional code or importing everything.  And it 
looks like it'll be pretty 
effective, and not bother system libraries.  Of the 94 .a files under /usr/lib 
on a fairly basic Ubuntu box, 
comprising 5581 object files, only 19 (a third of a percent!) had .ctor 
sections.  So even if it's not 
optimal, its much better than what we have now.

I'm still kind of hoping there's a more selective way to detect which units 
have a side effect in an 
already-used unit.  If this is something to take up with the compiler venders 
(i.e. emit a new section 
with the needed information) then so be it, at least then you can leave the 
ball in their court.

Also, there's also a side issue of awareness/documentation -- having a flag 
whose purpose is to make 
sure all the init sections are run raises awareness that some initialization 
routines might *not* be run if 
you don't use it.  Seeing as how I found quite a few threads where people have 
run into this problem, 
e.g.:
http://gcc.gnu.org/ml/gcc-bugs/2004-06/msg02196.html
http://cygwin.com/ml/cygwin/2007-02/msg00584.html
http://lists.apple.com/archives/xcode-users/2005/Aug/msg00786.html ("I don't 
think ld is smart 
enough")
http://www.physicsforums.com/archive/index.php/t-106619.html ("This doesn't 
work" and the thread 
never does seem to figure out what's going on)
http://ciaranm.org/show_post/13 ("evil and broken ", references --as-needed and 
DSO, but same 
issue)
http://mail.opensolaris.org/pipermail/dtrace-discuss/2005-August/000207.html 
("strangeness with 
respect to archives and .init processing")
...even just documentation would help avoid wasting people's time.  You should 
understand that when 
"the rest of us" write a static initializer, especially something explicit like 
__attribute__((constructor)), 
we do actually expect it to run, regardless of whether it's linked via an 
archive or not.  People don't 
expect using an archive vs. other formats to change their results.  I don't 
think they *should* expect 
that, not for something as basic and explicitly covered by the standards as 
"will the initializer be run?".  
It's clear in the above threads that even of the people who understand the 
problem, it's *not what even 
they ideally want it to do*.

> But note that the very popular operating systems Windows
> and Mac OS X are not ELF based.
True, OS X calls them __StaticInit and __constructor/__destructor sections and 
uses Mach-O, but either 
binutils already has code for parsing that or else it doesn't matter anyway... 
I don't know about 
Windows though, but it's entirely possible different platforms might need 
different solutions.  OS X's ld 
has -all_load instead of --whole-archive, for instance. (sigh)

-ethan

PS I'm switching the severity and summary back to a 'bug' since I still 
consider this a fixing a design 
flaw more than "enhancement".  Shouldn't matter to you since it's still closed 
anyway...

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |normal
            Summary|add --all-init flag to force|don't skip initializers with
                   |all static initializers to  |visible external side
                   |be loaded                   |effects in static archives


http://sourceware.org/bugzilla/show_bug.cgi?id=4538

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.




reply via email to

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