[kernel] Thread Control Block (TCB) and Process control block(PCB)

Reference:

https://en.wikipedia.org/wiki/Process_control_block

https://en.wikipedia.org/wiki/Thread_control_block

https://en.wikipedia.org/wiki/X86_memory_segmentation

https://en.wikipedia.org/wiki/Protection_ring

A Deep dive into (implicit) Thread Local Storage: https://chao-tic.github.io/blog/2018/12/25/tls

[split stack] reading notes and references: https://vsdmars.blogspot.com/2019/01/split-stack-reading-notes-and-references.html

TCB(Thread control block) or TLS(Thread Local Storage) setup is done somewhat differently for statically linked executables and dynamically linked executables.

dynamically linked executables

TLS is initialised differently for the main thread and the other threads that begin later in the execution.

When it comes to dynamically linked ELF programs, it’s useful to know that once they are loaded and mapped into memory, the kernel would then take its hands off and pass the execution baton to the dynamic linker (ld.so on Linux).

The main thread’s TLS is setup in the function init_tls, which calls _dl_allocate_tls_storage to allocate the TCB or struct pthread, eventually invokes the aforementioned macro TLS_INIT_TP to bind the pthread TCB to the main thread.

A module in glibc can refer to either an executable or a dynamically shared object, a module ID therefore is an index number for a loaded ELF object in a process.

Note that for a given running process the module ID for the main executable will always be 1, whereas the shared objects don’t know their module IDs until they are loaded and assigned by the linker.

Dynamically-loaded modules here don’t mean any dynamic shared objects, they only refer to the shared objects that are loaded by explicitly calling dlopen.