Re: More SSE infrastructure

[Mark Kettenis <kettenis@wins.uva.nl>]

   Date: Mon, 3 Jul 2000 14:02:20 -0700
   From: Richard Henderson <rth@cygnus.com>

   [ For the GDB list, we're discussing what needs to be emitted for
     debug information for 128-bit integers used with SSE.

     Note that this is not the same as when a user has declared a proper
     128-bit vector type, which is given in the debugging information as
     a struct, but rather to the Intel API defined __m128, which does not
     define the shape of the vector (float[4], int[4], short[8], ...) and
     so is represented as a plain int.  ]

Some time ago, Jim Blandy added support for SSE/SIMD to GDB[1].  We have
the following definitions in gdbtypes.h:

/* SIMD types.  We inherit these names from GCC.  */
extern struct type *builtin_type_v4sf;
extern struct type *builtin_type_v4si;
extern struct type *builtin_type_v8qi;
extern struct type *builtin_type_v4hi;
extern struct type *builtin_type_v2si;

And appropriate initializations in gdbtypes.c.  The "default" type for
the SSE registers is builtin_type_v4sf (see
config/i386/tm-i386.h:REGISTER_VIRTUAL_TYPE(N)).  I don't know why
(you'd have to ask Jim, but I believe he's on vacation until July 10).
It would make some sense though to make the __m128 type similar to the
SSE registers.  If builtin_type_v4sf is indeed the most suitable
return type, that would probably mean emitting the debug information
as a struct.

Mark

[1] This work was supposed to work together with a Linux kernel patch
    developed by Cygnus.  The stuff recenty added to Linux 2.4.0test2
    is a bit different, and I'm in the process of changing GDB
    accordingly.  If people are interested I can post a (preliminary)
    patch.
From ac131313@cygnus.com Tue Jul 04 01:46:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: GDB 5.0.1?
Date: Tue, 04 Jul 2000 01:46:00 -0000
Message-id: <3961A434.262D29C7@cygnus.com>
X-SW-Source: 2000-07/msg00003.html
Content-length: 413

Hello,

So is an incremental release worth it?  Personally, I've no problems
with just re-spinning the head of the 5.0 branch and calling it 5.0.1
(with the NEWS file tweeked).

Beyond that, I've reservations, I'd rather see people putting more
effort into the trunk and the next major release.

Opinions?  Give it 2-4 more weeks and then just re-spin what ever is on
the head and then close the branch?

	Andrew
From ac131313@cygnus.com Tue Jul 04 02:02:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: GDB 5.1?
Date: Tue, 04 Jul 2000 02:02:00 -0000
Message-id: <3961A819.7E91AE3C@cygnus.com>
X-SW-Source: 2000-07/msg00004.html
Content-length: 3492

(Ok, so it is Tuesday, I was ment to send this out yesterday).

Now is probably the time to start to think about another GDB release. 
Should it occure, and if so when?  What should be fixed, what would be
nice to fix?

I've attatched the immediatly relevant sections of the TODO file.

While the TODO file contains many other potential I'd rather see the
emphasis on finishing a small subset of that wish list.   If others are
achieved then, that is a bonus.

	Andrew


                Known problems in GDB 5.0
                =========================

Below is a list of problems identified during the GDB 5.0 release
cycle.  People hope to have these problems fixed in a follow-on
release.

--

The BFD directory requires bug-fixed AUTOMAKE et.al.

AUTOMAKE 1.4 incorrectly set the TEXINPUTS environment variable.  It
contained the full path to texinfo.tex when it should have only
contained the directory.  The bug has been fixed in the current
AUTOMAKE sources.  Automake snapshots can be found in:
        ftp://sourceware.cygnus.com/pub/gdb/snapshots
and     ftp://sourceware.cygnus.com/pub/binutils

--

RFD: infrun.c: No bpstat_stop_status call after proceed over break?
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00665.html

GDB misses watchpoint triggers after proceeding over a breakpoint on
x86 targets.

--

x86 linux GDB and SIGALRM (???)
http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00803.html

I know there are problems with single stepping through signal
handlers.  These problems were present in 4.18.  They were just masked
because 4.18 failed to recognize signal handlers.  Fixing it is not
easy, and will require changes to handle_inferior_event(), that I
prefer not to make before the 5.0 release.

Mark

--

Revised UDP support (was: Re: [Fwd: [patch] UDP transport support])
http://sourceware.cygnus.com/ml/gdb-patches/2000-04/msg00000.html

(Broken) support for GDB's remote protocol across UDP is to be
included in the follow-on release.

--

