From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97021 invoked by alias); 6 Jul 2016 10:06:59 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 96978 invoked by uid 89); 6 Jul 2016 10:06:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Gary X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 06 Jul 2016 10:06:42 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B4BBBDF218 for ; Wed, 6 Jul 2016 10:06:41 +0000 (UTC) Received: from blade.nx (ovpn-116-115.ams2.redhat.com [10.36.116.115]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u66A6e4h024703; Wed, 6 Jul 2016 06:06:41 -0400 Received: by blade.nx (Postfix, from userid 1000) id CE5DB26263B; Wed, 6 Jul 2016 11:06:39 +0100 (BST) Date: Wed, 06 Jul 2016 10:06:00 -0000 From: Gary Benson To: Florian Weimer Cc: gdb@sourceware.org Subject: Re: proc_service.h as an installed header Message-ID: <20160706100639.GB28876@blade.nx> References: <05458564-05ab-349e-8702-8dbe8f50c3de@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <05458564-05ab-349e-8702-8dbe8f50c3de@redhat.com> X-IsSubscribed: yes X-SW-Source: 2016-07/txt/msg00007.txt.bz2 Florian Weimer wrote: > glibc has received a request to turn proc_service.h into an > installed header: > > https://sourceware.org/bugzilla/show_bug.cgi?id=20311 > > The request seems reasonable. > > The only question is who owns this API. glibc is just a consumer > here, and the traditional provider is GDB, so I GDB would be the > natural I always thought of it as part of libthread_db's API. i.e., thread_db.h is the debugger->libthread_db API, and proc_service.h is the libthread_db->debugger API. It seems like it'd be easier to provide it from glibc. If GDB provided it glibc would have to carry its own copy anyway (I'm presuming you don't want to introduce a build dependency on GDB) > The API definitions seem to have drifted a bit, e.g.: > > --- glibc/git/nptl_db/proc_service.h > +++ binutils-gdb/gdb/gdb_proc_service.h > … > -extern ps_err_e ps_pstop (const struct ps_prochandle *); > -extern ps_err_e ps_pcontinue (const struct ps_prochandle *); > +extern ps_err_e ps_pstop (struct ps_prochandle *); > +extern ps_err_e ps_pcontinue (struct ps_prochandle *); > > Perhaps we should clean this up before making this a more public API? Yeah, I think the API was defined to match what the Solaris guys were doing with it, and that doesn't match well what glibc does. There's a fair few places where glibc's libthread_db casts away const. Cheers, Gary -- http://gbenson.net/