Re: [remote] Make registers network byteordered?

[Jim Blandy <jimb@zwingli.cygnus.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 8101 bytes --]

Andrew Cagney <ac131313@cygnus.com> writes:

> 
> Hello,
> 
> At present the target sends back registers in target byte order format
> vis:
> 
> 	T0525:c4060280ffffffff;1d:c0ffff81ffffffff;
> 
> I'd like to think about a tweek to this part of the protocol so that the
> format:
> 
> 	T0525=ffffffff80020664;1d=ffffffff81ffffc0;
> 
> is accepted.  The thing I can't figure out is now to also change the
> [pP] packets so that GDB can correctly detect targets that support this
> format when writing registers.
> 
> General comments?

What's the point?  Simply that registers don't have an endianness?
From jtc@redback.com Tue Dec 05 15:24:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: SOFTWARE_SINGLE_STEP_P and multi-arch
Date: Tue, 05 Dec 2000 15:24:00 -0000
Message-id: <5mk89ezc2o.fsf@jtc.redback.com>
References: <3A2C4141.B3C2F486@cygnus.com>
X-SW-Source: 2000-12/msg00026.html
Content-length: 1920

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> At present there are two macros that control software stepping:
Andrew>
Andrew> 	SOFTWARE_SINGLE_STEP_P()
Andrew>
Andrew> and 	SOFTWARE_SINGLE_STEP(sig, insert_or_remove)
Andrew>
Andrew> I'd like to suggest the following:
Andrew>
Andrew> Rename SOFTWARE_SINGLE_STEP_P() to TARGET_SOFTWARE_SINGLE_STEP_P() and
Andrew> add it to the *target* vector.


You're correct that hardware single step support is target dependent.
For example, SOFTWARE_SINGLE_STEP_P is 1 on the sparc (and thus the
embedded sparc varients like the sparclite and sparclet), but single
step performance using the remote protocol would be greatly improved
if the stub managed the step internally.  While not strictly a hard-
ware single step, it acts more or less the same.  Perhaps the names
SOFTWARE_SINGLE_STEP_P and SOFTWARE_SINGLE_STEP() should be changed
to something more appropriate?  I can't think of anything off hand.

One concern I have is that it may not be known whether a target
supports "hardware" single step until it is attempts one.  Using the
above examples of the sparclite and sparclet, older stubs won't have
support for the step command packet.  I can't think of a good way to
determine ahead of time whether the packet is supported.  GDB won't
know whether it's OK to use it until it's too late.

Perhaps this indicates we should be taking another approach.  This is
not completely thought out, feel free to shoot holes in it.  The step
function would be split out of target_resume() into a new vector
function target_step().  GDB would unconditionally call target_step(),
if it fails with an error code indicating that hardware single step is
not available, it would call SOFTWARE_SINGLE_STEP() and then
target_resume().

Looking at infrun.c:resume(), it looks like this wouldn't be a trivial
exercise. 

        --jtc

-- 
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Tue Dec 05 16:18:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: [remote] Make registers network byteordered?
Date: Tue, 05 Dec 2000 16:18:00 -0000
Message-id: <3A2D8384.1D52812B@cygnus.com>
References: <3A2C4305.6D9E53B3@cygnus.com> <o566kytwbv.fsf@toenail.toronto.redhat.com>
X-SW-Source: 2000-12/msg00027.html
Content-length: 545

"Frank Ch. Eigler" wrote:
> 
> Andrew Cagney <ac131313@cygnus.com> writes:
> 
> : [..]
> : At present the target sends back registers in target byte order format
> : vis:
> :       T0525:c4060280ffffffff;1d:c0ffff81ffffffff;
> : I'd like to think about a [tweak] to this part of the protocol so that the
> : format:
> :       T0525=ffffffff80020664;1d=ffffffff81ffffc0;
> : is accepted.  [...]
> 
> How are gdb and the target supposed to pick the right scheme?  Do you
> imagine some sort of prior negotiation?

The ``='' vs the ``:''.

	Andrew
