From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: muller@ics.u-strasbg.fr (Pierre Muller)
Cc: gdb-patches@sourceware.org,
pedro@codesourcery.com ('Pedro Alves'),
eliz@gnu.org ('Eli Zaretskii')
Subject: Re: [RFC] Remove i386 low level debug register function from nm- header file.
Date: Tue, 12 May 2009 15:00:00 -0000 [thread overview]
Message-ID: <200905121500.n4CF0Z1B016661@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <003701c9d30f$1cea0a00$56be1e00$@u-strasbg.fr> from "Pierre Muller" at May 12, 2009 04:37:01 PM
Pierre Muller wrote:
> > This looks good to me. However, now that you've moved the
> > prototypes to i386-nat.h, there is no longer any need for
> > the config/i386/nm-i386.h file -- please get rid of that file
> > (by removing the places where it is included into other nm-
> > files).
>
> OK, but how do I commit a file deletion?
> I never did this before!
That's an easy three steps :-)
1. Delete the file in your local copy: "rm nm-i386.h"
2. Announce the deletion to CVS: "cvs remove nm-i386.h"
3. Commit the deletion (together with the rest of your changes): "cvs commit"
B.t.w. there'll be some follow-on changes, because some of the
other nm- files in config/i386 will become (nearly) empty.
If an nm- file after your changes is completely empty (e.g.
nm-go32.h), you should remove all references to it (e.g. remove
the line NAT_FILE= nm-go32.h from go32.mh) and delete the
file as well.
If an nm- file after your changes consists solely of including
some other file (e.g. nm-linux64.h which will consist solely
of including "config/nm-linux.h"), you should update the references
to this file to refer to that other file (e.g. change the line
NAT_FILE= nm-linux64.h to NAT_FILE= config/nm-linux.h in linux64.mh)
and then delete the file as well.
Your patch should bring us quite a bit closer to the goal of
completely eliminating all nm- header files! Thanks!
> > I think you should provide everything in i386-nat.c (and
> > the new i386-nat.h) unconditionally, and eliminate the
> > various definitions of I386_USE_GENERIC_WATCHPOINTS in the
> > nm- header files.
>
> The only drawback is that "maint show-debug--regs" command
> will then also appear on target that do not support
> debug registers... Anyhow, it will just be a no-op in that case.
> Is that a problem?
I don't think so. The command simply says: "whenever the hardware
debug registers are changed, display their contents". Being able
to set that flag on a system that happens to never use hardware
debug register should be fine, the condition just never occurs.
> > Here, it seems every user of windows-nat.c unconditionally
> > defines I386_USE_GENERIC_WATCHPOINTS, so there's no point in
> > adding the #ifdef's to this file ...
>
> I don't know here, the problem is that windows-nat is full of i386
> specific code that should be moved to i386-windows-nat and/or
> amd64-windows-nat so that supporting other processors will be easier.
Right. For now, this is not an issue as windows-nat.c is only used
by those three hosts:
./config/i386/mingw64.mh:NATDEPFILES= i386-nat.o windows-nat.o amd64-windows-nat.o
./config/i386/cygwin.mh:NATDEPFILES= i386-nat.o windows-nat.o i386-windows-nat.o
./config/i386/mingw.mh:NATDEPFILES= i386-nat.o windows-nat.o i386-windows-nat.o
which are all i386.
If we want to support non-i386 Windows at some point, I guess this
should be done similarly to how we support Linux hosts for different
platforms: Instead of having a global "windows_ops" structure, have
windows-nat.c provide a routine "windows_target ()" that allocates and
fills in a target structure, and passes it to its caller (which would
be i386-windows-nat.c etc.) for further customization. See how the
routine "linux_target ()" is used today ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2009-05-12 15:00 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-10 14:54 Pierre Muller
2009-05-10 17:37 ` Eli Zaretskii
2009-05-12 13:02 ` Ulrich Weigand
2009-05-12 14:37 ` Pierre Muller
2009-05-12 15:00 ` Ulrich Weigand [this message]
2009-05-12 15:17 ` Eli Zaretskii
2009-05-12 15:45 ` Pierre Muller
2009-05-12 16:06 ` Ulrich Weigand
2009-05-12 16:19 ` Pedro Alves
2009-05-12 21:28 ` [RFC-v2] " Pierre Muller
2009-05-13 15:33 ` Ulrich Weigand
2009-05-13 18:09 ` Eli Zaretskii
2009-05-13 18:35 ` Ulrich Weigand
2009-05-13 18:25 ` Doug Evans
2009-05-13 18:38 ` Ulrich Weigand
2009-05-13 22:21 ` Pierre Muller
2009-05-13 23:16 ` Doug Evans
2009-05-13 23:39 ` [RFA-v3] " Pierre Muller
2009-05-14 9:06 ` Ulrich Weigand
2009-05-14 9:10 ` Joel Brobecker
2009-05-14 9:40 ` Pierre Muller
2009-05-14 15:32 ` Macros in config files Pierre Muller
2009-05-14 18:31 ` Ulrich Weigand
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=200905121500.n4CF0Z1B016661@d12av02.megacenter.de.ibm.com \
--to=uweigand@de.ibm.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=muller@ics.u-strasbg.fr \
--cc=pedro@codesourcery.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