Re: [PATCH] Set architecture for NetBSD core files

[Mark Kettenis <kettenis at chello dot nl>]

   From: Matt Thomas <matt@3am-software.com>
   Date: Mon, 9 Feb 2004 00:53:53 -0800

   On Feb 8, 2004, at 11:52 PM, Mark Kettenis wrote:

   >    Date: Sun, 08 Feb 2004 16:46:12 -0800
   >    From: Matt Thomas <matt@3am-software.com>
   >
   >    At 03:18 PM 2/8/2004, Mark Kettenis wrote:
   >> It would make my life a lot easier if a netbsd-core BFD would have its
   >> architecture set.  The attached patch accomplishes this, at least for
   >> NetBSD/amd64, NetBSD/i386, NetBSD/sparc and NetBSD/sparc64 (and the
   >> corresponding OpenBSD variants).
   >
   >    Why?  netbsd-core.c is only used for the old a.out based core dump
   >    format.  Under NetBSD, ELF executables produce ELF core dumps.
   >    NetBSD/amd64 and NetBSD/sparc64 have *always* been ELF based.
   >    NetBSD/i386 and  NetBSD/sparc have been ELF based for several years.
   >    In fact, all NetBSD targets except ns32k use ELF.
   >
   > True, however OpenBSD still uses the traditional core file format,
   > even for ELF executables.  And my changes don't interfere with the
   > recognition of NetBSD ELF core dumps.  It shouldn't hurt for
   > traditional NetBSD core files.

   So OpenBSD uses netbsd-core.c?  That's, uh, interesting.

Well, given the fact that they share a common history, this isn't so
surprising.

   >> OK to check this in?  Or should I move the M_SPARC64_NETBSD and
   >> M_X86_64_NETBSD #defines to libaout.h?

   Upon further reflection, I've proposed that we (NetBSD) change the
   values of M_X86_64_NETBSD and M_SPARC64_NETBSD to 156 and 157,
   respectively, so they won't overlap M_MIPS1 and M_MIPS2.  It does
   incur a small amount of pain on our part but it is the right thing
   to do.

Is it really worth it?  The M_MIPS1 and M_MIPS2 seem to be used only
on really ancient stuff.  And I'll have to support M_MIPS1 as an alias
for M_SPARC64_NETBSD anyway for the sake of backwards compatibility
with previous OpenBSD/sparc64 releases.  On the other hand, an extra
"case M_MIPS1:" with an OpenBSD-specific comment isn't going to hurt
either.  So go ahead if you like.

   >    IMO, no.  While I can see doing i386 and sparc, amd64 and sparc64 
   > are
   >    not needed.  But you should also include other former a.out targets
   >    such as vax, m68k, ns32k, and arm.  (mips, alpha, and powerpc never
   >    used a.out to significant degree).
   >
   > I'd be happy to include the platforms you mention too.  It just isn't
   > necessary for my work on GDB.  And I can't test it on the other
   > platforms.

   I'd strongly encourage OpenBSD to emit ELF core files but I digress.
   OpenBSD does support most of those architecture so if you are doing GDB
   work for OpenBSD, your patch isn't complete unless it supports all the
   targets that OpenBSD supports.

It's my intention to add further entries when I add support for more
OpenBSD ports in the future.  Right now, GDB only supports
OpenBSD/i386, OpenBSD/sparc and OpenBSD/sparc64.

   Note that NetBSD and OpenBSD currently have a conflict for 154 between
   SH5_32 and HPPA.  We (NetBSD) will move SH5_32 to 158 resolving that
   conflict.

   How does that sound?

Sounds fine to me.

Mark