From ac131313@cygnus.com Tue Dec 05 16:24:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: [remote] Make registers network byteordered?
Date: Tue, 05 Dec 2000 16:24:00 -0000
Message-id: <3A2D84F3.48F372E@cygnus.com>
References: <3A2C4305.6D9E53B3@cygnus.com> <np1yvm8plo.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-12/msg00028.html
Content-length: 975

Jim Blandy wrote:
> 
> Andrew Cagney <ac131313@cygnus.com> writes:
> 
> >
> > Hello,
> >
> > At present the target sends back registers in target byte order format
> > vis:
> >
> >       T0525:c4060280ffffffff;1d:c0ffff81ffffffff;
> >
> > I'd like to think about a tweek to this part of the protocol so that the
> > format:
> >
> >       T0525=ffffffff80020664;1d=ffffffff81ffffc0;
> >
> > is accepted.  The thing I can't figure out is now to also change the
> > [pP] packets so that GDB can correctly detect targets that support this
> > format when writing registers.
> >
> > General comments?
> 
> What's the point?  Simply that registers don't have an endianness?

Several motivations:

	o	there is no robust way of
		communicating a change in
		endianess through the protocol.

		This should be trivial.  Fetch
		the status register and check
		the endian bit.  Nope.

	o	I've had it with trying to read
		what are endian independant values
		backwards.

enjoy,
	Andrew
From cadamuro@lit.cpdtt.cefetpr.br Wed Dec 06 03:22:00 2000
From: João Cadamuro Junior <cadamuro@lit.cpdtt.cefetpr.br>
To: gdb <gdb@sources.redhat.com>
Subject: Re: GDB for powerpc-eabi under cygwin
Date: Wed, 06 Dec 2000 03:22:00 -0000
Message-id: <3A2E2311.16CFC078@lit.cpdtt.cefetpr.br>
References: <3A27C7CC.F75AE735@lit.cpdtt.cefetpr.br>
X-SW-Source: 2000-12/msg00029.html
Content-length: 2343

After "fighting and fighting", I fix the problem in building GDB under cygwin 1.1.6.

Firstly, the problem was cygwin, not GDB. This was discovered when I tried to build the insight-5.0
release and it fail in the same point as 2000-11-30 snapshot.

So, after a number of workarounds without success, I decide to work as a typical Windows user -
remove cygwin and install it all again.

After that, I rebuild all my tools (binutils, cross compiler, libraries and debugger) and ...
works!!! Also the second problem described with breakpoints in the SDS target disappeared (for now
I'm using SDS target for 2 days without seeing the problem again...).

After all, I think I have a corruption in some cygwin upgrade, because since version 1.1.2 I only
upgrade my cygwin installation.

Thank you for all the people who inverst their precious time in taking a look into my problem.
Special thanks to Michael Chastain for the help with the PowerPC simulator, whose problem wasn't
cygwin.

I hope this can help more cygwin users in the future...


Best Regards,

João Cadamuro Junior
LIT / CPDTT / CEFET-PR
URL.: http://www.lit.cpdtt.cefetpr.br


> I have a little questions about debugging powerpc targets and I'll be
> grateful for any help...
>
> I'm using gdb+insight to debug my PowerPC target. The debugger was built
> using option "--target=powerpc-eabi" and under cygwin (Pentium III
> machine with Windows2000 (SP 1) Operating System).
>
> The last successful built for me was 2000-08-16. After this version I
> tryied to build a certain number of snapshots without success.
>
> I have two reasons for build a newer gdb version:
>
> 1. PowerPC simulator don't work for snapshot 2000-08-16.
>
> If you compile a simple "Hello Word" for the simulator and try to debug
> it with GDB, you'll be "ejected"...
>
> 2. Sometimes when the target reports a breakpoint to GDB host with a
> Breakpoint Signal (SDS monitor target...) gdb "eject" me too. The point
> here is that target stop execution, repots the breakpoint signal, and
> GDB crashes receiving this signal. Because this problem is not
> deterministic, I cannot fix it...
>
> With this problems, my last try to build gdb+insight was 2000-11-30
> snapshot, under cygwin-1.1.6 .
>

.............

>
>
> João Cadamuro Junior
> LIT / CPDTT / CEFET-PR
> URL.: http://www.lit.cpdtt.cefetpr.br