Re: Patches for FreeBSD 4.2

[Mark Kettenis <kettenis at wins dot uva dot nl>]

   From: Stu Grossman <grossman@juniper.net>
   Date: Thu, 12 Jul 2001 14:58:03 -0700

   Actually, I was following the linux convention (xxx-linux-yyy.c).
   But, I can fix it.

   As an aside, it would be nice to use a consistent file naming
   convention throughout GDB.  So far, we have <mach><os>-nat/tdep, or
   <mach>-<os>-nat/tdep.  Mostly, files seem to use the latter
   convention unless it's one of the BSDs, in which case they use the
   former.  Picking one convention and sticking to it would make
   things cleaner.

New files tend to use the latter convention, but let's stick to
<mach><os>-nat/dep for the BSDs.

    > * This file won't compile on FreeBSD 3.x, since <machine/sigframe.h>
    >   doesn't exist.

   I'll try to clean that up for 3.x.  It looks like in 3.x and
   earlier, struct sigframe was in <machine/frame.h>.

Looks like it, but we may not need that.

    > Besides, the implementation of a *_frame_saved_pc
    >   function belongs in a target-dependent file, and shouldn't depend on
    >   the target headers.  What's wrong with the old implementation?

   I disagree.  *_frame_saved_pc is inherently native dependent for
   most OS's as it involves looking at some kind of OS specific signal
   context structure.

Well, it's true that it's OS specific, but that doesn't mean that it's
native dependent.  A cross debugger should be able to trace back
through signal frames just as well as a native debugger.  The only
thing that's needed is that instead of relying on target headers such
as <machine/sigframe.h> to provide the necessary offsets, we must
simply hardcode the values into GDB.  That's what I did when I updated
the FreeBSD support some time ago.

Now hardcoding has a drawback.  When the signal frame layout changes
(as it did between FreeBSD 3 and FreeBSD 4) things break.  That's too
bad, but it is a change in the ABI, and there's nothing we can do
about it if we don't have the target headers available (and even then
it is problematic since the location of the relevant details is often
changed between different releases of an OS).

The best we can do is somehow override these hardcoded values when
building a native debugger.  I have an idea to implement that makes
multi-arching the i386 target easier.  It would really help if you
could send me the numerical value of PS_STRINGS on FreeBSD 4.2.

I'll go and test my version of sigtramp code a bit.  If it works, that
part of your patch will not be necessary.

   I think you are stuck with different versions of GDB anyway.  3.4
   seems to have two versions of sigcontext (the old one is called
   `osigcontext').  Sigcontext is pretty much the same as the 4.2
   version.  In any case, I don't see a good way to distinguish
   between the two versions of sigcontext.  In addition, I doubt that
   core files are compatible between 3.4 and 4.2.  So, it really looks
   like you want different builds of GDB for each OS version.

The idea of a multi-arch GDB is that it contains support for multiple
targets in a single GDB.  It might be necessary for the user to
explicitly set the target if distinguishing between them isn't
possible, but that's no reason not to add support for different
versions of FreeBSD.

    > * I think the SOFTWARE_SINGLE_STEP_P stuff can be removed from your
    >   version of child_resume.

   That is only used for an internal consistency check, which I think
   is valuable here.

It's not as important as for the generic version to have this check,
but it doesn't hurt, so feel free to leave it in.

Mark