------- Comment #17 from steven at gcc dot gnu dot org  2010-04-29 11:39 -------
I've played a bit with modified .s files by hand, and as/ld work if the LTO
sections follow the other sections.

The normal order of output with -flto looks like this in the .s file:

LTO sections (the __GNU_LTO stuff)
.text / .data / etc. (all non-LTO sections)
LTO __section_names section

With this order I get the linker error.

I do *not* get the linker error if I re-order the .s file by hand to look like
this:

.text / .data / etc. (all non-LTO sections)
LTO sections (the __GNU_LTO stuff)
LTO __section_names section

With this order, the .s file looks identical with and without -flto, except for
the extra LTO sections after the non-LTO stuff of course. And with this order,
the linker doesn't give an error.

I don't understand this at all. It is almost as if the compiler somehow writes
an address relative to start-of-file, but the compiler doesn't know about
addresses (it can write labels and such, but not count bytes from
start-of-file).

Anyway, I did some research with Google and we are not the first to encounter
this problem. Apparently it doesn't happen in 32-bits mode, so I'll implement
that now and try that.

The important conclusion for me, is that the LTO patch is OK and the bug is
somewhere else :-)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729

Reply via email to