This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Remove i386 low level debug register function from nm- header file.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]