OSDev.org

The Place to Start for Operating System Developers
It is currently Mon Nov 11, 2019 7:13 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: Constructors, library order, and portability
PostPosted: Thu Jun 27, 2019 10:52 am 
Offline
Member
Member
User avatar

Joined: Sat Oct 16, 2010 3:38 pm
Posts: 644
I am designing a programming language which will involve having to run some static initializers. My compiler translates the code to C for easier portability.

GCC has a feature known as constructors available even in C via __attribute__ ((constructor)). My question is how this interacts with library load order and so on. If library A uses B (via DT_NEEDED), is it guaranteed that the constructors of B will run before the constructors of A?

And as such, does that mean if I have my standard library, libperun, run some constructors, will all libraries written in my language (linked against libperun!) have their constructors executed AFTER it? And if libperun is linked against libpthreads, can I call PThreads functions inside libperun constructors?

Furthermore, will this also hold when using this on Windows (via MinGW)?

Logically, it would seem that it should be this way, but I can't find where this is documented as a guarantee, and I don't want to accidentally invoke undefined behaviour.

NOTE: I do not care about supporting static libraries.

_________________
Glidix: architecture-independent OS (currently only implemented for x86_64), mostly implementing POSIX, but with a strong focus on making good APIs.
https://glidix.madd-games.org/

I am re-writing most of Glidix. Follow my progress here !


Top
 Profile  
 
 Post subject: Re: Constructors, library order, and portability
PostPosted: Thu Jun 27, 2019 11:41 am 
Offline
Member
Member

Joined: Wed Aug 30, 2017 8:24 am
Posts: 270
Officially, initializer order is undefined. Unofficially, initializers are run in a depth-first way (dependencies first), at least on glibc and musl. What happens on Windows is determined by the dynamic linker in use, which I don't know.

How about, instead of using __attribute__((constructor)) and DT_INIT or DT_INIT_ARRAY, you generate your own initializer list, establish whatever order on it, and run it first thing from your language runtime. That way, the C library will be fully initialized already, and you will be in full control of the process.


Top
 Profile  
 
 Post subject: Re: Constructors, library order, and portability
PostPosted: Thu Jun 27, 2019 11:50 am 
Offline
Member
Member
User avatar

Joined: Tue Mar 06, 2007 11:17 am
Posts: 1204
The core of libraries should have independent order.

It's the critical system functions you need that rely on each other to make things possible, and even then the cores are stand-alone. If you call stuff from other subsystems, the code must be clean/portable to make for stand-alone pieces with no particular order other than what you will be accessing in a logical, functional way.

-----------------------------------------------------------
For example if you need the disk you need the base system, user input, some data buffers, memory management at least with malloc/free, a sample partition with files, an unfragmented partition with at least 1 file to modify.

You can gradually add functions to those components in order as you see you need to "install" more functions for your system resources to function properly.

_________________
http://190.53.102.175/api (My OS compatible with DOS)

(udocproject@yahoo.com)
-----------------------------
IP for hosts file (all domains):
190.53.102.175 api.exe


Top
 Profile  
 
 Post subject: Re: Constructors, library order, and portability
PostPosted: Thu Jun 27, 2019 12:08 pm 
Offline
Member
Member
User avatar

Joined: Sat Oct 16, 2010 3:38 pm
Posts: 644
nullplan wrote:
Officially, initializer order is undefined. Unofficially, initializers are run in a depth-first way (dependencies first), at least on glibc and musl. What happens on Windows is determined by the dynamic linker in use, which I don't know.

How about, instead of using __attribute__((constructor)) and DT_INIT or DT_INIT_ARRAY, you generate your own initializer list, establish whatever order on it, and run it first thing from your language runtime. That way, the C library will be fully initialized already, and you will be in full control of the process.


This was the second plan but it's slightly more complex... how would I make it work with other libraries linked in?

I could generate such a list in every library (and executable), but someone has to call it. Do I just have to explicitly invoke every library initializer from main()? What about when loading libraries at runtime?

_________________
Glidix: architecture-independent OS (currently only implemented for x86_64), mostly implementing POSIX, but with a strong focus on making good APIs.
https://glidix.madd-games.org/

I am re-writing most of Glidix. Follow my progress here !


Top
 Profile  
 
 Post subject: Re: Constructors, library order, and portability
PostPosted: Thu Jun 27, 2019 3:46 pm 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 623
In the SysV ABI, initializers (DT_INIT and DT_INIT_ARRAY) in a library run in unspecified order (use the static initializer idiom or pthread_once() to order them). Initializers in different libraries, however, are specified to run in topological order. In other words, a lib is initialized after all of its dependencies are already initialized.

EDIT: Because you asked for a reference: section 5-22 ("Initialization and Termination functions") of the (incomplete) PDF version http://www.sco.com/developers/devspecs/gabi41.pdf of the SysV specification (the HTML version is more verbose in general).

_________________
managarm: Microkernel-based OS that is capable of running a Wayland desktop
My OS-dev projects: [mlibc: Portable C library for managarm, qword, Linux, Sigma, ...] [LAI: AML interpreter] [xbstrap: Build system for OS distributions]


Top
 Profile  
 
 Post subject: Re: Constructors, library order, and portability
PostPosted: Sat Jun 29, 2019 9:26 am 
Offline
Member
Member
User avatar

Joined: Tue Mar 06, 2007 11:17 am
Posts: 1204
Since it's a compiler tool you are making yourself, you can make it manually configurable in ways that match what you need for your own projects.

Test what works for you and for existing systems, and it will surely end up optimum.

_________________
http://190.53.102.175/api (My OS compatible with DOS)

(udocproject@yahoo.com)
-----------------------------
IP for hosts file (all domains):
190.53.102.175 api.exe


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group