Re: ST(i) and MMj

[Eli Zaretskii <eliz@gnu.org>]

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

(Note that I changed the subject: "none" seems inappropriate ;-)

> If a symbol's address class (`aclass') is LOC_REGISTER and its value
> is N, then GDB assumes the variable's value occupies register N.  It
> uses REGISTER_BYTE(N), REGISTER_RAW_SIZE(N), etc. to access that
> symbol's value.

We could arrange for REGISTER_RAW_SIZE and REGISTER_BYTE to perform
the required mapping between %st(i) and %mmj using the current TOS.

> We can't assign distinct register numbers to %st(0) and %mm0, for
> reasons discussed previously: GDB can't cope with two distinct
> register numbers referring to the same bits in the register file.

During that discussion I did agree that these registers should not be
treated as separate, but it seems we meant different things.

What I meant was that it is a Bad Idea to maintain separate data for
each one of these sets.  In other words, if %st(3) corresponds to
%mm0, it is wrong to have GDB maintain a separate data buffer where
the contents of each one of these registers is held.  The reason for
this is that it would be very hard to teach GDB and the
platform-specific code which data to use in each case, especially when
the user changes the values in these registers and you need to pass
the changed values to the debuggee.

But I don't see why cannot GDB _think_ about %st(X) and %mmY as being
separate registers while in reality they share the same data, if this
sharing is concealed behind REGISTER_BYTE and REGISTER_RAW_SIZE (and
possibly other functions/macros used to manipulate registers).  What
are the specific problems with this scheme?
From ac131313@cygnus.com Wed Dec 01 00:39:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: memory verify
Date: Wed, 01 Dec 1999 00:39:00 -0000
Message-id: <3844DE71.32797799@cygnus.com>
References: <5memd74iem.fsf@jtc.redbacknetworks.com> <384478F8.B079BDC2@cygnus.com> <5maenv4ehr.fsf@jtc.redbacknetworks.com> <38449CE7.26320160@cygnus.com> <5maenvcfqd.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00385.html
Content-length: 1542

"J.T. Conklin" wrote:
> 
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> >> But is there a reason for higher level code to care how the compare
> >> is implemented?  We could have target_XXX_memory check
> >> current_target-> to_XXX_memory --- if it's NULL, call that function
> >> otherwise a generic implementation would be used.
> 
> Andrew> Typically, yes.  I can think of two cases:
> Andrew>
> Andrew> o a weak/broken CRC algorithm
> Andrew>   which the user doesn't like.
> Andrew>
> Andrew> o Internal operations such as
> Andrew>   program download that would exploit the CRC
> Andrew>   when available.  (ex program load could run
> Andrew>   the crc before downloading each section.  This
> Andrew>   could cleanup the compare sections command.).
> 
> I don't think the existance of a to_XXX_memory() vector function is
> enough of a hint for upper layers of GDB to decide whether to use it.
> For example, changing generic_load() to call to_XXX_memory() on each
> section to determine whether it is already loaded makes a lot of sense
> with targets with CRC-like verification.  Those that implement it with
> a 'srecord verify'-like mechanism would lose (some ROM monitors have a
> command where a srecord stream is compared with the contents of memory
> instead of replacing the contents).  But perhaps this is an argument
> against using that kind of implementation.  Thoughts?

Bleuk :-)

That suggests one requirement on that method is that it be significantly
faster than a simple memory read :-)

	Andrew
From ac131313@cygnus.com Wed Dec 01 00:57:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: "Brown, Rodney" <rodneybrown@pmsc.com>
Cc: "'gdb@sourceware.cygnus.com'" <gdb@sourceware.cygnus.com>
Subject: Re: memory verify
Date: Wed, 01 Dec 1999 00:57:00 -0000
Message-id: <3844E2C4.85B7A492@cygnus.com>
References: <9150F3E779F0D211BD370008C733141C38AA12@aus-msg-02.au.pmsc.com>
X-SW-Source: 1999-q4/msg00386.html
Content-length: 1387

> "Brown, Rodney" wrote:
> 
> Depending how capable the stubs are, you could look at using Andrew
> Tridgewell's
> rsync algorithms. I think that uses CRCs to locate differences in
> files on
> different boxes to generate a delta file to update the file on one.
> This could allow the first difference idiom when run over large memory
> areas,
> without having to transmit the area over the wire.

