From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16998 invoked by alias); 6 Sep 2002 01:02:49 -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 16925 invoked from network); 6 Sep 2002 01:02:47 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sources.redhat.com with SMTP; 6 Sep 2002 01:02:47 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 54CDAD2CC1; Thu, 5 Sep 2002 18:02:47 -0700 (PDT) Date: Thu, 05 Sep 2002 18:02:00 -0000 From: Joel Brobecker To: Michael Snyder Cc: gdb-patches@sources.redhat.com Subject: Re: native or target? Message-ID: <20020906010247.GX1169@gnat.com> References: <20020905232440.GV1169@gnat.com> <20020905232935.GF1194@gnat.com> <3D77F391.85509705@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D77F391.85509705@redhat.com> User-Agent: Mutt/1.4i X-SW-Source: 2002-09/txt/msg00081.txt.bz2 > A more accurate definition is that gdb is using the "native" > (ie. OS-provided) mechanism for controlling the target > program (eg. /proc or ptrace). Thank you. With your explainations and Daniel's message, I think it's much clearer in my head now. > > I would like to move the code in [b.] to the right place, and then > > remplace the #ifdef __INTERIX section by the proper runtime test. > > But I am confused as to where the right place for this code would > > be. > > I would say this is target code. Correct me of I am wrong, but > I think you would use the same code regardless of how you were > debugging the target program (procfs or remote). This is where I am wondering whetherour approach is flawed or not. It seems very awkward at the very least: procfs is definitely native, but at the same time the procfinfo data contains these addresses that are useful for a method which is target dependent... I need to spend a bit more time understanding why the computation is done here. I need to do some more research to see if there is no other way to get these addresses. > But I am confused -- you said that GDB is not running on the > target platform, but on a 386-linux machine. So how can you > use procfs.c? That's my fault. I confused you with my first example for a question that was unrelated to the case we are discussing. I am actually using a native debugger on i386-interix. But I am trying to fix the few places where we have target-dependent code in native-only modules. I don't think this is an option to leave these changes there if I want our interix port to be integrated :-). BTW: Is it a requirement for a new port to be buildable as a target only, or can we provide a native-only port as a first step, and then eventually improve it to support "--host=--target=interix"? This is out-of-the-box thinking, I don't see how this would help the problem we have been discussing, but I think this is an interesting piece of information to know. > > What would you do? > > Move them out of procfs, and probably into interix-tdep. I thought about this. There were several issues that made me a bit cautious: 1. interix-tdep can not know about the procinfo structure, since this structure is used in native-only debugging. I can still get the information because I know the offset of these addresses in the procinfo structure. A bit crude, and probably hard to maintain as versions of interix evolve, but doable. 2. I still need somehow to call this function from procfs.c. Could it be a new architecture method? As I said above, I think it is best that I investigate a bit more with Donn Terry to see if there is no other way to implement PC_IN_SIGTRAMP in a completely target-oriented way before any of us spends more time on this. -- Joel