Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@gnat.com>
To: gdb-patches@sources.redhat.com
Subject: native or target?
Date: Thu, 05 Sep 2002 16:29:00 -0000	[thread overview]
Message-ID: <20020905232935.GF1194@gnat.com> (raw)
In-Reply-To: <20020905232440.GV1169@gnat.com>

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?

I think part of it is due to the fact that I don't have a clear
definition of what a native port is. 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?

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 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. On one hand the procinfo stuff seem to pertain to the native
  side (hence the -nat module), but on the other hand, the addresses
  themselves belong to the interix-tdep module... What would you do?

  Or maybe the approach of caching the addresses from the proc
  information is not viable in the current GDB architecture?

Thanks,
-- 
Joel


       reply	other threads:[~2002-09-05 23:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20020905232440.GV1169@gnat.com>
2002-09-05 16:29 ` Joel Brobecker [this message]
2002-09-05 16:35   ` Daniel Jacobowitz
2002-09-05 17:15   ` Michael Snyder
2002-09-05 18:02     ` Joel Brobecker
2002-09-06 11:00       ` Michael Snyder
2002-09-06 12:48       ` Mark Kettenis
2002-09-09 12:14         ` Andrew Cagney
2002-09-05 17:47   ` Kevin Buettner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020905232935.GF1194@gnat.com \
    --to=brobecker@gnat.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox