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

[jtc at redback dot com (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