From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 60C22A0093; Sat, 10 Dec 2022 00:55:11 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EE10740A84; Sat, 10 Dec 2022 00:55:10 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 1B20240042 for ; Sat, 10 Dec 2022 00:55:09 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 4F5B720B6C40; Fri, 9 Dec 2022 15:55:08 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 4F5B720B6C40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1670630108; bh=163blD0ViTaLvOc1mh/cvU2E6bWc3sKRWwki0QfR2dc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZP18nidC3Kx+Z/vq7oiwsXQS2dAlA6aN7OFbJuZ/GRmZyZchtQ3r/KHSrp9DLXNNV 5NZNt44k1SsFssd+r5fmuOFNiJoyZwubrBUVJRS9jrjJpimt1O99TfxexsSVldLyGR UsEcH5UoE5147q/4bCJYtLFsZEScyLae2B87mFSU= Date: Fri, 9 Dec 2022 15:55:08 -0800 From: Tyler Retzlaff To: Stephen Hemminger Cc: Thomas Monjalon , Morten =?iso-8859-1?Q?Br=F8rup?= , dev@dpdk.org, david.marchand@redhat.com, Bruce Richardson Subject: Re: help with pthread_t deprecation / api changes Message-ID: <20221209235508.GB26599@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20221130225427.GA13682@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <2146119.C4sosBPzcN@thomas> <20221209084814.3b1479d5@hermes.local> <17965272.sWSEgdgrri@thomas> <20221209143849.137b1202@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221209143849.137b1202@hermes.local> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Fri, Dec 09, 2022 at 02:38:49PM -0800, Stephen Hemminger wrote: > On Fri, 09 Dec 2022 22:14:33 +0100 > Thomas Monjalon wrote: > > > 09/12/2022 17:48, Stephen Hemminger: > > > On Fri, 09 Dec 2022 08:53:57 +0100 > > > Thomas Monjalon 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.