[windenntw]

excellent, thanks!

so the traced calls would more or less be:

https://sources.debian.org/src/glibc/2.33-3/sysdeps/m68k/tls...

https://sources.debian.org/src/glibc/2.33-3/sysdeps/unix/sys...

Maybe it is all related to errno needing to read the base TLS pointer? https://sources.debian.org/src/linux/5.15.15-1/arch/m68k/ker...

Sounds like we'd benefit from placing the result of calling sys_get_thread_area(void) in the VDSO area and updating it from http://lxr.linux.no/linux+v5.14/arch/m68k/include/asm/entry.... every time we do a process switch

[jagrsw]

> Maybe it is all related to errno needing to read the base TLS pointer?

Probably everything that uses __thread requires this. e.g. malloc(), or some functions that return pointers to static buffers, and implementators wanted to make them multi-thread safe.

  /*
     The interface of this function is completely stupid,
     it requires a static buffer.  We relax this a bit in 
     that we allow one buffer for each thread.
  */
  static __thread char buffer[18];

  char * inet_ntoa (struct in_addr in)
  {
    unsigned char *bytes = (unsigned char *) ∈
    __snprintf (buffer, sizeof (buffer), "%d.%d.%d.%d",
                bytes[0], bytes[1], bytes[2], bytes[3]);
    return buffer;
  }

[jagrsw]

Well.. I just noticed that implementation of inet_ntoa in glibc is a bit suspect. Using %d with char, without typecasting to (int) or using %hhd is tricky, and depending on memory alignment rules, and on whether arguments are passed in registers on on the stack this can produce incorrect results.

This is because arguments from the stack can be taken as ints (typically in batches of 4 octects), and put there as char (1 octet typically, but alignment might force it to be aligned to 4 bytes, I guess it depends). Interesting.