This is the mail archive of the 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]
Other format: [Raw text]

gdbserver for embedded targets?

Most gdbserver targets are full OSes (Linux, *BSD).  I need a remote stub for an embedded multi-core DSP target.  The DSPs are co-processors of an ARM, similar to the pairing of SPUs with PPC.  When debugging, there will always be a full OS (Linux or Windoze) front-end system available.  System topology looks like so:

    Workstation: gdb client
    ... TCP ...
    x86 front-end: gdbserver
    ... serial ...
    ARM co-processor: target control
    ... shared memory, control registers ...

The DSP doesn't handle interrupts, and all control is handled by the ARM, thus the ARM must run the stub.  Traditional stub functionality (remote protocol handling + target processor control) is divided betweenthe front-end systemthe ARM.  The front-end system will run gdbserver, and the target_ops will be populated with functions that send/receive requests over serial using a compact binary protocol.  The ARM will run a simple command loop.  The gdbserver/ARM interactions will be simple commands toread/write memory & registers, and control execution. 

I really don't want to write a remote-protocol server, and would rather leverage the existing gdbserver, since presumably it is maintained and stays current with enhancements to the remote protocol.

Question: is the gdbserver target_ops interface suitable for such a target?  I'm going to proceed under the assumption that it is, and will supplement if I find deficiencies.



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