From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23254 invoked by alias); 8 Mar 2003 23:49:43 -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 23245 invoked from network); 8 Mar 2003 23:49:39 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (62.163.169.212) by 172.16.49.205 with SMTP; 8 Mar 2003 23:49:39 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6/8.12.5) with ESMTP id h28Nn6oR000579; Sun, 9 Mar 2003 00:49:06 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6/8.12.6) with ESMTP id h28Nn6N8000782; Sun, 9 Mar 2003 00:49:06 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6/8.12.6/Submit) id h28Nn54f000779; Sun, 9 Mar 2003 00:49:05 +0100 (CET) Date: Sat, 08 Mar 2003 23:49:00 -0000 Message-Id: <200303082349.h28Nn54f000779@elgar.kettenis.dyndns.org> From: Mark Kettenis To: kewarken@qnx.com CC: gdb-patches@sources.redhat.com In-reply-to: <004001c2e584$65814690$2a00a8c0@dash> (kewarken@qnx.com) Subject: Re: [RFC] QNX Neutrino/i386 support References: <200303081344.h28DiNvi040785@elgar.kettenis.dyndns.org> <004001c2e584$65814690$2a00a8c0@dash> X-SW-Source: 2003-03/txt/msg00196.txt.bz2 From: "Kris Warkentin" Date: Sat, 8 Mar 2003 10:06:49 -0500 That's great Mark but what about the native procfs stuff? Sorry but the native procfs stuff is beyond my maintainership, and I don't feel confident enough to approve that stuff based on my global maintainership. The most recent patch that I had submitted was a native only version. The only stuff in the i386-nto-tdep.c that was even vaguely related to the remote protocol was stuffing the regset type in the register area. This is also used by nto-procfs.c so I refactored the regset numbers to be defines that can be used by both. The i386-nto-tdep.c (and the nto-tdep.c for that matter) should only contain ISA/ABI related code. You'll probably need some register mapping functions in there (for interpreting core files), but I fail to see how the code that's in your proposed i386-nto-tdep.c file is related to the rest of the stuff. There just seem to be too many interdependencies between all the different files. The file you have reduced to here is completely useless for any form of debugging on Neutrino. We don't currently support the standard gdb debug protocol although it's on our to-do list. Our i386 registers are in a different order that gdb so we need to do the mapping. I have already applied patches to solib.c to do a special lookup of target solibs. Without that support, libs won't be found properly. I understand that, and I'm not asking you to implement the standard GDB remote protocol before we can add this to GDB. BTW, the OSABI stuff is already committed (they gave me write-after approval for cvs) - the only stuff left is the addition of new files. I would like to get the config dir stuff, the tdep files, the nto-share headers and nto-procfs.c committed. But I hope you can understand that you can't just drop in those new files. Dropping in large chunks of code makes it difficult to get approval. If you can split things up in smaller chunks that don't need approval of several people, you're much more likely to get approval. As a benefit you'll probably get code that's structure more like the way we'd like GDB to evolve. That's the main reason why I (and Andrew before me) have asked you to seperate the target-dependent bits from the native and remote support and ask approval for those bits seperately. What we have currently is something that works perfectly for us. I really don't want to start with something completely broken and make additions until it works. I want to add the working stuff and then cut away any fat that we can prove that we don't need. I don't mind doing major refactoring but I want to have working code in CVS at all times. That is something that the GDB project strives for and I would like to do for our target as well. I've attached a tarball with the files in it. I think that it's pretty much the same as what you have with the changes for the remote defines. I appreciate the time you're putting into this and I really want our port to be as clean as it can be. I know that there's lots of work to be done but I'd really rather start from a working version and clean from there. This is one of my highest priority projects so I have lots of cycles available to do the work but I want to be able to point our customers to the head branch and have it work for them. We have seen in the past that such cleanups hardly ever happen. Would it be acceptable for you to check the new files in on a branch and merge it in bit by bit from there? Mark