From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: "Marko Mlinar" Cc: , "Damjan Lampret" , , "Johan Rydberg" Subject: Re: gdb port to or1k Date: Mon, 30 Apr 2001 10:13:00 -0000 Message-id: <5mhez69uqr.fsf@jtc.redback.com> References: <00a501c0ce7d$1fa4c5e0$bb4902c1@Javor> <5mhezbmi6i.fsf@jtc.redback.com> <004b01c0cee8$5617aaa0$e54902c1@Javor> X-SW-Source: 2001-04/msg00230.html >>>>> "Marko" == Marko Mlinar writes: >> Many host systems that GDB supports don't even have parallel ports. >> Those that do don't suport the same set of capabilites (other than >> open/close and write, those are pretty standard :-). Marko> We are only interested to add debugging support for host that Marko> will be really used e.g. we don't have any interest at all to Marko> use arm host. So we can assume, host should be able to print Marko> and thus have printer port. Please note that it is a GDB goal (or at least one of my my goals as a GDB hacker) that features be available on as many host machines as possible. While there have been back ends which have been integrated into GDB that need a special vendor-supplied DLL which ties it to a single host platform (ie. windows), I'd rather avoid this if at all possible. If I understand your intentions, you intend to use a bi-directional parallel port to bit-bang a JTAG like interface. This limits the feature to machines with bi-directional parallel hardware running OS's that allow user-level programs access to the individual lines. I think this is OK. Marko> Do you perhaps know if this will work for SUN? And HP machines? Marko> Is there any way to easily configure this, if platforms use Marko> different IOCTL numbers? (not to include #ifdefs) I believe that Andrew Cagney mentioned the ser-* abstraction GBD uses for serial ports. It may be necessary to do something equivalent for parallel ports. Since the ioctl's used by serial tty's is much more standardized on UNIX and UNIX-like systems (e.g. sgtty, termio or termios), support for all is located in one source file ser-unix.c. For parallel, we might need par-hp.c, par-sun.c, etc. It won't be a requirement for you to supply implementations for all platforms, just that the scheme be extensible and not preclude other people adding support for their platforms. Marko> And on the other hand we don't wan't to use special driver for Marko> every platform... I don't think this is as bad as you think. If you make the split correctly, the bulk will be host independent. --jtc -- J.T. Conklin RedBack Networks