
Making our own executable packer, part 13, Thread-local storage - lukastyrychtr
https://fasterthanli.me/blog/2020/thread-local-storage/
======
elteto
Great article. I particularly enjoyed the “beyond the basics” use of gdb.

I know the basics just like anyone else whose done some light debugging with
gdb but it is hard to find information that goes beyond that. There’s a
gazillion of half-baked gdb introductions but IMO not enough advanced
tutorials.

------
platz
Would someone explain what the primary intent and current best-case usages of
thread-local storage are?

Is this more suited for certain languages than others?

~~~
cryptonector
It's super useful for many reasons:

    
    
      - to help make thread-unsafe APIs thread-safe
    
        E.g., errno, strtok(), and so on.
    
      - to store thread-private mutable globals
    
        (Thread-locals are more like thread-globals.)
    
      - to keep a reference/copy of global immutable
        data that might get replaced in the middle of
        a thread's handling of a request
    
      - to keep contextual data that you can't retrofit
        an API to pass explicitly (see also first item)

~~~
spacechild1
Pure Data made heavy use of thread local storage to turn the original
application singleton (with lots of globals) into a threadsafe and reentrant
library (libpd).

------
drudru11
Why is he making a packer?

~~~
chrisseaton
I don’t understand what a ‘packer’ is - is it a linker?

~~~
killercup
> I don’t understand what a ‘packer’ is

You've found the right series of articles then!

~~~
chrisseaton
I read it - I did't find an explanation of what it was that he was building,
just how he was building it.

~~~
saagarjha
Think of it of decompression software bundled along with a compressed version
of the program you actually want to run. So execution starts in the
uncompression part, it unzips all the code into memory, and then starts
running the program you actually cared about.

