Monitor support in machine -tdep.c file?

Monitor support in machine -tdep.c file?

[Stephane Carrez]

Hi!

I'm adding the support for Buffalo monitor for 68hc11 in Gdb (using the CME11E9
board from Axiom Manufacturing). I'm using the Gdb generic monitor framework.

Is it acceptable to put such monitor support in my m68hc11-tdep.c file?

For other monitors, it's true that a separate file is defined for each kind
of monitor.  But I would like to avoid introducing a new file in Gdb for
something that will always be there for 68hc11.

I understand that in the past the various monitors were selected based on
the configury stuff.  With the multi-arch, it seems to me we should always
have those monitors.  In that context, do we really need to separate the
monitor from the machine specific part? (most monitors are machine specific).

Thanks for any opinions about that,

	Stephane

-----------------------------------------------------------------------
         Home                               Office
E-mail: stcarrez@worldnet.fr               Stephane.Carrez@sun.com
WWW:    http://home.worldnet.fr/stcarrez   http://www.sun.com
Mail:   17, rue Foucher Lepelletier        6, avenue Gustave Eiffel
        92130 Issy Les Moulineaux          78182 Saint Quentin en Yvelines
        France

Re: Monitor support in machine -tdep.c file?

[J.T. Conklin]

>>>>> "Stephane" == Stephane Carrez <Stephane.Carrez@worldnet.fr> writes:
Stephane> Is it acceptable to put such monitor support in my
Stephane> m68hc11-tdep.c file?
Stephane>
Stephane> For other monitors, it's true that a separate file is
Stephane> defined for each kind of monitor.  But I would like to avoid
Stephane> introducing a new file in Gdb for something that will always
Stephane> be there for 68hc11.
Stephane>
Stephane> I understand that in the past the various monitors were
Stephane> selected based on the configury stuff.  With the multi-arch,
Stephane> it seems to me we should always have those monitors.  In
Stephane> that context, do we really need to separate the monitor from
Stephane> the machine specific part? (most monitors are machine
Stephane> specific).

My personal preference is to use another file, even though it will
only and always be used by the 68hc11 target.

* It re-enforces the abstraction layer between the target dependent
  code in *-tdep.c and the target i/o layer in the remote-*.c and
  *-rom.c files.

* It exposes all the files that use the ROM monitor infrastructure.
  For example, I've had an itch to refine the code used for loading a
  program image (instead of using multiple fields in monitor_ops, I'd
  have a single pointer to void.  For those rom monitors using the s-
  record downloader, it would be set to point to a struct containing
  s-record related fields.  For those rom monitors using custom down-
  loaders, it might not even use the new load param ptr/field).  The
  point being, when (and if) I make such a change, I would expect that
  I could edit *-rom.c and fix up all the examples.  I wouldn't expect
  a rom monitor might be hiding in target specific code.

* While we have quite a bit of files in the top-level, I don't think a
  few more are going to hurt.  I think it's understood that we'll have
  to go to a hierarchical scheme of some sort eventually.  But until
  then, I believe we should maintain the same standard that we've been
  going by.

Any other opinions?

        --jtc  

-- 
J.T. Conklin
RedBack Networks