From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27073 invoked by alias); 9 Mar 2003 14:54:06 -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 26904 invoked from network); 9 Mar 2003 14:54:05 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by 172.16.49.205 with SMTP; 9 Mar 2003 14:54:05 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id JAA26634 for ; Sun, 9 Mar 2003 09:40:51 -0500 Received: from dash ([192.168.20.29]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id JAA26788 for ; Sun, 9 Mar 2003 09:54:03 -0500 Message-ID: <008701c2e64c$6342cb60$2a00a8c0@dash> From: "Kris Warkentin" To: Subject: Re: [RFC] QNX Neutrino/i386 support Date: Sun, 09 Mar 2003 14:54:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SW-Source: 2003-03/txt/msg00203.txt.bz2 > 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. Okay. I guess I'll have to wait for someone else to pipe up. > 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. Okay, I can see that. One of the things I've been working on is untying all our register stuff (in our own tree) because it bounces back and forth between files so I can relate to how nasty that gets. All there is in i386-nto-tdep.c however is the link map stuff and the register fetch/store functions which many tdep files have. I just happen to do a little extra calculating to report back regset numbers and sizes, etc. that are handy for nto-procfs and remote-nto to know. My plan was to have all the generic stuff in nto-tdep.c and then have hooks for register store/fetch in the -nto-tdep.c files. This way nto-procfs.c and remote-nto.c get to take advantage of the same files. Forgive my bad ascii art but we have: nto-procfs.c__ _i386-nto-tdep.c \_nto-tdep.[ch]__/_sh-nto-tdep.c remote-nto.c__/ \_mips-nto-tdep.c, arm, ppc, ... Where the nto-tdep.h is the interface to the arch specific back ends. > 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. Alright. I had understood that you wanted me to separate the native from the remote but perhaps I misunderstood. If you would like to do it this way, it's fine by me. > 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? I hope that I will eventually earn your trust but I can see your point. Tell you what, how about you add the file as you presented it to me and then I will start submitting additions to you. Trust is a two way street so I will trust you to do the right thing and help me get our support in and working. cheers, Kris