From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15846 invoked by alias); 17 Sep 2011 01:05:49 -0000 Received: (qmail 15836 invoked by uid 22791); 17 Sep 2011 01:05:48 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from barfooze.de (HELO barfooze.de) (78.46.117.212) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 17 Sep 2011 01:05:34 +0000 Received: from xdsl-188-155-204-78.adslplus.ch ([188.155.204.78] helo=[172.16.0.230]) by barfooze.de with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1R4jLP-0000qD-0m; Sat, 17 Sep 2011 03:05:32 +0200 Message-ID: <4E73F1A4.2020606@barfooze.de> Date: Sat, 17 Sep 2011 01:23:00 -0000 From: John Spencer User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110221 SUSE/3.1.8 Mail/1.0 MIME-Version: 1.0 To: gdb-patches@sourceware.org CC: Pedro Alves Subject: Re: wrong assumptions about pthread_t being numeric References: <4E73D06F.603@barfooze.de> <201109170000.43306.pedro@codesourcery.com> <4E73D806.2040302@barfooze.de> <201109170130.42276.pedro@codesourcery.com> In-Reply-To: <201109170130.42276.pedro@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-09/txt/msg00333.txt.bz2 On 09/17/2011 02:30 AM, Pedro Alves wrote: > On Saturday 17 September 2011 00:13:10, John Spencer wrote: >> On 09/17/2011 01:00 AM, Pedro Alves wrote: >>> These are only built natively on solaris and aix respectively, so >>> let's just leave them alone. >>> >> I expected it to be desirable for a product in industrial use to be >> standard-compliant and not invoking undefined behavior. > Those files are tied to those platforms' thread_db/libc implementations. > There's absolutely no need to handle some other hipotetical libc that > defines pthread_t diferently there. If it appears, we'll handle it. > Chances are, some other changes would be necessary to make it really > work, not just build. > exactly. for example in musl's case it is wrong to compare the underlying type (which is a struct pointer) with 0. in the implementation specific part it would practically be valid to compare it with NULL, but that's still invalid regarding the definition in POSIX. so the few places that use a thread id had to be changed everywhere, to not have dozens of special case sections for any libc/OS combination... also there are a few spots where the thread_t is numerically compared to some arbitrary int value (i have not yet evaluated where those originate from). this also can't work when thread_t is no number. this happens for example in the if statement leading to the posted printf format string errors. i expect that the number of actual fixes would be small, but it might require another way to get to a thread id. if the id is only used for textual representation, it would be sufficient if gdb would assign a new unique number on each successful pthread_create. if it is also used to find a thread internally, it had to have a list of tid numbers -> pthread_t. >>>> thread-db.c: In function 'find_one_thread': >>>> thread-db.c:295:7: error: format '%ld' expects type 'long int', but >>>> argument 3 has type 'thread_t' >>>> thread-db.c: In function 'attach_thread': >>>> thread-db.c:335:7: error: format '%ld' expects type 'long int', but >>>> argument 3 has type 'thread_t' >>>> thread-db.c:341:9: error: format '%ld' expects type 'long int', but >>>> argument 2 has type 'thread_t' >>> So just cast it to long, and you're done. >>> >> pthread_t could legally be a struct, which you can't just cast to a long. > No need to complicate things for an hipotetical scenario. The set of > libc's in existence is finite. If we were to handle a struct pthread_t, > we'd need to be able to print it, and so we'd need some libc specific > way to do it, something autoconf'ed. There's no need to invent work. > i disagree. adding a proper solution once is superior to creating dozens of special case hacks. also it saves a lot of time in the long term. -- JS