Re: More SSE infrastructure

Re: More SSE infrastructure

[Richard Henderson]

[ 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.  ]

On Mon, Jul 03, 2000 at 09:14:52PM +0100, Bernd Schmidt wrote:
> On Mon, 3 Jul 2000, Richard Henderson wrote:
> > On Mon, Jul 03, 2000 at 07:08:34PM +0100, Bernd Schmidt wrote:
> > > ... the only place in the compiler I've found so far that relies
> > > on it is debugging output (where TImode constants are used for
> > > TYPE_{MIN,MAX}_VALUE of 128 bit integers.
> > 
> > I wonder if we can just bail on that?
> 
> Possibly.  I don't know for what the debugger could use this information.

Neither do I.  It seems relatively certain that the debugger isn't going
to allow us to evaluate 128-bit int expressions; what other use of the
bounds of the type I don't know.  Why it would even need to be told the
bounds, given the size of the type and its signedness I don't know. 
(Possibly to represent pascal-like integer subranges?)

> If you think that's OK, we could leave out that part for now.

I don't think we can do nothing right now.  We need to come to agreement
with the gdb folks what would be acceptible. 

If we need to emit *something*, it would be possible for us to put
code in at this point to recognize that TYPE_{SIZE,PRECISION} is out
of range for what an INTEGER_CST could represent, and emit the max
bounds by hand, in octal, based on the known size of the type.


r~

PS: Oh, you'll have to watch type_for_mode, which does 

	#if HOST_BITS_PER_WIDE_INT >= 64
	  if (mode == TYPE_MODE (intTI_type_node))

and possibly a few other places in the compiler.  What I'd like you
to do while we're sorting out the debugging thing is to hack the debug
code to not crash (or just use -g0) and see where else you run into
problems compiling SSE code with HOST_BITS_PER_WIDE_INT=32.  Because
you'll probably need to have TYPE_{MIN,MAX}_VALUE=NULL, which could
well give fold-const (among other places) indigestion.
From bernds@masala.cygnus.co.uk Mon Jul 03 15:31:00 2000
From: Bernd Schmidt <bernds@masala.cygnus.co.uk>
To: Richard Henderson <rth@cygnus.com>
Cc: gcc-patches@gcc.gnu.org, gdb@sourceware.cygnus.com
Subject: Re: More SSE infrastructure
Date: Mon, 03 Jul 2000 15:31:00 -0000
Message-id: <Pine.LNX.3.96.1000703232354.12291A-100000@masala.cygnus.co.uk>
References: <20000703140220.A25809@cygnus.com>
X-SW-Source: 2000-07/msg00001.html
Content-length: 1061

On Mon, 3 Jul 2000, Richard Henderson wrote:

> What I'd like you
> to do while we're sorting out the debugging thing is to hack the debug
> code to not crash (or just use -g0) and see where else you run into
> problems compiling SSE code with HOST_BITS_PER_WIDE_INT=32.  Because
> you'll probably need to have TYPE_{MIN,MAX}_VALUE=NULL, which could
> well give fold-const (among other places) indigestion.

I did something like this last year.  The only difference in behaviour
I noticed was slightly different debugging output (TYPE_{MIN_MAX}_VALUE
contained bogus constant values, but not NULL).
I did not look at the whole compiler, but I believe things like
fold-const are relatively safe, as we aren't really building any "real"
expressions with 128 bit types.  These types only show up as function
call arguments and return values and variable declarations.  This is
not something I can imagine fold-const ever wanting to touch.

What I did was by no means an exhaustive test, though.  I don't really
have a large chunk of SSE code to test with.

Bernd

Re: More SSE infrastructure

[Mark Kettenis]

   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.

Re: More SSE infrastructure

[Mark Kettenis]

   Date: Wed, 5 Jul 2000 00:16:46 -0700
   From: Richard Henderson <rth@cygnus.com>

   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.

Whatever, I don't really care.

   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.

[snip]

   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.

I'm assuming you're talking about stabs here.

   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.

If the lower bound is 0 and the upper bound is -1, GDB interprets the
type as an unsigned integer with the size of the hosts natural integer
type (i.e. 4 bytes on a 32-bit machine).

   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.

GDB uses the range info to determine the size of an object, even for
global symbols where it might be able to get the size from the symbol
table.  So using 0 and -1 wouldn't produce anything useful.

Giving the correct upper and lower bounds does work (tested on Solaris
2.6, with a recent GDB snapshot and egcs-2.91.66, where I added the
stab for a 128-bit type by hand).  GDB happily prints a 128-bit
hexadecimal constant when I ask it to print the value of a 128-bit
variable, but refuses to evaluate any complex expressions using this
variable, telling me that it cannot do such things on integer
variables larger than 8 bytes.

If printing correct lower and upper bounds is too hard for GCC, there
are alternatives.  If the lower bound is 0 and the upper bound is a
negative number, GDB assumes the size of the type (in bytes) is the
absolute value of the upper bound.  I've verified that emitting:

.stabs "__m128:t(0,20)=r(0,20);0;-16;",128,0,0,0

does indeed work.  The GNU stabs info file suggests that this is a
Convex convention.

It seems that GDB also supports type attributes (an AIX extension, see
the GNU stabs info file).  So

.stabs "__m128:t(0,20)=@s128;r(0,20);0;-1;",128,0,0,0

also works.

The relevant bits of code in GDB are stabsread.c:read_range_type()
(which interprets the lower and upper bound) and
stabsread.c:read_type() (which is sopposed to interpret the entire
stabs type string, and interprets the `s' type attribute).

Mark
From pbreed@yahoo.com Wed Jul 05 07:12:00 2000
From: Paul Breed <pbreed@yahoo.com>
To: insight@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Step into and Step over....
Date: Wed, 05 Jul 2000 07:12:00 -0000
Message-id: <20000705141145.11822.qmail@web3507.mail.yahoo.com>
X-SW-Source: 2000-07/msg00012.html
Content-length: 1186

I've been stuck at this place for a long time.
I'm willing to pay someone to help me solve this....

Step over does not work.
Example:
10)printf("Something");
11)myfunction();
12)printf("Something else");

If I am stopped at a break point on line 10

If I hit 'S' step I go to the first line of code
within printf.

If I hit 'N' next I go the the opening brace in the
printf function.

If I hit 'F' I finish the function and return.

I would have expected 'N' to step over the printf on
line 10 and stop at line 11.
Is this assumption wrong?


I'm using the latest Insite build on windows NT as
a cross debugger for a M68K-Elf using the remote
serial
protocol.

The code was compiled with GCC 2.95.2

I see the same problem running just GDB (I've not
tried 5.0 only 4.18.1)

This problem has persisted unchanged for more than a
year I'd be glad to work on it myself, but I need some
guidance.

Help!!!!!

Please respond to Paul@Netburner.com as the ISP I
normally use is on the Cygnus mail list reject list.
So I am reduced to yahoo mail ;-(

Paul





__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/
From rth@cygnus.com Wed Jul 05 10:56: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 10:56:00 -0000
Message-id: <20000705105600.A27820@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> <20000705001646.B27048@cygnus.com> <200007051344.e65DigH01032@delius.kettenis.local>
X-SW-Source: 2000-07/msg00013.html
Content-length: 1418

On Wed, Jul 05, 2000 at 03:44:42PM +0200, Mark Kettenis wrote:
> GDB uses the range info to determine the size of an object, even for
> global symbols where it might be able to get the size from the symbol
> table.  So using 0 and -1 wouldn't produce anything useful.

Ok.  I figured it couldn't be that easy.

> Giving the correct upper and lower bounds does work (tested on Solaris
> 2.6, with a recent GDB snapshot and egcs-2.91.66, where I added the
> stab for a 128-bit type by hand).

Next question: will GDB accept negative octal constants for
signed 128-bit types?  E.g. -017777.  I surely don't want to
do decimal output without libgmp on my side, which we don't
want to assume.

It wouldn't be the end of the world if we wound up considering
all such types unsigned in the debugger, but if it's possible...

> If printing correct lower and upper bounds is too hard for GCC, there
> are alternatives.  If the lower bound is 0 and the upper bound is a
> negative number, GDB assumes the size of the type (in bytes) is the
> absolute value of the upper bound.  I've verified that emitting:
> 
> .stabs "__m128:t(0,20)=r(0,20);0;-16;",128,0,0,0
> 
> does indeed work.  The GNU stabs info file suggests that this is a
> Convex convention.

Interesting to know.  However, I would imagine that not all
stabs system debuggers allow such a thing, so it'd be better
to go with printing proper bounds if possible.


r~
From kettenis@wins.uva.nl Wed Jul 05 12:08:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: rth@cygnus.com
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 12:08:00 -0000
Message-id: <200007051908.e65J89c01140@delius.kettenis.local>
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> <20000705001646.B27048@cygnus.com> <200007051344.e65DigH01032@delius.kettenis.local> <20000705105600.A27820@cygnus.com>
X-SW-Source: 2000-07/msg00014.html
Content-length: 1530

   Date: Wed, 5 Jul 2000 10:56:00 -0700
   From: Richard Henderson <rth@cygnus.com>

   Next question: will GDB accept negative octal constants for
   signed 128-bit types?  E.g. -017777.  I surely don't want to
   do decimal output without libgmp on my side, which we don't
   want to assume.

Not with the explicit minus sign.  You specify the sign bit as part of
the octal number, e.g. 020000 for your example (the range would be
specified as 020000;017777; in this case).  This is exactly what is
already done for `long' and `long long'.

   It wouldn't be the end of the world if we wound up considering
   all such types unsigned in the debugger, but if it's possible...

Looks like GDB treats those extremely large integers as unsigned
anyway :-(.  I might take a look on a rainy day or so ...

   > If printing correct lower and upper bounds is too hard for GCC, there
   > are alternatives.  If the lower bound is 0 and the upper bound is a
   > negative number, GDB assumes the size of the type (in bytes) is the
   > absolute value of the upper bound.  I've verified that emitting:
   > 
   > .stabs "__m128:t(0,20)=r(0,20);0;-16;",128,0,0,0
   > 
   > does indeed work.  The GNU stabs info file suggests that this is a
   > Convex convention.

   Interesting to know.  However, I would imagine that not all
   stabs system debuggers allow such a thing, so it'd be better
   to go with printing proper bounds if possible.

I'd be really surprised if those stabs system debugger would allow
large integers at all.

Mark
From avr_fan@nettaxi.com Wed Jul 05 17:12:00 2000
From: "Dave Arnold" <avr_fan@nettaxi.com>
To: "Paul Breed" <pbreed@yahoo.com>, <insight@sourceware.cygnus.com>, <gdb@sourceware.cygnus.com>
Subject: Re: Step into and Step over....
Date: Wed, 05 Jul 2000 17:12:00 -0000
Message-id: <010801bfe6e0$20293ee0$64251004@homepc.freedsl.com>
X-SW-Source: 2000-07/msg00015.html
Content-length: 2869

hi,

I've had similar problems but  I'm unsure whether the current available port
of Insight to cygwin even works
for anyone using win9x.  I've posted questions to the list to see who else
is using it, if they're having problems or not
but I have not one response out of about 3 postings.

I personally have had numerous problems.  I love the GUI on insight, it
seems to have a load of great
features and is very intuitive GUI which gets me excited. But I have not
been able to use it. Sometimes
what I'll do is recompile with DJGPP and use the command line gdb that comes
with DJGPP instead,
or I'll go as far as using Borland debugger but this is getting tiresome
after so many times.

I've been planning on trying to do a build of the latest source on my win95
computer to see if things
will go any smoother but haven't got around to it.

Do you know if Insight GDB will compile "OOB' with a ./configure and make ?
under cygwin on win95?

The problems I've had are numerous, most common are these:
1.source code in assembly only
2.listing source limited to some files and not others e.g. list
foo.c:myfunc() gives an error saying "source unavailable"
3.stepping and breakpoints work on and off and unpredictably.
4.using gdb console window and attempting to run an .exe gives "Error 193"
and failed to create process.  What the
heck am I supposed to do?

/dave

-----Original Message-----
From: Paul Breed <pbreed@yahoo.com>
To: insight@sourceware.cygnus.com <insight@sourceware.cygnus.com>;
gdb@sourceware.cygnus.com <gdb@sourceware.cygnus.com>
Date: Wednesday, July 05, 2000 7:13 AM
Subject: Step into and Step over....


>I've been stuck at this place for a long time.
>I'm willing to pay someone to help me solve this....
>
>Step over does not work.
>Example:
>10)printf("Something");
>11)myfunction();
>12)printf("Something else");
>
>If I am stopped at a break point on line 10
>
>If I hit 'S' step I go to the first line of code
>within printf.
>
>If I hit 'N' next I go the the opening brace in the
>printf function.
>
>If I hit 'F' I finish the function and return.
>
>I would have expected 'N' to step over the printf on
>line 10 and stop at line 11.
>Is this assumption wrong?
>
>
>I'm using the latest Insite build on windows NT as
>a cross debugger for a M68K-Elf using the remote
>serial
>protocol.
>
>The code was compiled with GCC 2.95.2
>
>I see the same problem running just GDB (I've not
>tried 5.0 only 4.18.1)
>
>This problem has persisted unchanged for more than a
>year I'd be glad to work on it myself, but I need some
>guidance.
>
>Help!!!!!
>
>Please respond to Paul@Netburner.com as the ISP I
>normally use is on the Cygnus mail list reject list.
>So I am reduced to yahoo mail ;-(
>
>Paul
>
>
>
>
>
>__________________________________________________
>Do You Yahoo!?
>Kick off your party with Yahoo! Invites.
> http://invites.yahoo.com/