From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9690 invoked by alias); 4 Feb 2003 22:02:39 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 9683 invoked from network); 4 Feb 2003 22:02:39 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 4 Feb 2003 22:02:39 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id E8D103CB4; Tue, 4 Feb 2003 17:02:37 -0500 (EST) Message-ID: <3E40387D.50001@redhat.com> Date: Tue, 04 Feb 2003 22:02:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.1) Gecko/20021211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Warkentin Cc: gdb-patches@sources.redhat.com Subject: Re: patch to add QNX NTO i386 support References: <1c3601c2cbc1$72eac3b0$0202040a@catdog> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00145.txt.bz2 Suggest separating the GDB stuff out (native, target, remote) and using separate e-mail threads to discuss each. > gdb/ChangeLog entry: > > 2003-03-02 Kris Warkentin kewarken@qnx.com > > * config/i386/i386nto.mt: New file The MH_CFLAGS and XM_FILE flags should not be needed. Instead gdb/configure should be able to handle this. > * config/i386/nm-nto.h: New file The file nm-nto.h should not be needed. Instead define it's only macro local to remote-nto.c. (Disclaimer, you're breaking new ground with this one. Some existing targets don't have xm-*.h files, but I think you're first with the no-*.h file). > * config/i386/nto.mh: New file Yes, you need this, you've a native support. > * config/i386/tm-i386nto.h: New file The file tm-i386nto.h should not be needed. Instead, gdbarch handles architecture specific issues. The only exception is with shared libraries (as there is a bit of this that isn't yet multi-arched). If nto has architecture specific features then create an i386-nto-tdep.c or nto-tdep.c file (typically it ends up containing the sigtramp code). > * config/i386/xm-nto.h: New file The file xm-nto.h should not be needed. gdb/configure should be able to handle all host specific problems. > * config/tm-qnxnto.h: New file > * configure.host: add gdb_host=nto > * configure.tgt: add gdb_target=i386nto > * nto-procfs.c: New file Once the target stuff is sorted, please re-submit nto-procfs.c as a separate patch. > * nto-share/debug.h: New file > * nto-share/dsmsgs.h: New file > * remote-nto-i386.c: New file > * remote-nto.c: New file Can you expand on how these relate to each other? > * ser-ntopty.c: New file Hmm, is this specific to nto? Also, glancing through the code, how different is this to the existing serial code. I'm wondering if the file exists due to local fixes and not because it is needed. -- Regarding coding standards. Look through http://sources.redhat.com/gdb/current/ari/. Anything listed under `Critical', `Code', or `Fixed' should be addressed, also glance through `info'. I immediatly noticed `PARAMS()' (GDB uses ISO C) `//' (C, not C++) and `extern' in C files (always bad). All files need a proper (C) notice at the top. The year should include `2003' since this is the year that the FSF will first include it. Run all the new files through ./gdb_indent.sh. Audit all `#ifdef ...' many of those macro's have been deleted (I noticed TARGET_BYTE_ORDER_SELECTABLE'. Many of the functions have `^qnx_' prefixes. Should they be given `^nto_' prefixes?