Constructor Order

Constructor Order

[David F.]

So I'm back from years ago trying to work out the constructor order.
It doesn't seem any change I make causes autogen.c to change the order
to what I want to happen.  At least if someone could indicate which
file I need to use to check the order, that would help.  I presume
it's the .inf file of items being built in the [libraryclasses]
section ?

I don't think [Packages] should matter?

TIA!!

Re: Constructor Order

[Kinney, Michael D]

David,

Constructor order is determined by the build tool through evaluation of each of the library instance dependencies as declared in the [LibraryClasses] section of the INF.  This is a recursive algorithm to collect all the library instances because a module uses libs and each lib can use additional libs.

This process is described in the EDK II Build Specification in Section 8.2.5 Post processing.

https://edk2-docs.gitbooks.io/edk-ii-build-specification/content/8_pre-build_autogen_stage/82_auto-generation_process.html#82-auto-generation-process

If you want a different order, then likely one or more of the lib instances being linked to a module does not have correct information about its lib dependencies in the [LibraryClasses] section of the INF.  If the dependencies are specified correctly, then the order generated by the build tool should be a valid order based on dependencies.  There are some cases where there could be ties, such that the order could be different and still correct, but there is no way to influence the order between ties.

Mike

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of David F.
Sent: Thursday, June 22, 2017 3:05 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Constructor Order

So I'm back from years ago trying to work out the constructor order.
It doesn't seem any change I make causes autogen.c to change the order to what I want to happen.  At least if someone could indicate which file I need to use to check the order, that would help.  I presume it's the .inf file of items being built in the [libraryclasses] section ?

I don't think [Packages] should matter?

TIA!!
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: Constructor Order

[Ard Biesheuvel]

On 23 June 2017 at 02:59, Kinney, Michael D <michael.d.kinney@intel.com> wrote:
> David,
>
> Constructor order is determined by the build tool through evaluation of each of the library instance dependencies as declared in the [LibraryClasses] section of the INF.  This is a recursive algorithm to collect all the library instances because a module uses libs and each lib can use additional libs.
>
> This process is described in the EDK II Build Specification in Section 8.2.5 Post processing.
>
> https://edk2-docs.gitbooks.io/edk-ii-build-specification/content/8_pre-build_autogen_stage/82_auto-generation_process.html#82-auto-generation-process
>
> If you want a different order, then likely one or more of the lib instances being linked to a module does not have correct information about its lib dependencies in the [LibraryClasses] section of the INF.  If the dependencies are specified correctly, then the order generated by the build tool should be a valid order based on dependencies.  There are some cases where there could be ties, such that the order could be different and still correct, but there is no way to influence the order between ties.
>

Note that constructor dependencies don't apply transitively if an
intermediate library in the dependency chain has no constructor. For
example, if LibWithConstructorA depends on LibWithoutConstructorB, and
the latter depends on LibWithConstructorC, the EDK2 tools don't
guarantee that C's constructor has executed when A's constructor is
invoked.

I think this is a flaw in the implementation, but fixing this results
in circular dependencies in many platforms that I have tried. so the
best way to deal with this IMO is not to rely on constructor ordering
at all, and which means you shouldn't call other libraries from the
constructor of a library.

-- 
Ard.