From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7294 invoked by alias); 7 Feb 2012 20:45:32 -0000 Received: (qmail 7284 invoked by uid 22791); 7 Feb 2012 20:45:30 -0000 X-SWARE-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-yw0-f41.google.com (HELO mail-yw0-f41.google.com) (209.85.213.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 07 Feb 2012 20:45:17 +0000 Received: by yhoo22 with SMTP id o22so3847453yho.0 for ; Tue, 07 Feb 2012 12:45:17 -0800 (PST) Received: by 10.50.153.133 with SMTP id vg5mr18376460igb.8.1328647517185; Tue, 07 Feb 2012 12:45:17 -0800 (PST) Received: from giga.mcgary.org ([65.101.31.122]) by mx.google.com with ESMTPS id x18sm35570443ibi.2.2012.02.07.12.45.15 (version=SSLv3 cipher=OTHER); Tue, 07 Feb 2012 12:45:16 -0800 (PST) Message-ID: <4F318D55.10402@gmail.com> Date: Tue, 07 Feb 2012 20:45:00 -0000 From: Greg McGary User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 MIME-Version: 1.0 To: gdb@sourceware.org Subject: gdbserver for embedded targets? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-02/txt/msg00006.txt.bz2 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 ... DSPs 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. Comments? G