go32-nat.c compilation problem

[Pierre Muller <muller@cerbere.u-strasbg.fr>]

  Trying to compile go32-nat.c I ran into the problem that
that file uses fatal function which is not defined anymore in gdb directory !

  Replacing it by error allowed me to compile the code but 
what should be the replacement of fatal function ??


Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99
From ezannoni@cygnus.com Mon Nov 08 09:02:00 1999
From: Elena Zannoni <ezannoni@cygnus.com>
To: Pierre Muller <muller@cerbere.u-strasbg.fr>
Cc: gdb@sourceware.cygnus.com
Subject: go32-nat.c compilation problem
Date: Mon, 08 Nov 1999 09:02:00 -0000
Message-id: <14375.536.118347.328812@kwikemart.cygnus.com>
References: <Daniel> <Vogel's> <message> <of> <Mon,> <01> <Nov> <1999> <14:25:01> <+0100> <381D94AD.B37EC167@grafzahl.de> <199911081709.SAA23904@cerbere.u-strasbg.fr>
X-SW-Source: 1999-q4/msg00222.html
Content-length: 566

Pierre Muller writes:
 > 
 >   Trying to compile go32-nat.c I ran into the problem that
 > that file uses fatal function which is not defined anymore in gdb directory !
 > 
 >   Replacing it by error allowed me to compile the code but 
 > what should be the replacement of fatal function ??
 > 
 > 
 > Pierre Muller
 > Institut Charles Sadron
 > 6,rue Boussingault
 > F 67083 STRASBOURG CEDEX (France)
 > mailto:muller@ics.u-strasbg.fr
 > Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99

I believe you need to change fatal() to internal_error().

Elena Zannoni
From eliz@gnu.org Mon Nov 08 09:43:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: Pierre Muller <muller@cerbere.u-strasbg.fr>, Stan Shebs <shebs@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: go32-nat.c compilation problem
Date: Mon, 08 Nov 1999 09:43:00 -0000
Message-id: <199911081742.MAA20623@mescaline.gnu.org>
References: <199911081709.SAA23904@cerbere.u-strasbg.fr> <14375.536.118347.328812@kwikemart.cygnus.com>
X-SW-Source: 1999-q4/msg00223.html
Content-length: 385

> I believe you need to change fatal() to internal_error().

WIBNI, when a function is renamed or removed from the sources,
somebody would grep all the sources and change all the callers, or
least alert the various platform maintainers that a function used by
their code is going to become extinct?

(If such a message *was* indeed posted in this case, I apologize for
not seeing it.)
From ezannoni@cygnus.com Mon Nov 08 10:17:00 1999
From: Elena Zannoni <ezannoni@cygnus.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Elena Zannoni <ezannoni@cygnus.com>, Pierre Muller <muller@cerbere.u-strasbg.fr>, Stan Shebs <shebs@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: go32-nat.c compilation problem
Date: Mon, 08 Nov 1999 10:17:00 -0000
Message-id: <14375.5038.377535.816858@kwikemart.cygnus.com>
References: <199911081709.SAA23904@cerbere.u-strasbg.fr> <14375.536.118347.328812@kwikemart.cygnus.com> <199911081742.MAA20623@mescaline.gnu.org>
X-SW-Source: 1999-q4/msg00224.html
Content-length: 779

Eli Zaretskii writes:
 > 
 > > I believe you need to change fatal() to internal_error().
 > 
 > WIBNI, when a function is renamed or removed from the sources,
 > somebody would grep all the sources and change all the callers, or
 > least alert the various platform maintainers that a function used by
 > their code is going to become extinct?
 > 
 > (If such a message *was* indeed posted in this case, I apologize for
 > not seeing it.)
 > 

Eli, I see what happened.
Fatal() was deleted, and then changes to go32-nat.c were made that
reintroduced calls to fatal(). I believe the changes were part of a patch
you submitted, *before* the function fatal was replaced by internal_error().

This is a consequence of not having applied the patch sooner. Our fault.
Apologies.