Can't build IRIX -> arm GDB.
http://sourceware.cygnus.com/ml/gdb-patches/2000-04/msg00356.html

David Whedon writes:
> Now I'm building for an embedded arm target.  If there is a way of turning
> remote-rdi off, I couldn't find it. It looks like it gets built by default
> in gdb/configure.tgt(line 58) Anyway, the build dies in
> gdb/rdi-share/unixcomm.c.  SERPORT1 et. al. never get defined because we
> aren't one of the architectures supported.

--

Problem with weak functions
http://sourceware.cygnus.com/ml/gdb/2000-05/msg00060.html

Dan Nicolaescu writes:
> It seems that gdb-4.95.1  does not display correctly the function when
> stoping in weak functions. 
> 
> It stops in a function that is defined as weak, not in the function
> that is actualy run... 

--

GDB 5.0 doesn't work on Linux/SPARC

--

                Code Cleanups: Next Release
                ===========================

The following are small cleanups that will hopefully be completed by
the follow on to 5.0.

--

Delete macro TARGET_BYTE_ORDER_SELECTABLE.

Patches in the database.

--

Purge PARAMS.

Eliminate all uses of PARAMS in GDB's source code.

--

Fix copyright notices.

Turns out that ``1998-2000'' isn't considered valid :-(

http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00467.html

--

Find something better than DEFAULT_BFD_ARCH, DEFAULT_BFD_VEC to
determine the default isa/byte-order.

--

Rely on BFD_BIG_ENDIAN and BFD_LITTLE_ENDIAN instead of host dependant
BIG_ENDIAN and LITTLE_ENDIAN.

--
From kettenis@wins.uva.nl Tue Jul 04 02:08:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: ac131313@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: GDB 5.0.1?
Date: Tue, 04 Jul 2000 02:08:00 -0000
Message-id: <200007040908.e6498WG00704@delius.kettenis.local>
References: <3961A434.262D29C7@cygnus.com>
X-SW-Source: 2000-07/msg00005.html
Content-length: 881

   Date: Tue, 04 Jul 2000 18:45:40 +1000
   From: Andrew Cagney <ac131313@cygnus.com>

   Hello,

   So is an incremental release worth it?  Personally, I've no problems
   with just re-spinning the head of the 5.0 branch and calling it 5.0.1
   (with the NEWS file tweeked).

   Beyond that, I've reservations, I'd rather see people putting more
   effort into the trunk and the next major release.

   Opinions?  Give it 2-4 more weeks and then just re-spin what ever is on
   the head and then close the branch?

IMHO, releasing 5.0.1 is only worth the trouble if it fixes the really
annoying problem with rerunning programs with breakpoints in shared libs:

   http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00230.html

