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

Doug Evans
2014-07-11T19:44:48Z

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?