Yes, I've had that in the back of my mind.  Several aspects of a typical
embedded target make it less general then one would hope:

	o	the typical target has a weak CRC
		(This suggests that perhaphs the check should
		have a requirement that it be ``strong''.
		How strong is an interesting question.

	o	rcync's performance depends heavily on the
		stream nature of its remote connection.
		The typical target uses an RPC like mechanism.
		GDB's remote protocol is especially bad.  The
		overhead of requesting CRC's could quickly
		mitigate any savings in avoiding downloads.

	o	remote targets are small and dumb with all the
		the inteligence (?) and memory living in GDB.

Having said that, an embedded implementation of rsync would make for an
interesting performance boost when it came to re-loading memory.  It
would definitly be a challenge to add an rsync session (it would be a
complex interaction than a simple exchange of packets) to GDB's remote
protocol.

	enjoy,
		Andrew
From ac131313@cygnus.com Wed Dec 01 01:55:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: David Golombek <daveg@maker.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Writing a new simulator
Date: Wed, 01 Dec 1999 01:55:00 -0000
Message-id: <3844F02D.EEFFEE84@cygnus.com>
References: <21vh6lj9mo.fsf@seattle143.maker.com>
X-SW-Source: 1999-q4/msg00387.html
Content-length: 2336

David Golombek wrote:
> 
> I'm examining using the simulator code packaged with GDB for the basis
> of a new simulator project.  I haven't seen much discussion here about
> the simulator packages, but haven't seen any other lists that might be
> appropriate.  If there is another list, please direct me towards it.
> I've read through a fair bit of the existing code, and wanted to ask
> some questions to make sure my assumptions are correct.
> 
> This work is for a new processor, to which I've already ported the
> Binutils, GDB, and Gas.  This is for a 32bit processor with a lot of
> special functional units, which are memory mapped.
> 
> 1) It seems that using either the mips or the v850 code as an example
> it the best bet, using the same igen framework that they use.  T/F?

Yes (along with the tic80 and d30v). The more recent simulators have
tended to use igen and (more importantly) the sim/common framework.

Another alternative would be to write your own simulator generator and
just exploit the common framework.

> 2) Reading the igen source, as well as the code in 'common', is the
> only existing documentation on igen.  T/F?

Unfortunatly also true.  The main igen documentation is in its header
files where it describes the syntax of each file.

> 3) Is there a good "ramp-up" methodology for writing a simulator, or
> do I need to write very large parts of it before its useful at all?
> IE, are there some pieces that I can implement first to get at least a
> simulator that will run, if not do anything, so that I can do
> piecewise implementation?

Yes.  Doing something like copying an existing sim directory (v850?
tic80?) and then chopping it back to nothing is a good strategy.  Just
be ruthless.  Simulators like the v850 were originally built using a
gencode program and now many years later still show some of that in
their internals.

> 4) Are there any mail archives or any discussion saved anywhere of the
> previous simulator implementations?  Just to give me a heads up on
> potential pit-falls, etc., that i may run into.

To be honest, outside of direct discussions with people I work with,
you're the first person to ask!

