This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gdb port to or1k


>>>>> "Marko" == Marko Mlinar <Marko.Mlinar@campus.fri.uni-lj.si> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]