From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pierre Muller To: gdb@sourceware.cygnus.com Subject: go32-nat.c compilation problem Date: Mon, 08 Nov 1999 08:54:00 -0000 Message-id: <199911081709.SAA23904@cerbere.u-strasbg.fr> References: <01> <1999> <14:25:01> <+0100> <381D94AD.B37EC167@grafzahl.de> X-SW-Source: 1999-q4/msg00221.html 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 To: Pierre Muller 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: <01> <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 To: Elena Zannoni Cc: Pierre Muller , Stan Shebs , 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 To: Eli Zaretskii Cc: Elena Zannoni , Pierre Muller , Stan Shebs , 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 To: Mark Kettenis , Eli Zaretskii , Chris Faylor , "J. T. Conklin" , "J. Kean Johnston" , "H. J. Lu" 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 To: Jim Blandy Cc: Mark Kettenis , Eli Zaretskii , "J. T. Conklin" , "J. Kean Johnston" , "H. J. Lu" , 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 To: Eli Zaretskii Cc: Stan Shebs , 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 To: Chris Faylor Cc: Mark Kettenis , Eli Zaretskii , "J. T. Conklin" , "J. Kean Johnston" , "H. J. Lu" , gdb@sourceware.cygnus.com Subject: Re: i386: Are we settled? Date: Mon, 08 Nov 1999 17:34:00 -0000 Message-id: 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 To: Jim Blandy Cc: Mark Kettenis , Eli Zaretskii , "J. T. Conklin" , "J. Kean Johnston" , "H. J. Lu" , 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> 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 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." 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