From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9446 invoked by alias); 1 Oct 2011 09:00:56 -0000 Received: (qmail 9438 invoked by uid 22791); 1 Oct 2011 09:00:55 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 01 Oct 2011 09:00:40 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3) with ESMTP id p9190KsY011511; Sat, 1 Oct 2011 11:00:21 +0200 (CEST) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3/Submit) id p9190Jsm019191; Sat, 1 Oct 2011 11:00:19 +0200 (CEST) Date: Sat, 01 Oct 2011 09:00:00 -0000 Message-Id: <201110010900.p9190Jsm019191@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: pedro@codesourcery.com CC: maillist-gdbpatches@barfooze.de, gdb-patches@sourceware.org In-reply-to: <201110010300.00160.pedro@codesourcery.com> (message from Pedro Alves on Sat, 1 Oct 2011 02:59:59 +0100) Subject: Re: wrong assumptions about pthread_t being numeric References: <4E73D06F.603@barfooze.de> <201109171629.09383.pedro@codesourcery.com> <4E8665ED.4070905@barfooze.de> <201110010300.00160.pedro@codesourcery.com> 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/msg00004.txt.bz2 > From: Pedro Alves > Date: Sat, 1 Oct 2011 02:59:59 +0100 > > > there > > should be at least a explicit function/macro which takes a thread_t and > > converts it to long, since it is assumed in a couple of spots that it is > > of this type. > > that is exactly what my patch does. > > > > and as you wished, it fixes the current issue with minimal effort. > > The patch has a number of problems (no biggie, just the usual for > someone not used to GNU code). I'll take a look if I still failed > to convince you to change musl instead. No, I think you shouldn't. This whole madness with a zillion Linux libc's has to stop. We can't add support for each and every one of them. I think we should take the position that if people want thread support for their non-standard libc's in GDB they should provide a libthread_db.so that is ABI compatible with the one provided by glibc. Since pthread_t is part of that ABI, that means pthread_t has to be "unsigned long int".