Is there any way to determine a (multi) thread/task's stack address start in the virtual memory of a process on Linux?

Question

I know there potentially can be multiple different threading libraries that one use, but for this question I'm specifically thinking about POSIX pthreads.

Figuring out where the stack for the "process/main task/main thread/thread group leader" it's not all that difficult I think. Looking in the /proc/ filesystem one can guess where this stuff is for a particular task.

What I want to be able to do, is find out where pthread placed the stack for the newly created thread and if this is even possible to figure out? This functionality would be, for instance used in a debugger like GDB.

One can pass stack address and stack size to the pthread_create function, so obviously some control over where it's located in virtual memory is possible.

Is there possibly a way to write a kernel module that looks at stack addresses of a pid/tid and determine from there, where in virtual memory of the process, where it's located? The stack member variable of struct task_struct in the kernel, seems to point to the physical memory and not the virtual memory, which is what I'm actually interested in.

ptrace doesn't seem to have an API for this either, which is unfortunate (for me). From a debugger's perspective this could be interesting information.

Looking at the stack pointer of a task and "going backwards" until a memory mapping's start, certainly isn't a clean way to do it and I'm not sure if that's even 100% certain to be correct either.

I would greatly appreciate if anybody had any ideas or if this is even possible.

Answer 1

the question relates to situations where "we" are not "the program", ie in a debugger situation we are the tracer and inspecting the tracee.

You are probably looking for td_thr_get_info() from libthread_db , which (among other info) returns

  paddr            ti_stkbase;        /* base of thread's stack area*/
  int              ti_stksize;        /* size in bytes of thread's allocated
                                         stack region*/

PS Looking in /proc/$pid/maps is a possibility, but you wouldn't necessarily know which anonymous mappings "belong" to thread stacks.