From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3527 invoked by alias); 6 Sep 2002 00:15:15 -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 3518 invoked from network); 6 Sep 2002 00:15:14 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 6 Sep 2002 00:15:14 -0000 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id RAA05923; Thu, 5 Sep 2002 17:05:49 -0700 (PDT) Message-ID: <3D77F391.85509705@redhat.com> Date: Thu, 05 Sep 2002 17:15:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Joel Brobecker CC: gdb-patches@sources.redhat.com Subject: Re: native or target? References: <20020905232440.GV1169@gnat.com> <20020905232935.GF1194@gnat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00078.txt.bz2 Joel Brobecker wrote: > > Hello, > > I have read the gdbint documentation, but still sometimes have some > difficulties deciding where some of the pieces of code should be going. > Should be -nat, or -tdep? Difficult to say sometimes. Can anyone help > me? Sure. Let's take i386-linux for an example. It can be debugged natively (meaning, the debugger and the program being debugged are both running on the same machine), or it can be cross-debugged (the debugger is running on one machine, and the program being debugged is running on another machine). If it is cross-debugged, then the debugger might even be running on a machine that is not an intel machine, and maybe is not even running linux (eg. a sparc solaris machine). So: if you add code that affects how gdb debugs a 386-linux program _natively_, then that code goes in i386-linux-nat.c. If you add code that affects how gdb debugs a 386-linux program _no_matter_ where gdb is running, then it goes in i386-linux-tdep.c. And of course, if you add code that affects how gdb debugs _any_ 386 program, then it goes in i386-tdep.c. > I think part of it is due to the fact that I don't have a clear > definition of what a native port is. A simple but inaccurate definition of "native" is that gdb is running on the same machine as the target program. A more accurate definition is that gdb is using the "native" (ie. OS-provided) mechanism for controlling the target program (eg. /proc or ptrace). An example of "not native" is when gdb uses the remote serial protocol to debug. And this illustrates why the first simple definition of "native" is inaccurate. It is possible to use the remote serial protocol to debug a program even if it is running on the same computer as gdb. That would not be "native". > I suppose native is when host and > target are the same? I don't have a recent cross-debugger handy to check > that: if I am running on a x86-linux machine cross ppc, is the code in > i386-nat.c used? No. Look in your build directory -- you should not see i386-nat.o. > Let's take an example of where I am confused: > > On interix, the PC_IN_SIGTRAMP method works by comparing the > PC address against a set of addresses. These addresses are actually > to computed at the time when the comparison is made, but were > cached earlier. > > One of the places where these addresses are computed is in the > procfs module (ie we deduct these addresses from the proc info). > Right now, our code looks like this: > > proc_get_status (procinfo *pi) > { > [a. normal processing] > #ifdef __INTERIX > [b. compute sigtramp-related addresses from proc info] > #endif > [c. rest of normal processing] > } I don't understand why you would do this here. It seems completely unrelated to the function of proc_get_status. > 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). 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? > On one hand the procinfo stuff seem to pertain to the native > side (hence the -nat module), procfs.c is DEFINITELY for native debugging ONLY. It should not be used for cross-debugging. > but on the other hand, the addresses > themselves belong to the interix-tdep module... That's correct. > What would you do? Move them out of procfs, and probably into interix-tdep. > Or maybe the approach of caching the addresses from the proc > information is not viable in the current GDB architecture? That's what I don't understand. How can you be using procfs if your target program is on another machine? Procfs depends on making os system calls. Michael