This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: proc_service.h as an installed header
- From: Gary Benson <gbenson at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: gdb at sourceware dot org
- Date: Wed, 6 Jul 2016 11:06:39 +0100
- Subject: Re: proc_service.h as an installed header
- Authentication-results: sourceware.org; auth=none
- References: <05458564-05ab-349e-8702-8dbe8f50c3de@redhat.com>
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/