On Fri, Dec 09, 2022 at 02:38:49PM -0800, Stephen Hemminger wrote:
> On Fri, 09 Dec 2022 22:14:33 +0100
> Thomas Monjalon <tho...@monjalon.net> wrote:
>
> > 09/12/2022 17:48, Stephen Hemminger:
> > > On Fri, 09 Dec 2022 08:53:57 +0100
> > > Thomas Monjalon <tho...@monjalon.net> wrote:
> > >
> > > > > > If some execution environment doesn't support thread names, it
> > > > > > could return a string that makes it possible for a human to
> > > > > > identify the thread, e.g. the tread id. Again, this is assuming
> > > > > > that it is only used for debugging, trace, and similar.
> > > > >
> > > > > i think this raises a good question. is the purpose of setting a
> > > > > thread name
> > > > > meant to be something we can use from the application or is it
> > > > > something that
> > > > > is for debugging diagnostics and may be a best effort?
> > > >
> > > > I think yes it is only for debugging.
> > > > So best effort looks to be a good approach.
> > > > I'm not sure you need to replace the functions.
> > > > Can you just complete the implementations?
> > >
> > >
> > > Surprisingly, thread names are not preserved in core dumps.
> > > The core dump standard used by Linux does not put thread name in the
> > > image.
> > > Since this is a ELF ABI unlikely to be ever be added.
> >
> > What is missing exactly to have thread name in the core dump?
> >
> >
>
> Linux core dump file format is ELF.
> The thread info is storewd in the file notes as NT_PRPSINFO
> which contains info but not the thread name. In the kernel
> thread name is under comm.
>
>
> typedef struct prpsinfo { /* Information about process
> */
> unsigned char pr_state; /* Numeric process state
> */
> char pr_sname; /* Char for pr_state
> */
> unsigned char pr_zomb; /* Zombie
> */
> signed char pr_nice; /* Nice val
> */
> unsigned long pr_flag; /* Flags
> */
>
> uint32_t pr_uid; /* User ID
> */
> uint32_t pr_gid; /* Group ID
> */
>
> pid_t pr_pid; /* Process ID
> */
> pid_t pr_ppid; /* Parent's process ID
> */
> pid_t pr_pgrp; /* Group ID
> */
> pid_t pr_sid; /* Session ID
> */
> char pr_fname[16]; /* Filename of executable
> */
> char pr_psargs[80]; /* Initial part of arg list
> */
> } prpsinfo;
>
>
> Stack Overflow leads to this pages
> https://www.gabriel.urdhr.fr/2015/05/29/core-file/
> https://uhlo.blogspot.com/2012/05/brief-look-into-core-dumps.html
>
> Only know this because of investigating how to get thread names
> to show up in Azure with Watson.
from a dpdk specific perspective if we want to consistently have a
thread name in a dump / coredump then we have a better chance of
success just storing it in our applications namespace ourselves.
relying on platform-specific facilities to preserve it seems hit and
miss at best.
