Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@chello.nl>
To: rmh@debian.org
Cc: neroden@twcny.rr.com, gdb-patches@sources.redhat.com,
	glibc-bsd-hackers@nongnu.org
Subject: Re: [PATCH] GNU/k*BSD fixes [w/ChangeLog]
Date: Mon, 09 Aug 2004 17:48:00 -0000	[thread overview]
Message-ID: <200408091748.i79HmXOS038567@elgar.kettenis.dyndns.org> (raw)
In-Reply-To: <20040809162831.GD2417@khazad.dyndns.org> (message from Robert Millan on Mon, 9 Aug 2004 18:28:31 +0200)

   Date: Mon, 9 Aug 2004 18:28:31 +0200
   From: Robert Millan <rmh@debian.org>

   Asides GNU/kFreeBSD I'm not aware of other non-FreeBSD systems
   using kernel of FreeBSD.  Wrt different versions of FreeBSD, I
   can't be completely sure some arcane version of FreeBSD didn't have
   osreldate.h.

   I propose the following alternative, which also looks cleaner:

   #ifdef HAVE_SYS_PARAM_H
   #include <sys/param.h> /* __FreeBSD_{kernel_,}version */
   #endif
   #if defined(__FreeBSD__) && !defined(__FreeBSD_kernel__)
   # define __FreeBSD_kernel__ __FreeBSD__
   # define __FreeBSD_kernel_version __FreeBSD_version
   #endif

   (note: osreldate.h and sys/param.h are equivalent for this purpose)

Indeed <sys/param.h> defenitely exists on all FreeBSD systems, and is
the official way to get the defined we're talking about here.

   On Mon, Aug 09, 2004 at 08:59:20AM +0200, Mark Kettenis wrote:
   > 
   > Yuck, the #ifdef mess in i386bsd-nat.c gets ugly.  I think it should
   > be simplified.

   Does the proposed alternative above address this concern?

Not really.  I'm sort of bending the rules in i386bsd-nat.c by
checking the version numbers.  By adding more to it, I run the risk
that people start noticing it ;-).  Anyway, this code is not really
adding any functionality.  It's just a bunch of consistency checks,
that you can perfectly well do without.

   > You're probably changing it to avoid the warning about
   > the offsets in `struct sigcontext'.  If I just drop the support for
   > ancient BSD (which isn't used anyway) we can avoid that.  You won't
   > get the extra check on GNU/kFreeBSD then, but as long as enough people
   > use GDB on normal FreeBSD/i386, this doesn't really matter.

   The oldest version of kFreeBSD we ever supported is 4.6, so compatibility
   with 3.x is not an issue for us.  If you want to drop support for 3.x, that
   is fine with me.

I'm talking about dropping support for pre-FreeBSD-BSD here, which
actually isn't supported.  I'll remove that stuff and you can forget
about the #ifdefs.

   > I assume that GNU/k*BSD
   > still has libkvm.  Why doesn't it have <nlist.h>?  If not, then where
   > does it get its `struct nlist' from?

   We have libkvm, but not nlist() which is not part of Glibc.  I'm considering
   adding nlist() and other functions in a compatibility library (e.g. libbsd),
   though.

IIRC the Hurd once had such a compatibility library.  Anyway ...

   But I was surprised that disabling the '#include <nlist.h>' didn't cause the
   build process to fail on missing declarations.  Does bsd-kvm.c really work
   without nlist, or am I missing something?

It only needs the definition of `struct nlist'.  If something else
provides that (presumably your <kvm.h> has been hacked to do that)
everything is fine.  I'll add the #ifdef HAVE_NLIST_H.  It can't hurt.

Mark


  reply	other threads:[~2004-08-09 17:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-07  2:20 Robert Millan
2004-08-09  6:59 ` Mark Kettenis
2004-08-09 16:32   ` Robert Millan
2004-08-09 17:48     ` Mark Kettenis [this message]
2004-08-09 19:19       ` Robert Millan
2004-08-09 21:25         ` Mark Kettenis
2004-08-09 22:34           ` Robert Millan
2004-08-09  3:59 Nathanael Nerode

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=200408091748.i79HmXOS038567@elgar.kettenis.dyndns.org \
    --to=kettenis@chello.nl \
    --cc=gdb-patches@sources.redhat.com \
    --cc=glibc-bsd-hackers@nongnu.org \
    --cc=neroden@twcny.rr.com \
    --cc=rmh@debian.org \
    /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