Elena
From jimb@cygnus.com Mon Nov 08 16:18:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>, Eli Zaretskii <eliz@gnu.org>, Chris Faylor <cgf@cygnus.com>, "J. T. Conklin" <jtc@redbacknetworks.com>, "J. Kean Johnston" <jkj@sco.com>, "H. J. Lu" <hjl@valinux.com>
Cc: gdb@sourceware.cygnus.com
Subject: i386: Are we settled?
Date: Mon, 08 Nov 1999 16:18:00 -0000
Message-id: <199911090018.TAA12933@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00225.html
Content-length: 1468

Are we settled on the essential contents of tm-i386.h?  Can we start
removing the little [regs] and [fpregs] boxes from
http://sourceware.cygnus.com/gdb/papers/linux/i386-includes.png ?

Essentially, I see two outstanding questions remaining:

- How should i386 targets handle the x86 FPU's 80-bit float type?  How
  can we make sure that hosts capable of handling it properly don't
  perform lossy conversions?

- What format should the output from "info float" take?  (Actually, it
  sounds like this is pretty much resolved.)

Notably missing from this list are any other questions about tm-i386.h
as it stands.  Am I correct in thinking that the other x86 port
maintainers think it's basically sane?

If so, I encourage folks to start deleting stuff from their more
specialized tm-*.h files, and using the definitions in tm-i386.h.
It's been done for Linux and the HURD, so it's had some testing, but
if the definitions there don't please you, and not for some odd
platform-specific reason, then we don't yet have a consensus, and I
would like to continue talking about what you do want in tm-i386.h.

(Again, I'm excluding issues related to `long double'; I do expect
folks to retain their own definitions for coping with that.)

I'd specifically like responses from the people addressed directly in
the "To:" header --- those are the people who look to me most likely
to be doing the work for a specific platform, and/or who have
participated in the discussion.
From cgf@cygnus.com Mon Nov 08 16:21:00 1999
From: Chris Faylor <cgf@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, Eli Zaretskii <eliz@gnu.org>, "J. T. Conklin" <jtc@redbacknetworks.com>, "J. Kean Johnston" <jkj@sco.com>, "H. J. Lu" <hjl@valinux.com>, gdb@sourceware.cygnus.com
Subject: Re: i386: Are we settled?
Date: Mon, 08 Nov 1999 16:21:00 -0000
Message-id: <19991108192442.B2703@cygnus.com>
References: <199911090018.TAA12933@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00226.html
Content-length: 504

On Mon, Nov 08, 1999 at 07:18:11PM -0500, Jim Blandy wrote:
>- What format should the output from "info float" take?  (Actually, it
>  sounds like this is pretty much resolved.)

Did we resolve that there would be a generic routine for displaying the
stuff from "info float"?

>Notably missing from this list are any other questions about tm-i386.h
>as it stands.  Am I correct in thinking that the other x86 port
>maintainers think it's basically sane?

AFAICT, the plan makes sense.  Let's do it.

cgf
From ac131313@cygnus.com Mon Nov 08 16:22:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Stan Shebs <shebs@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: go32-nat.c compilation problem
Date: Mon, 08 Nov 1999 16:22:00 -0000
Message-id: <382768ED.EC306A06@cygnus.com>
References: <199911081709.SAA23904@cerbere.u-strasbg.fr> <14375.536.118347.328812@kwikemart.cygnus.com> <199911081742.MAA20623@mescaline.gnu.org>
X-SW-Source: 1999-q4/msg00227.html
Content-length: 689

Eli Zaretskii wrote:
> 
> > I believe you need to change fatal() to internal_error().
> 
> WIBNI, when a function is renamed or removed from the sources,
> somebody would grep all the sources and change all the callers, or
> least alert the various platform maintainers that a function used by
> their code is going to become extinct?
> 
> (If such a message *was* indeed posted in this case, I apologize for
> not seeing it.)

See the thread
http://sourceware.cygnus.com/ml/gdb-patches/1999-q3/msg00108.html
fatal() -> internal_error() jumbo patch

At the time J.T.C identifed one file I missed - .gdbinit.

As Elena noted, it came about as a result of crossed patches.

	sorry,
		Andrew
