From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10909 invoked by alias); 1 Oct 2011 01:08:24 -0000 Received: (qmail 10900 invoked by uid 22791); 1 Oct 2011 01:08:23 -0000 X-SWARE-Spam-Status: No, hits=-2.1 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, 01 Oct 2011 01:08:10 +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 1R9o3j-00065o-2s; Sat, 01 Oct 2011 03:08:09 +0200 Message-ID: <4E86676A.7060706@barfooze.de> Date: Sat, 01 Oct 2011 01:08: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: Kai Tietz CC: gdb-patches@sourceware.org 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> <4E73F1A4.2020606@barfooze.de> <20110917022840.GD17681@adacore.com> <4E74C031.8050603@barfooze.de> <4E83D50B.60002@barfooze.de> In-Reply-To: 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-10/txt/msg00002.txt.bz2 On 09/29/2011 10:26 AM, Kai Tietz wrote: > > Well, I can't approve this and I won't. But I would like to give me 5 > cents for this approach. This approach seems to me bogus, as you are > dependent to sizeof (long) == sizeof (void *), which is a broken > attempt. It might be a way to use here instead intptr_t instead of > long type. gdb assumes that the type of thread_t is a long. that is the bogus part. my macro just explicitly casts it to long. on archictectures where sizeof(void*) != sizeof(long) it would possible truncate or zeropad the value, but still return a (hopefully unique) number. if it isnt guaranteed to return a unique number on this not-yet-existing platform, there had to be some ifdef'd code for that. for libc's that use a struct type for pthread_t, there needs to be a specific workarounds, as others already pointed out. > Nevertheless I admit that the pthread standard doesn't > disallow structure-typed pthread_t, so it might be still worth to > support this for gthread posix. > > For windows there is a pthread implementation "winpthread" - hosted by > mingw-w64 project in experimental tree but it will be soon put into > active trunk. This one uses here for pthread_t an integer-scalar > handle instead of a structure, so issues about current implementation > in gthread are working fine. > > Regards, > Kai >