There is an old PSIM mailing list / web site (
http://sourceware.cygnus.com/psim/ however that doesn't cover any of the
the more recent sim/ developemnt.

	enjoy,
		Andrew
From rok.papez@kiss.uni-lj.si Wed Dec 01 03:28:00 1999
From: Rok Papez <rok.papez@kiss.uni-lj.si>
To: gdb@sourceware.cygnus.com, gnu-gdb-bug@moderators.isc.org
Subject: Insight 19991116, gdbserver, fork() - always follows parent
Date: Wed, 01 Dec 1999 03:28:00 -0000
Message-id: <99120112265800.00878@Strader.home>
X-SW-Source: 1999-q4/msg00388.html
Content-length: 1361

Hi!

-> Problem description:
-----------------
Even if I explicitly set follow-fork-mode to child, insight still follows a
parent.

I've succesfully compiled "insight 19991116" but I have encountered the
following problems:
-----------------
(gdb) s
daemonize () at httpdial.c:105
105       rc=fork();
(gdb) show follow-fork-mode
Debugger response to a program call of fork or vfork is "child".
(gdb) n

Program received signal SIGSTOP, Stopped (signal).
0x804926f in daemonize () at httpdial.c:105
105       rc=fork();
(gdb) show follow-fork-mode
Debugger response to a program call of fork or vfork is "child".
(gdb) n
106       if (-1==rc) {
(gdb) p rc
$1 = 11730
-----------------




-> Platforms:
---------
Target is a Linux 2.2.13 (RH 6.0):
- gdbserver from insight-19991116
- debugging via TCP
Workstation is a Linux 2.2.13 (RH 6.0):
- running insight GUI (problem tested with insight -nw)



-> Questions:
----------
1.) Is the insight 19991116 version same as gdb 19991116 ?
2.) Can insight and/or gdb finally work with LinuxThreads? What about
gdbserver? Do new threads block when they get created ?
3.) How can I make gdb/insight/gdbserver follow a fork() && exec() ??
4.) Is it possible to compile into the programme a breakpoint (so when it is
run I could attach to it) - if yes - how to make it work with gdbserver.

-- 
best regards,
Rok Papez.
From rodneybrown@pmsc.com Wed Dec 01 06:03:00 1999
From: "Brown, Rodney" <rodneybrown@pmsc.com>
To: "'Andrew Cagney'" <ac131313@cygnus.com>, "Brown, Rodney" <rodneybrown@pmsc.com>
Cc: "'gdb@sourceware.cygnus.com'" <gdb@sourceware.cygnus.com>
Subject: RE: memory verify
Date: Wed, 01 Dec 1999 06:03:00 -0000
Message-id: <9150F3E779F0D211BD370008C733141C38AA13@aus-msg-02.au.pmsc.com>
X-SW-Source: 1999-q4/msg00389.html
Content-length: 2874

Title: RE: memory verify





The loop unrolled CRC-32 used in the info-zip tools (with a bit of extra 
optimization) is 259 bytes i386 text space - but needs a 4*256 byte array.
Assuming that ultimate speed in CRC calculation isn't needed in the stub
then a nibble at a time varient - without loop unrolling should be possible
in < 259 bytes with a 4*16 = 64 byte array.
It should be possible to provide a CRC-32 in < 300 bytes (i386), if that
is strong enough. 
Having just had a quick look at rsync, an MD4 checksum is being used - a cryptographic digest isn't it? If the rolling rsync checksum calculation

is small enough & you replaced the MD4 checksum with one or two 32-bit
CRC calculations you'd be able to do almost as well as with the MD4
checksum - but without the anti-tampering guarantees.
Note that adding another 32-bit CRC polynomial should only cost another 
64 bytes of array or so.



-----Original Message-----
From: Andrew Cagney [ mailto:ac131313@cygnus.com ]
Sent: Wednesday, 1 December 1999 19:57
To: Brown, Rodney
Cc: 'gdb@sourceware.cygnus.com'
Subject: Re: memory verify



> "Brown, Rodney" wrote:
> 
> Depending how capable the stubs are, you could look at using Andrew
> Tridgewell's
> rsync algorithms. I think that uses CRCs to locate differences in
> files on
> different boxes to generate a delta file to update the file on one.
> This could allow the first difference idiom when run over large memory
> areas,
> without having to transmit the area over the wire.


Yes, I've had that in the back of my mind.  Several aspects of a typical
embedded target make it less general then one would hope:


        o       the typical target has a weak CRC
                (This suggests that perhaphs the check should
                have a requirement that it be ``strong''.
                How strong is an interesting question.


        o       rcync's performance depends heavily on the
                stream nature of its remote connection.
                The typical target uses an RPC like mechanism.
                GDB's remote protocol is especially bad.  The
                overhead of requesting CRC's could quickly
                mitigate any savings in avoiding downloads.


        o       remote targets are small and dumb with all the
                the inteligence (?) and memory living in GDB.


Having said that, an embedded implementation of rsync would make for an
interesting performance boost when it came to re-loading memory.  It
would definitly be a challenge to add an rsync session (it would be a
complex interaction than a simple exchange of packets) to GDB's remote
protocol.


        enjoy,
                Andrew