This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Monitor support in machine -tdep.c file?
- To: Stephane Carrez <Stephane dot Carrez at worldnet dot fr>
- Subject: Re: Monitor support in machine -tdep.c file?
- From: jtc at redback dot com (J.T. Conklin)
- Date: 07 Sep 2000 12:17:09 -0700
- Cc: gdb at sourceware dot cygnus dot com
- References: <39B6CBFB.9462A94E@worldnet.fr>
- Reply-To: jtc at redback dot com
>>>>> "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