From jimb@cygnus.com Mon Nov 08 17:34:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Chris Faylor <cgf@cygnus.com>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, Eli Zaretskii <eliz@gnu.org>, "J. T. Conklin" <jtc@redbacknetworks.com>, "J. Kean Johnston" <jkj@sco.com>, "H. J. Lu" <hjl@valinux.com>, gdb@sourceware.cygnus.com
Subject: Re: i386: Are we settled?
Date: Mon, 08 Nov 1999 17:34:00 -0000
Message-id: <npogd4h2i7.fsf@zwingli.cygnus.com>
References: <199911090018.TAA12933@zwingli.cygnus.com> <19991108192442.B2703@cygnus.com>
X-SW-Source: 1999-q4/msg00228.html
Content-length: 652

> >- What format should the output from "info float" take?  (Actually, it
> >  sounds like this is pretty much resolved.)
> 
> Did we resolve that there would be a generic routine for displaying the
> stuff from "info float"?

Yep.  Mark has written an implementation.  There have been comments
and suggestions, but no major objections.  I think there are copyright
issues to be resolved.

> >Notably missing from this list are any other questions about tm-i386.h
> >as it stands.  Am I correct in thinking that the other x86 port
> >maintainers think it's basically sane?
> 
> AFAICT, the plan makes sense.  Let's do it.

Okay.  One down, five to go.
From cgf@cygnus.com Mon Nov 08 17:54:00 1999
From: Chris Faylor <cgf@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, Eli Zaretskii <eliz@gnu.org>, "J. T. Conklin" <jtc@redbacknetworks.com>, "J. Kean Johnston" <jkj@sco.com>, "H. J. Lu" <hjl@valinux.com>, gdb@sourceware.cygnus.com
Subject: Re: i386: Are we settled?
Date: Mon, 08 Nov 1999 17:54:00 -0000
Message-id: <19991108205721.A1683@cygnus.com>
References: <199911090018.TAA12933@zwingli.cygnus.com> <19991108192442.B2703@cygnus.com> <npogd4h2i7.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00229.html
Content-length: 513

On Mon, Nov 08, 1999 at 08:34:08PM -0500, Jim Blandy wrote:
>
>> >- What format should the output from "info float" take?  (Actually, it
>> >  sounds like this is pretty much resolved.)
>> 
>> Did we resolve that there would be a generic routine for displaying the
>> stuff from "info float"?
>
>Yep.  Mark has written an implementation.  There have been comments
>and suggestions, but no major objections.  I think there are copyright
>issues to be resolved.

Ah, that's right.  I remember seeing this now.

cgf
From jimb@cygnus.com Mon Nov 08 23:06:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: MMX: Messy Multimedia eXtensions
Date: Mon, 08 Nov 1999 23:06:00 -0000
Message-id: <199911090706.CAA13120@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00230.html
Content-length: 9093

Intel has contracted with Cygnus to provide support for the MMX and
SSE registers in the GNU toolchain.  We've just finished the beta.
The work is on a branch at the moment, so it won't be showing up in
snapshots.  I'd like to explain what I did in GDB, and get folks'
criticisms and ideas for what we would be happy with in mainline GDB.
There are some exquisitely twisted problems here.

If someone wants to really scrutinize my code, then I can post diffs.

In GCC, you can now write code like this (toy example, not tested):

    /* This declares the type V4SF to be a vector of four single-precision
       floats, in a way that encourages GCC to map it onto the Pentium-III
       SSE registers.  */
    typedef int v4sf __attribute__ ((mode(V4SF)));

    /* Given a bunch of points (X[i], Y[i]), 0 <= i < N, rotate
       each one clockwise by ANGLE radians.  For simplicity's sake,
       N must be a multiple of four.  */
    void
    rotate (double angle, int n, float *x, float *y)
    {
      int i;

      /* Load all four slots of these with the sin and cos of angle.  */
      v4sf cos_angle = __builtin_ia32_setps1 (cos (angle));
      v4sf sin_angle = __builtin_ia32_setps1 (sin (angle));

      /* Rotate all the points, four at a time.  */
      for (i = 0; i < n; i += 4)
	{
	  /* new_x = cos (angle) * x - sin (angle) * y
	     new_y = sin (angle) * x + cos (angle) * y */
	  v4sf x4 = __builtin_ia32_loadaps (x + i);
	  v4sf y4 = __builtin_ia32_loadaps (y + i);
	  v4sf new_x4
	    = __builtin_ia32_subps (__builtin_ia32_mulps (cos_angle, x4),
				    __builtin_ia32_mulps (sin_angle, y4));
	  v4sf new_y4
	    = __builtin_ia32_addps (__builtin_ia32_mulps (sin_angle, x4),
				    __builtin_ia32_mulps (cos_angle, y4));

	  __builtin_ia32_storeaps (x + i, new_x4);
	  __builtin_ia32_storeaps (y + i, new_y4);
	}
    }

