Re: help with pthread_t deprecation / api changes

[Tyler Retzlaff <roretzla@linux.microsoft.com>]

On Fri, Dec 09, 2022 at 02:38:49PM -0800, Stephen Hemminger wrote:
> On Fri, 09 Dec 2022 22:14:33 +0100
> Thomas Monjalon <thomas@monjalon.net> wrote:
> 
> > 09/12/2022 17:48, Stephen Hemminger:
> > > On Fri, 09 Dec 2022 08:53:57 +0100
> > > Thomas Monjalon <thomas@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.