From: "Kris Warkentin" <kewarken@qnx.com>
To: "Mark Kettenis" <kettenis@chello.nl>
Cc: <ac131313@redhat.com>, <gdb-patches@sources.redhat.com>
Subject: Re: patch to add QNX NTO i386 support
Date: Thu, 13 Feb 2003 22:29:00 -0000 [thread overview]
Message-ID: <021601c2d3af$562e07f0$0202040a@catdog> (raw)
In-Reply-To: <200302132220.h1DMKBxU000786@elgar.kettenis.dyndns.org>
> From: "Kris Warkentin" <kewarken@qnx.com>
> Date: Wed, 12 Feb 2003 17:18:35 -0500
>
> Okay. I've got all our config files down to what's below. Not
> much left to them. Andrew had wanted me to submit separate native
> and remote patches but I can't figure out how to do that. We would
> never build a native only gdb - we always support the remote
> protocol as well - so I'm at a loss for how to get it to NOT
> compile the remote-nto.c file.
>
> I think we'd want the remote stuff to be optional. One way to make it
> such is having a configure option, say --enable-remote-nto, to enable
> it (which would be the default on QNX NTO systems, where you'd be able
> to use --disable-remote-nto to disable it). GDB should compile either
> way (but the remote-nto stuff probably wouldn't be of any use except
> for connecting to QNX NTO systems).
How would this work? If the option were supplied would I append
remote-qnx.o to TDEPFILES?
> As you can see, I've got the common stuff separated into nto-tdep.c and
> i386-nto-tdep.c which will be used by both remote-nto.c and
nto-procfs.c.
> The problem seems to be that when I build a native debugger, it
includes the
> stuff from i386nto.mt as well. I'm thinking that I want NATDEPFILES
and
> TDEPFILES to both have the *nto-tdep in them but then where does the
> remote-nto.c go? Any help?
>
> Sorry I'm not following you here. There's no point in listing files
> both in NATDEPFILES and TDEPFILES, since a native GDB by definition
> also includes the target stuff for the host its being built for.
Yes. Daniel J. explained this to me.
> I'm missing config/tm-qnxnto.h from the files you listed. And what
> purpose fulfills the tm-nto.h file you listed? Anyway, show me the
> complete target-stuff and let's get that integrated first!
The missing tm-qnxnto.h was an oversight - not necessary for the question I
was asking. The tm-nto.h file is necessary because configure will not build
a native debugger without it, even if it's empty. I'm trying to solve a few
annoying bugs (SOLIB_BKPT_NAME and SVR$_EXEC_EMU) first before I submit.
cheers,
Kris
next prev parent reply other threads:[~2003-02-13 22:29 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-03 20:19 Kris Warkentin
2003-02-04 7:23 ` Eli Zaretskii
2003-02-04 13:33 ` Kris Warkentin
2003-02-04 13:53 ` Kris Warkentin
2003-02-04 19:59 ` Eli Zaretskii
2003-02-04 20:12 ` Kris Warkentin
2003-02-05 5:50 ` Eli Zaretskii
2003-02-04 22:02 ` Andrew Cagney
2003-02-05 1:29 ` Kris Warkentin
2003-02-05 2:40 ` Andrew Cagney
2003-02-05 2:59 ` Andrew Cagney
2003-02-05 12:31 ` Kris Warkentin
2003-02-05 2:55 ` Andrew Cagney
2003-02-05 17:15 ` Kris Warkentin
2003-02-05 18:46 ` Andrew Cagney
2003-02-07 1:48 ` Kris Warkentin
2003-02-07 19:22 ` Mark Kettenis
2003-02-07 20:08 ` Kris Warkentin
2003-02-07 21:59 ` Andrew Cagney
2003-02-11 18:11 ` Kris Warkentin
2003-02-11 18:41 ` patch to add HAVE_CONTINUABLE_BREAKPOINT to target_ops Kris Warkentin
2003-02-12 22:18 ` patch to add QNX NTO i386 support Kris Warkentin
2003-02-12 22:44 ` Daniel Jacobowitz
2003-02-13 0:52 ` Kris Warkentin
2003-02-13 22:21 ` Mark Kettenis
2003-02-13 22:29 ` Kris Warkentin [this message]
2003-02-13 22:53 ` Mark Kettenis
2003-02-13 23:55 ` Kris Warkentin
2003-02-14 0:01 ` Kris Warkentin
2003-02-13 21:56 ` Kris Warkentin
2003-02-13 22:08 ` Daniel Jacobowitz
2003-02-13 22:25 ` Kris Warkentin
2003-02-13 22:29 ` Daniel Jacobowitz
2003-02-13 23:48 ` Kris Warkentin
2003-02-14 0:03 ` Daniel Jacobowitz
2003-02-14 0:09 ` Kris Warkentin
2003-02-14 0:13 ` Daniel Jacobowitz
2003-02-14 0:35 ` Kris Warkentin
2003-02-17 14:58 ` Andrew Cagney
2003-02-17 15:44 ` Daniel Jacobowitz
2003-02-17 16:45 ` Andrew Cagney
2003-02-17 18:54 ` Kris Warkentin
2003-02-18 21:26 ` Andrew Cagney
2003-02-18 22:30 ` Kris Warkentin
2003-02-20 0:42 ` Andrew Cagney
2003-02-27 19:02 ` Kris Warkentin
2003-02-27 19:56 ` Andrew Cagney
2003-02-27 20:02 ` Daniel Jacobowitz
2003-02-27 20:10 ` Andrew Cagney
2003-02-27 20:11 ` Kris Warkentin
2003-02-27 20:23 ` Andrew Cagney
2003-02-27 20:28 ` Kris Warkentin
2003-02-05 20:48 ` Mark Kettenis
2003-02-05 21:23 ` Kris Warkentin
2003-02-05 21:43 ` Kris Warkentin
2003-02-05 22:24 ` Mark Kettenis
2003-02-06 15:13 ` Kris Warkentin
2003-02-06 18:19 ` Andrew Cagney
2003-02-05 22:48 ` Mark Kettenis
2003-02-06 15:08 ` Kris Warkentin
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='021601c2d3af$562e07f0$0202040a@catdog' \
--to=kewarken@qnx.com \
--cc=ac131313@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=kettenis@chello.nl \
/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