606137 - Reorder .ctors on Linux

Status: RESOLVED WORKSFORME

(Firefox Build System :: General, defect)

Description

[Mike Hommey [:glandium]]

Attachment: PoC program to revert .ctors order

See the URL for more background.

Short version: on Linux, builds include a .ctors section containing pointers to static initialization functions. Its content is sorted by ascending address, but the init function gcc adds to run these static initializers parses the .ctors section backwards, leading to backwards I/O, which are known to be less efficient than forward I/O.

I'm attaching here a proof of concept program that hacks an ELF binary to revert .ctors order (which, on platforms using RELA relocations, also needs RELA changes)

Running this program on libxul.so and other libraries at build time could be considered.

This builds with the following command line:
gcc -o ctors ctors.c -lelf

Comment 1

[Mike Hommey [:glandium]]

Comment on attachment 484995 [details]
PoC program to revert .ctors order

Please note that the //TODO line at the beginning of the file is wrong. Relocations are handled.

Comment 2

[Mike Hommey [:glandium]]

For the record, I figured some ELF ABIs (at the very least the arm EABI) doesn't use a .ctors section, but a .init_array section, which is not handled by the same gcc generated code, but by ld.so, and ld.so loads them in the proper order.

Comment 3

[Mike Hommey [:glandium]]

I will reimplement this in elfhack.

Comment 4

[Zack Weinberg (:zwol)]

Why can't we just get this fixed in gcc, rather than inventing our own postprocessor?

Comment 5

[(dormant account)]

(In reply to comment #4)
> Why can't we just get this fixed in gcc, rather than inventing our own
> postprocessor?

As an-ex gcc dev you should know that fixes like this can not be accomplished in under 20years(we are 10 years in)</sarcasm>

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

Comment 6

[Mike Hommey [:glandium]]

... and buildbots are still using 4.3 at the moment.

Comment 7

[Zack Weinberg (:zwol)]

Thanks for finding that bug report.  The change we want seems to have gotten tangled up with another change (switching from .ctors to .init_array, which AFAICT is unrelated except insofar as .init_array has always run forwards), and both of them have run afoul of H.J., who has trouble communicating with people.

Mike is excellent at communicating with people; if he took the lead on that bug I see no reason why it could not be resolved in a week or two.

Comment 8

[Mike Hommey [:glandium]]

(In reply to comment #7)
> Thanks for finding that bug report.  The change we want seems to have gotten
> tangled up with another change (switching from .ctors to .init_array, which
> AFAICT is unrelated except insofar as .init_array has always run forwards), and
> both of them have run afoul of H.J., who has trouble communicating with people.

FWIW, IIRC, I filed that bug with the intent to replace .ctors with .init_array with the known side effect of effectively reversing the order of static initializers after I talked with some gcc devs on irc and they said they wouldn't reverse .ctors. Don't remember the reason invoked at the time.

Comment 9

[ariasuni]

The above GCC bug report is tagged RESOLVED FIXED, is this bug report still relevant?

Comment 10

[Mike Hommey [:glandium]]

Yeah, the gcc bug was fixed in 4.6, and we've required to build with 4.8 for a while now (and 4.9 now)