All the v4sf values get mapped onto SSE registers automatically, and
the __builtin_ia32_foo forms turn into single SSE instructions.  It's
very sexy.  (Automatic vectorization would be even sexier, of course,
but that's another day.)

In GDB, you can now debug code like this (real example):


    (gdb) break *0x0804846b
    Breakpoint 1 at 0x804846b: file sse-mandel.c, line 42.
    (gdb) run
    Starting program: /home/jimb/play/sse-mandel 

    Breakpoint 1, 0x804846b in iter.aligned () at sse-mandel.c:42
    (gdb) next
    iter.aligned () at sse-mandel.c:43
    (gdb) p count
    $1 = {f = {1, 1, 1, 1}}
    (gdb) p countadd
    $2 = {f = {0, 0, 0, 0}}
    (gdb) p countadd
    $3 = {f = {1, 1, 1, 1}}
    (gdb) p zx
    $4 = {f = {-2.5, -2.482337, -2.464674, -2.44701076}}
    (gdb) p zy
    $5 = {f = {-1.25, -1.25, -1.25, -1.25}}
    (gdb) p countadd
    $6 = {f = {1, 1, 1, 1}}
    (gdb) set countadd.f[1] = 0
    (gdb) p countadd
    $7 = {f = {1, 0, 1, 1}}
    (gdb) 

If you want to print SSE registers, you can:

    (gdb) p $xmm3
    $14 = {f = {-2.5, -2.482337, -2.464674, -2.44701076}}

You can print MMX registers, too, but it's messier, since GDB doesn't
know whether it's eight 8-bit values, four 16-bit values, et cetera:

    (gdb) p $mm2
    $1 = {v8qi = {f = "\001\000\001\000\001\000\001"}, v4hi = {f = {1,
      1, 1, 1}}, v2si = {f = {65537, 65537}}, uint64 = 281479271743489}

(Please ignore the fact that the eight 8-bit integers are printed as
characters.  I'm going to fix that.)

The SSE work is pretty uncontroversial.  I think there's basically one
right way to do this.  The only unusual step is to assign the
appropriate virtual type to the registers --- choose something like

	struct __builtin_v4sf { float f[4]; };

and everything just works.

The MMX arrangement, however, is controversial.  That's what I'd like
people's criticism and comments on.

There are eight MMX registers, 64 bits long each.  They're actually
not new registers --- they occupy the 64-bit mantissas of the eight
floating-point registers.  The MMX registers map to physical FP
registers; the correspondence is unaffected by the FPU's top-of-stack
register.

The interaction between the MMX instructions and the FPU is odd.
Whenever you read or write an MMX register, the processor sets the
FPU's TOS to zero, and marks all FP registers as "Valid".  That is,
the stack is now full.  If you write an MMX register, the processor
sets the corresponding FP register's upper 16 bits to 0xffff.  (I
think this is a quiet NaN.)

So, how should we represent the MMX registers in GDB's register file?
There are two basic approaches:
- Assign them register numbers separate from the FP stack registers'.
- Assign them the same numbers as the FP stack registers, and treat them as
  an alternative way of looking at the FP registers' mantissas.

The first approach has some problems.
- Do you assign the MMX registers a separate region of the register
  file as well?
  - If so, when your target-specific code writes back GDB register values to
    the inferior, which copy does it write --- the FP registers, or the
    MMX registers?
  - If the user assigns to an FP stack register, the corresponding MMX
    registers' contents must be updated.  Is that handled in
    architecture-specific code?  Via what interface to the
    architecture-independent code?  How can that interface be designed
    so that future hackers, perhaps innocent of the delights of the
    x86, won't break it?  Would *you* expect writing register 12 to
    affect the value, in GDB's register file, of register 42?

I think this approach is fundamentally wrong, because the register
file doesn't match reality.  There are not really two separate sets of
bits --- the FP mantissas and the MMX registers are the same object.
If our model doesn't reflect that, we're going to be perpetually
discovering bugs with no correct solution.  I hate that.

The second approach is the one I took.  The typing information
provided by the compiler tells GDB how to interpret the register's
bits anyway.  The only wrinkle is that the FP registers are
REGISTER_CONVERTIBLE, so REGISTER_CONVERT_TO_{VIRTUAL,RAW} need to
expect MMX types as well as FP types.  They simply memcpy them.
With this approach, the register file accurately reflects the reality:
there is only one set of bits.

To let people access the MMX registers using names like `$mm2', I
added a new thing, "register views".  Register views allow you see a
register's bits using different types, depending on the name you call
it.

When the parser sees `$FOO', after checking whether `FOO' is a
register name, it calls the architecture-defined macro
IS_REGISTER_VIEW_NAME.  This macro either returns -1, meaning that it
doesn't recognize the name, or a register view number.  The macros
REGISTER_VIEW_REGNO and REGISTER_VIEW_TYPE map this register view
number to an ordinary register number, and a type to apply to that
register.  So for the x86, we have register views named "mm0", "mm1",
and so on, for which REGISTER_VIEW_REGNO returns FP0_REGNUM,
FP0_REGNUM + 1, and so on, and for which REGISTER_VIEW_TYPE returns an
appropriate union type for MMX registers.  There is a new expression
op, OP_REGISTER_VIEW, which works much like OP_REGISTER, but uses
REGISTER_VIEW_TYPE insead of REGISTER_VIRTUAL_TYPE.

I think this concept is useful for other architectures, too.  You
could use register views to provide more helpful interpretations of
control registers.  For example, perhaps a new register view $ftos
could apply the type
  struct { :10; unsigned int tos:3 }
to $fstat, or $fprec could apply the type
  struct { :7; enum { single, reserved, double, extended } pc:2; }
to $fctrl.  Thus:

    (gdb) print $ftos
    $1 = 3
    (gdb) print $fprec
    $2 = extended

Or something like that.

But, getting back to the MMX registers...

The problem is, we're using the same register number for %mm0 and
%st(0), but %mm0 doesn't really correspond to %st(0).  It depends on
the value of the FPU TOS register.  However, every MMX instruction
does reset TOS to zero.  And you can't really mix FP and MMX code very
effectively; the processor's behavior (marking the stack as full;
resetting TOS) seems designed to prevent this, without actually losing
data.  So it's almost always right.

