Re: Preferred format of Copyright statement

[Geoff Keating <geoffk@cygnus.com>]

> From: Rodney Brown <rdb@cygnus.com>
> Date: Tue, 15 Aug 2000 23:14:51 +1000 (EST)

> Copyright 1990, 91, 92, 93, 94, 1999 Free Software Foundation, Inc.
> 
> This form would allow ~ 9 year numbers in the list before needing to
> wrap to two lines as compared with ~ 6 for the 4-digit year form implied
> by the FSF Information for Maintainers page.
> GDB has at least one file with a list of 13 years.
> 
> According to section 2.7 of the Copyright-FAQ, it would be a
> valid (US) Copyright notice (IMO - which has No legal worth)
> < ftp://rtfm.mit.edu/pub/usenet/news.answers/law/Copyright-FAQ/part2 >
> 
> Does this form meet the FSF need for squeaky clean legalities?

No.  The FSF asks for full 4-digit years. The statement above should
be:

Copyright 1990, 1991, 1992, 1993, 1994, 1999 Free Software Foundation,
Inc.

I know this has a tendency to line-wrap, but so what?  No human will
ever care.  So we might as well make it completely correct.
-- 
- Geoffrey Keating <geoffk@cygnus.com>
From fnasser@cygnus.com Tue Aug 15 12:23:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Shaun Jackman <shaunj@gray-interfaces.com>
Cc: gdb list <gdb@sources.redhat.com>
Subject: Re: remote debugging
Date: Tue, 15 Aug 2000 12:23:00 -0000
Message-id: <39999A0E.64174D4C@cygnus.com>
References: <004e01c006dc$056bda60$6801a8c0@gray.internal>
X-SW-Source: 2000-08/msg00077.html
Content-length: 2183

Shaun Jackman wrote:
> 
> What is the preferred method for remote debugging?
> 
> I have an Atmel EB01, AT91M40400 processor (ARM7TDMI) which came with an
> Angel monitor in flash.
> Debugging with it is dead slow. Stepping through a few lines of code which
> occurs as fast as I can click in the simulator takes ~20 seconds with the
> Angel monitor. Also, I am unable to connect to the Angel monitor faster than
> 9600 (although I can go up to 38400 with the Arm Ltd. debugger).
> 

gdb 5.0 should be able to talk to RDI targets up to 115200.  Of course
it depends
on the board you have.  On a board I have with a StrongARM processor I
can talk
to Angel at 115200 but on the ARM Inc. $150 AEB board I can only connect
at 9600.

The protocol is very simple: gdb (actually, the code ARM gave us), using
9600 bauds,
proposes the speeds it can handle starting with the preferred one,
115200 of course,
and the board replies with the speed it can handle.  The AEB board
replies with 9600,
so gdb uses 9600 and things are slow as you say.

But there is not much we can do about this.  We cannot just ignore the
Angel monitor
reply because the board must switch to the appropriate speed after the
reply (and that
is the protocol, damn it!)


> I have a Jeeni on loan (JTAG Angel over ethernet) which allows me to debug
> as fast as the simulator, but they're bloody expensive! I'd prefer a serial
> or parallel solution if possible, only for cost reasons. (unless someone
> knows of a cheap ethernet device!)
> 
> Is serial-tether debugging necessarily as slow as the Angel monitor? Would
> Cygmon or the gdb-stub be better?
> 

Cygmon is nice.  It works fast at 115200 speed but it is only available
for some
boards.  You will have to check with your board manufacturer.


> My preferred development environment would be Linux, but I'm stuck in a
> dual-booting limbo right now until I can sort out my tool-chain problems.
> 

There was a problem, at some point, with the gdb RDI protocol (the one
used to
talk to Angel) on CygWin some time ago.  It works fine now, so if you
get a 
recent CygWin dll you should be able to use it on a Window box.

-- 
Fernando Nasser
Red Hat Canada Ltd.
From jingham@apple.com Tue Aug 15 16:08:00 2000
From: Jim Ingham <jingham@apple.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb@sources.redhat.com
Subject: Re: Changing the "enclosing_type" of a value structure
Date: Tue, 15 Aug 2000 16:08:00 -0000
Message-id: <200008152308.QAA05666@scv2.apple.com>
X-SW-Source: 2000-08/msg00078.html
Content-length: 1884

On Monday, August 14, 2000, at 11:32 PM, Eli Zaretskii wrote:

> > Date: Mon, 14 Aug 2000 11:32:07 -0700 
> > From: Jim Ingham <jingham@apple.com> 
> >  
> > The sketch I sent in the last note was not right.  You have to change the 
> > lazy flag 
>  
> Sorry for jumping in--I wasn't following this thread--but changing the 
> way the lazy flag is set might affect the hardware watchpoints, at 
> least on x86 targets.  The current code which checks whether a given 
> value can be watched by hardware watchpoint(s) and the code which 
> inserts the watchpoints assume that those parts of the value chain 
> which have their lazy flag set don't need to be watched.  This allows 
> to watch members of large structs and array elements without watching 
> the whole struct/array. 
>  
> If the issue you were discussing has no relation to that problem, I 
> apologize. 
>  

Humm...  I have to think about this some more.  The comment before the definition of the lazy field in value.h says:

    /* If zero, contents of this value are in the contents field.
       If nonzero, contents are in inferior memory at address
       in the location.address field plus the offset field
       (and the lval field should be lval_memory).  */
    char lazy;
 
This doesn't sound at first reading like the meaning that it is being given by the watchpoint code, which also doesn't quite jibe with the description of the VALUE_CONTENTS macro.  In valops.c & friends, the lazy flag is definitely used to indicate whether the data HAS been read in from inferior memory or not.

I don't yet understand how this all works enough to know whether this seeming overloading is actually a problem or not, though I agree that given how it is used for watchpoints, it is not as simple as I first thought.

Still digging...

Jim
Jim Ingham                                   jingham@apple.com
Apple Computer