Linker ordering ... ?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Linker ordering ... ?

g4@novadsp.com
Not sure if this is the best list on which to ask. Please advise if there is
a better one.

There is something of a 'trick' played with nsmodule linkage in order to
ensure they get grouped correctly. During the course of my experiments I was
caught out when many of the component manager 'create' calls failed. In the
stock moz.build files, xul is specifically set up to have
staticxulXXXstart.obj as the first module and staticxulXXXend.obj as the
last in the linker command, which creates the correct result.

In staticXULComponentsStart.cpp we have this:

NSMODULE_DEFN(start_kPStaticModules) = nullptr;

which resolves to a section of kPStaticModules and a sort key of M.

If I've understood this correctly does it not make more sense to define
start_kPStaticModules as follows? Note critically that the $key value is now
A so it is first after the sort ...

------------snip-----------------
/* Sections on Windows are in two parts, separated with $. When linking,
* sections with the same first part are all grouped, and ordered
* alphabetically with the second part as sort key. */
#  pragma section(".kPStaticModules$A", read)
#  undef NSMODULE_SECTION
#  define NSMODULE_SECTION __declspec(allocate(".kPStaticModules$A"),
dllexport)
NSMODULE_DEFN(start_kPStaticModules) = nullptr;
------------snip-----------------

This (appears to) create the correct results in the .map when linked using
VS*.

TIA

Jerry.

https://gist.github.com/g40/cf79e483aa9052de90dd




_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|

Re: Linker ordering ... ?

Mike Hommey
On Mon, Mar 23, 2015 at 02:54:11PM -0000, [hidden email] wrote:

> Not sure if this is the best list on which to ask. Please advise if there is
> a better one.
>
> There is something of a 'trick' played with nsmodule linkage in order to
> ensure they get grouped correctly. During the course of my experiments I was
> caught out when many of the component manager 'create' calls failed. In the
> stock moz.build files, xul is specifically set up to have
> staticxulXXXstart.obj as the first module and staticxulXXXend.obj as the
> last in the linker command, which creates the correct result.
>
> In staticXULComponentsStart.cpp we have this:
>
> NSMODULE_DEFN(start_kPStaticModules) = nullptr;
>
> which resolves to a section of kPStaticModules and a sort key of M.
>
> If I've understood this correctly does it not make more sense to define
> start_kPStaticModules as follows? Note critically that the $key value is now
> A so it is first after the sort ...
>
> ------------snip-----------------
> /* Sections on Windows are in two parts, separated with $. When linking,
> * sections with the same first part are all grouped, and ordered
> * alphabetically with the second part as sort key. */
> #  pragma section(".kPStaticModules$A", read)
> #  undef NSMODULE_SECTION
> #  define NSMODULE_SECTION __declspec(allocate(".kPStaticModules$A"),
> dllexport)
> NSMODULE_DEFN(start_kPStaticModules) = nullptr;
> ------------snip-----------------
>
> This (appears to) create the correct results in the .map when linked using
> VS*.

The order needs to be ensured for non-Windows platforms, so it doesn't
really matter that the Windows build can be made to work without the
files being ordered.

Mike
_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds