From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23759 invoked by alias); 1 Oct 2011 02:00:23 -0000 Received: (qmail 23734 invoked by uid 22791); 1 Oct 2011 02:00:22 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 01 Oct 2011 02:00:04 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1R9orz-0007Aj-8L from pedro_alves@mentor.com ; Fri, 30 Sep 2011 19:00:03 -0700 Received: from scottsdale.localnet ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Oct 2011 03:00:01 +0100 From: Pedro Alves To: John Spencer Subject: Re: wrong assumptions about pthread_t being numeric Date: Sat, 01 Oct 2011 02:00:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.7.1; x86_64; ; ) Cc: gdb-patches@sourceware.org References: <4E73D06F.603@barfooze.de> <201109171629.09383.pedro@codesourcery.com> <4E8665ED.4070905@barfooze.de> In-Reply-To: <4E8665ED.4070905@barfooze.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110010300.00160.pedro@codesourcery.com> 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/msg00003.txt.bz2 On Saturday 01 October 2011 01:59:25, John Spencer wrote: > >>> i disagree. adding a proper solution once is superior to creating dozens > >>> of special case hacks. > >> What's the "proper" solution then? The only possible way I can think > >> of to handle some libc what uses a struct for pthread_t, is with some way at > >> runtime to know which libc/thread_db gdb is talking to, failing that, > >> #ifdefs and/or autoconfig'ury. Since a simple cast will > >> work for glibc, android, musl, and whatever other libc's happen be > >> be building gdbserver today, what's the point? > > I'll even go a step further, and suggest you do expose pthread_t > > as a typedef to long in public headers, and cast it to pointer internally > > in musl, just like glibc and most other libc's do. Hiding the fact > > that you implement things with a pointer could even be a good thing. > > > > It's just easier for everybody else that way. There's really no point in > > being different for the sake of it. > > > > that's definitely going to far, you can't dictate how libcs should > handle an opaque type internally just to keep broken code working. The fact that you're still calling gdb's libthread_db.so handling code broken because of this only shows that you still missed the point of the code you're talking about. Let me sum it up: The debugger is coordinating with a libc-provided shared library, that is used to peek at the libc's internal state. pthread_t's type is implementation defined. The debugger's code in question is interacting with a specific libc implementation (glibc). For that fact, the debugger's code in question can be seen as being part of "the implementation" (as in the pthread_t's type being implementation defined part). The fact that other libcs work with the same code is a bonus. Again: > that's definitely going to far, you can't dictate how libcs should > handle an opaque type internally just to keep broken code working. I can at least try to persuade one libc author into sanity. :-) Ever heard of not inflicting unnecessary pain on others for no good reason? You know people do sprinkle around printfs of pthread_t's for debug purposes, don't you? Things like printing printf ("%ld been here\n", pthread_self ()). I really don't see the point of not being source compatible with glibc (and all other linux libcs) when it's super easy to be so... Again: > that's definitely going to far, you can't dictate how libcs should > handle an opaque type internally just to keep broken code working. public header: typedef unsigned long pthread_t; musl implementation: struct pthread { whatever you have today; }; int pthread_foo_public_function (pthread_t th, ...) { struct pthread *t = (pthread_t) th; // business as usual. } There, how did that dictate how your libc handles its opaque type _internally_ again? It shouldn't take more than 15 minutes to change all of that in musl, and everyone lives happy ever after. > 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. -- Pedro Alves