From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11657 invoked by alias); 1 Oct 2011 09:14:48 -0000 Received: (qmail 11645 invoked by uid 22791); 1 Oct 2011 09:14:47 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from mail-vx0-f169.google.com (HELO mail-vx0-f169.google.com) (209.85.220.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 01 Oct 2011 09:14:32 +0000 Received: by vcbfo14 with SMTP id fo14so2305242vcb.0 for ; Sat, 01 Oct 2011 02:14:31 -0700 (PDT) Received: by 10.52.180.4 with SMTP id dk4mr12897160vdc.49.1317460471156; Sat, 01 Oct 2011 02:14:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.200.132 with HTTP; Sat, 1 Oct 2011 02:14:11 -0700 (PDT) In-Reply-To: <201110010900.p9190Jsm019191@glazunov.sibelius.xs4all.nl> References: <4E73D06F.603@barfooze.de> <201109171629.09383.pedro@codesourcery.com> <4E8665ED.4070905@barfooze.de> <201110010300.00160.pedro@codesourcery.com> <201110010900.p9190Jsm019191@glazunov.sibelius.xs4all.nl> From: Kevin Pouget Date: Sat, 01 Oct 2011 09:14:00 -0000 Message-ID: Subject: Re: wrong assumptions about pthread_t being numeric To: maillist-gdbpatches@barfooze.de Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00006.txt.bz2 On Sat, Oct 1, 2011 at 11:00 AM, Mark Kettenis wr= ote: >> 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). =A0I'll take a look if I still failed >> to convince you to change musl instead. > > No, I think you shouldn't. =A0This whole madness with a zillion Linux > libc's has to stop. =A0We can't add support for each and every one of > them. =A0I 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". Just my 2 cents here, but a few years ago, I developped a library named "User-Level Thread_db" [1], which aims at reducing the burden of thread-library developpers when it comes to provide debuggers support. > they should provide a libthread_db.so that is ABI compatible with the one= provided by glibc I took the opposite approach: I developped the `libthread_db.so' and the thread-target on GDB's side, and then specified a very light API to link `libthread_db.so' to the threading library. The appoach was demonstrated efficient on two different libraries, just a few days requied for the integration. That was on the 6.8 days, so some adaptations should be necessary for 7.*, but most of the work is already in place. Cordially, Kevin [1] http://mpc.sourceforge.net/files/PouPerCarJou10MTAAP.pdf