proc_service.h as an installed header

proc_service.h as an installed header

[Florian Weimer]

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

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?

Thanks,
Florian

Re: proc_service.h as an installed header

[Gary Benson]

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/

Re: proc_service.h as an installed header

[Pedro Alves]

On 07/06/2016 11:06 AM, Gary Benson wrote:
> 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)

Agreed.  (I've followed up on the glibc bug.)

Thanks,
Pedro Alves