This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Maintain order of LTO sections


> Well, I'm not sure we should jump through too much hoops to make
> -flto work with -fno-toplevel-reorder.  Simply because I think nothing
> defines any "toplevel order" for multiple object files.  So, I think

In practice it seems to work because real programs rely on it.

I can just say with this patch and Honza's my program works
(with -flto-partition=none), without it it doesn't.

Also as Honza pointed out it has other benefits, like making
compiles more reproducible. For example if you have a memory corruption
somewhere the random order currently will randomly move it from
run to run and make it harder to debug.

> both ld and gcc/collect2 need to first document they will never
> break toplevel order (what about ld with -ffunction-sections and
> -gc-sections? Or -relax?)

-ffunction-sections and -gc-sections do not reorder as far as I know.
Not sure about -relax.

But the programs that rely on order should "don't do it when it hurts"
so not set too magic options. I'm sure there are other creative ways to break
order too, but it doesn't seem to be too hard in practice to avoid
them.


-Andi


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]