From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: Stephane Carrez Cc: gdb@sourceware.cygnus.com Subject: Re: Monitor support in machine -tdep.c file? Date: Thu, 07 Sep 2000 12:17:00 -0000 Message-id: <5m8zt4qafe.fsf@jtc.redback.com> References: <39B6CBFB.9462A94E@worldnet.fr> X-SW-Source: 2000-09/msg00082.html >>>>> "Stephane" == Stephane Carrez 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