------- Additional Comments From ejt at andrew dot cmu dot edu 2007-05-23
08:19 -------
Ah, but unfortunately Mr. Earnshaw was arguing up the wrong tree there. Just
because we understand
why the current implementation is producing the results we see, doesn't mean
the current
implementation is *correct*.
As he says, the standard specifies how to handle sections in individual object
files. This defines the
expected behavior. However, the linker is not providing the expected behavior
when the files happen
to be in an archive, therefore it is breaking the spec in that case. It
doesn't matter that the spec doesn't
say anything about archive formats, because it doesn't need to. If I invent
some new container format,
and it breaks exception handling on any code stored within it, then it's
breaking the spec by
malforming handling of stuff that *is* covered by the spec.
If you want to claim to support C++ code, then you don't have carte blanche to
give whatever random
behavior you feel like -- the spec defines how code is supposed to be handled,
and it's currently not
happening.
Correct me if I'm wrong, but the archive format is intended to speed up linking
and simplify
distribution, *not change the behavior of code which results*. If the linker
can strip/leave out unused
code from an archive, that's a nice optimization, but if this causes a change
in runtime results, then
obviously that code wasn't unused after all, and was incorrect to leave it out!
I still don't see an explanation why you won't consider changing this incorrect
behavior. I read some
performance concerns of questionable validity, and perhaps an issue with
breaking existing code
(apparently relying on *not* being run?!?). Both of these can be resolved by
using either of the options I
suggested above. Option A would probably be somewhat more difficult to
implement, perhaps
requiring a new section to be emitted by gcc, but I would expect Option B would
be quite
straightforward -- just a lighter version of --whole_archive, and it would
allow those of us who want to
use this language feature to do so without affecting anything else.
Finally, I'll point out this isn't just a C++ issue. I've also tried using
__attribute__((constructor)) on a
function in C, and it has the same issues as these C++ initialization woes.
You may consider the
current status quo the pinnacle definition of 'what's expected', but I have a
feeling library writers would
like a way for constructor/initialization functions to be called reliably
regardless of whether a symbol in
the translation unit of that init code happens to be referenced. That
requirement is neither intuitive nor
consistent nor spec conformant.
I'm not expecting this to be fixed overnight, but it's never going to be
corrected if you stick by the "it's
not a bug" line and refuse to leave this open for future consideration.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |
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.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