This patch is kind of a stopgap, but I've failed to come up with
something better, and no-one else seems to be interested in solving
this :-(.

Mark
From muller@cerbere.u-strasbg.fr Tue Jul 04 02:21:00 2000
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: Andrew Cagney <ac131313@cygnus.com>, GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: GDB 5.1?
Date: Tue, 04 Jul 2000 02:21:00 -0000
Message-id: <200007040921.LAA17498@cerbere.u-strasbg.fr>
X-SW-Source: 2000-07/msg00006.html
Content-length: 766

  I just wanted to remind people that the current state for pascal language
is really odd:

  - the language is defined
(you can type 
"set language pascal")

  - default source extensions are recognized

but the main part of my patch (that already is in GDB CVS tree)
is not active because the new files are not compiled nor link into GDB.

  I sent this to gdb-patches under
http://sourceware.cygnus.com/ml/gdb-patches/2000-06/msg00214.html

  I wanted to get reaction from people trying this out, as I am uncertain
about some code parts especially in cross platform configurations.


 


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 eliz@delorie.com Tue Jul 04 08:19:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ac131313@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: GDB 5.1?
Date: Tue, 04 Jul 2000 08:19:00 -0000
Message-id: <200007041519.LAA19774@indy.delorie.com>
References: <3961A819.7E91AE3C@cygnus.com>
X-SW-Source: 2000-07/msg00007.html
Content-length: 470

> Date: Tue, 04 Jul 2000 19:02:17 +1000
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> Now is probably the time to start to think about another GDB release. 
> Should it occure, and if so when?  What should be fixed, what would be
> nice to fix?

What about rearranging the source tree so as to avoid file-name
problems on 8+3 filesystems, and get rid of the ugly fnchange.lst
kludge?  I volunteer to suggest the new structure if people agree with
making this happen.
From ac131313@cygnus.com Tue Jul 04 19:37:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb@sourceware.cygnus.com
Subject: Re: GDB 5.1?
Date: Tue, 04 Jul 2000 19:37:00 -0000
Message-id: <39629F3A.A205EEA5@cygnus.com>
References: <3961A819.7E91AE3C@cygnus.com> <200007041519.LAA19774@indy.delorie.com>
X-SW-Source: 2000-07/msg00008.html
Content-length: 1410

Eli Zaretskii wrote:
> 
> > Date: Tue, 04 Jul 2000 19:02:17 +1000
> > From: Andrew Cagney <ac131313@cygnus.com>
> >
> > Now is probably the time to start to think about another GDB release.
> > Should it occure, and if so when?  What should be fixed, what would be
> > nice to fix?
> 
> What about rearranging the source tree so as to avoid file-name
> problems on 8+3 filesystems, and get rid of the ugly fnchange.lst
> kludge?  I volunteer to suggest the new structure if people agree with
> making this happen.

Possibly too much change :-(  5.1 is already going to see (assuming
KevinB keeps up his blistering pace) an almost pure ISO-C source tree. 
The other big ticket items on the table is auto-make-a-fying GDB and
enabling MI, I'd like to pace things a little :-)

I suspect that by 5.2 (Summer 00/01 time frame (1) :-) it is going to be
far clearer as to what is going to be in and what is going to be out. 
Things I suspect are out (to be deleted) include:

	config/*/xm-*.h
		subsumed by autoconf?
	config/*/tm-*.h
		kind of useless when all it
		contains is:
		#define GDB_MULT_ARCH 1
	all the obsolete code will be gone

similarly there is the question of how to correctly break down the
*-tdep.c files.

To address the immediate concerns, I'll get around to tweeking the build
process so that it verifies fnchange.lst.

	Andrew

(1) For the geographically challenged, I mean December-March ;-)
From rth@cygnus.com Wed Jul 05 00:16:00 2000
From: Richard Henderson <rth@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: bernds@masala.cygnus.co.uk, gcc-patches@gcc.gnu.org, gdb@sourceware.cygnus.com
Subject: Re: More SSE infrastructure
Date: Wed, 05 Jul 2000 00:16:00 -0000
Message-id: <20000705001646.B27048@cygnus.com>
References: <20000703122133.F25642@cygnus.com> <Pine.LNX.3.96.1000703211132.12211A-100000@masala.cygnus.co.uk> <20000703140220.A25809@cygnus.com> <200007040019.e640Jwe00432@delius.kettenis.local>
X-SW-Source: 2000-07/msg00009.html
Content-length: 1543

On Tue, Jul 04, 2000 at 02:19:58AM +0200, Mark Kettenis wrote:
> It would make some sense though to make the __m128 type similar to the
> SSE registers.

I don't agree.  If you wanted v4sf, you can use v4sf in the source.
Though not, admittedly, with Intel's interface.  But you can get it
from GCC easily enough.

In any case, the question at hand has absolutely nothing to do with
SSE specifically, but rather what we should give GDB for describing
a 128-bit integer.

The GCC infrastructure currently prohibits representing full 
arithmetic on items larger than twice the host word size.  If you
take away the actual arithmetic, and just manipulate the things as
data (movement and such), then the only thing left in GCC that 
appears to have problems is debugging.

The current solution in the Cygnus tree is to force the use of
long long as the `host' word size.  Which slows down the compiler
significantly.  We're trying to figure a way out of that.

So, the object being, fix the debugging code to cope with integer
objects larger than twice the host word size.  And in order to do
that, we need to know what GDB needs to do its job.

In the original message I sent, perhaps only to the GCC list (oops),
I quoted a fragment from the stabs emitter, wherein we look to see
if it's easy to print the upper bound for the type.  If it isn't
easy, we just print -1.

So the question is, do we really have to print the correct upper
and lower bounds for the 128-bit type, or can we just use 0 and -1,
as the existing code would suggest.


r~
From gordo0678@quepasa.com Wed Jul 05 03:58:00 2000
From: <gordo0678@quepasa.com>
To: gdb@sourceware.cygnus.com
Subject: This company plans to be in Wireless
Date: Wed, 05 Jul 2000 03:58:00 -0000
Message-id: <785.877911.803411@quepasa.com>
X-SW-Source: 2000-07/msg00010.html
Content-length: 442

Inform Worldwide, Inc. , a leader in commercial location technologies,  
plans to focus its proprietary  GPS technologies on  the Wireless Industry. ( ANYI )

Come Learn More
http://www.investwise.org.uk/anyi1.html

 




You were sent this message because your address is in our subscriber database. 
If you wish to be removed, please reply here; http://www.investwise.org.uk/response.html and we will remove you from our subscriber list.