Another problem is, we've added an entirely new concept --- register
views --- which affects the parser and the evaluator.  But the changes
are simple and straightforward, and they could be useful on other
architectures, if you want to view a single register 

Still, though, it's not quite right.  All the information is available
to do the job perfectly --- we have the TOS in $fctrl and everything.
And for something which requires (even simple) changes to the parser,
expression evaluator, and everything else that touches expressions,
you'd like to get perfection.

The real obstacle is the assumption, pervasive in GDB, that each
distinct register is an independent part of the machine state.  This
makes it very difficult to implement a truly accurate solution.  I
don't really know how to work around that.

So, I'm interested in folks' opinions on the current support, and
ideas on how to do better.  How should we do this?
From lplos@essegi.net Tue Nov 09 03:06:00 1999
From: "Livio Plos - Essegi s.r.l." <lplos@essegi.net>
To: gdb@sourceware.cygnus.com
Subject: PPC gdb stub
Date: Tue, 09 Nov 1999 03:06:00 -0000
Message-id: <3.0.6.32.19991109120052.007e9bf0@titano>
X-SW-Source: 1999-q4/msg00231.html
Content-length: 138

Can anyone help me, pointing me a site where I can
find sources for a power pc gdb stub (resident debug monitor)?

Thank you.
Livio Plos