From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: GDB Discussion Subject: nm.h, *-nat.c and multi-arch? Date: Wed, 04 Jul 2001 09:12:00 -0000 Message-id: <3B43404E.6090805@cygnus.com> X-SW-Source: 2001-07/msg00024.html Hello, I'm trying to eliminate xm.h, tm.h and possibly nm.h. Part of that is actually understanding what should and what should not be in a nm.h and *-nat.c. xm.h is pretty easy, it can be replaced by autoconf magic. As they say, It is now ``done stage 7 - it was seen to work once'' (cf NetBSD/PPC). tm.h is also straight forward. It has been replaced by the gdbarch vector (gdbarch.h/c) and extra *-tdep.c code. nm.h and *-nat.c, however are more interesting. Studying the code I think it has been used for: o interface code to make procfs, ptrace, ... work See below. o Stuff that should have been put in the xm file. I'll pretend this didn't happen :-) o Stuff that should have been put in a tm file. Ditto :-) o OS specific info for standard features (core file, shared libraries, ...). This is now also being moved to gdbarch and being made host independant. It is definitly a WIP though. See wart below. o customize to enable extra (OS/arch specific?) features. (The i386 hw breakpoint code comes to mind.) Here again, I think this should really be host independant. See wart below. Ignoring the warts, this just leaves the the first case. As best as I can tell, the only things that, strictly speaking, should be in nm.h and *-nat.c are macros/functions that enable the native interface code (procfs, ptrace, ...). Having an nm.h for those files is probably ok since procfs.[hc] is HOST=TARGET specific. Anyway, this in turn begs the (for the moment largely accademic) question should procfs.c et.al. include nm.h directly instead of having defs.h include it. -- The wart? So far multi-arch has concentrated on problems like: MIPS2 embedded MIPS3 embedded but has avoided cases such as: Linux/MIPS native and remote MIPS embedded *BSD/MIPS remote i.e. OS as well as ISA/ABI as a variant. For nm.h to be reduced to just _native_ interface support, multi-arch will need to be extended to include this. Andrew