Re: [PATCH 05/15] Introduce and use debug_printf and debug_vprintf

[Doug Evans <dje@google.com>]

Gary Benson writes:
 > This introduces debug_printf and debug_vprintf, a function that
 > clients of "common" are expected to implement.  gdbserver's
 > existing debug_printf is repurposed as debug_vprintf, and a new
 > wrapper is written.
 > 
 > common/agent.c is changed to use debug_vprintf rather than
 > defining the macro DEBUG_AGENT depending on GDBSERVER.
 > 
 > nat/i386-dregs.c is changed to use the externally-implemented
 > debug_printf, rather than defining it itself.
 > 
 > gdb/
 > 2014-07-09  Tom Tromey  <tromey@redhat.com>
 > 	    Gary Benson  <gbenson@redhat.com>
 > 
 > 	* common/common-debug.h: New file.
 > 	* utils.h: Include common-debug.h.
 > 	* utils.c (debug_vprintf): New function.
 > 	(debug_printf): Likewise.
 > 	* common/agent.c (debug_agent_print): New function.
 > 	(DEBUG_AGENT): Redefine.
 > 	* nat/i386-dregs.c (debug_printf): Undefine.
 > 
 > gdb/gdbserver/
 > 2014-07-09  Tom Tromey  <tromey@redhat.com>
 > 	    Gary Benson  <gbenson@redhat.com>
 > 
 > 	* utils.h: Include common-debug.h.
 > 	* debug.h (debug_printf): Don't declare.
 > 	* debug.c (debug_vprintf): New function.
 > 	(debug_printf): Use the above.

IWBN if there was more file naming consistency.
As a general rule, how objectionable is it to have
gdb/foo.c and gdbserver/foo.c for every shared foo.h header?
[Or common-foo.h header in the case of, e.g., common/common-debug.h.]
An alternative would be to move common-debug.h to a new directory,
e.g., shared, and call it shared/debug.h.  I'm only mentioning
this for discussion sake, it's not a requisite for this patch.

In this case, any objection to putting the gdb implementation
in gdb/debug.c instead of utils.c?