RE: Preferred format of Copyright statement

RE: Preferred format of Copyright statement

[Brown, Rodney]

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

Title: RE: Preferred format of Copyright statement





For the patches supplied I found it easiest to run the script,
correct the (few) errors it diagnosed and then walk through the changes
doing some minor reformatting. The ChangeLog entries took almost as
long. Since the changes are mainly in comments a big bang approach is
less risky than for PARAMS. Once the distraction of Roy & HG is over I should be able to
supply patches with a few days turn around at most, so whenever it
is convenient for you guys.


I need to submit a patch to automake which has and generates
an embedded year range.


-----Original Message-----
From: Andrew Cagney [ mailto:ac131313@cygnus.com ]
Sent: Tuesday, September 26, 2000 6:08 AM
To: RDBrown@mira.net; RodneyBrown@mynd.com
Cc: Geoff Keating; gdb@sources.redhat.com
Subject: Re: Preferred format of Copyright statement




> > 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.
> 
> Ok, will produce that form.
>   Given that the first attempt over gdb
> gives a patch file of ~900k touching 1725 files, would it be more useful
> to provide patches for the few percent of cases needing manual fixes and
> provide the script to be run when the maintainer finds it convenient?
> Or should it only fix those with ranges or 2-digit years and leave (C)
> removal where the year list is Ok?
> 
> (Trying to conserve maintainer think time, not be a WOFTAM).


(Yes I know your e-mail was posted a month ago :-().


Could I suggest a multi-step process like Kevin is doing to clean up
PARAMS.  I'd suggest doing the automated changes and then as a later
pass, do the hand changes.  You won't need maintainer approval for this
change.  Just give a weeks notice on the big jumbo change.


        enjoy,
                Andrew


PS: I my take on how to format copyright is that IanC's guideline is
simply too complicated for us programming types - we're a simple bunch
:-)

Re: Preferred format of Copyright statement

[Andrew Cagney]

> "Brown, Rodney" wrote:
> 
> For the patches supplied I found it easiest to run the script,
> correct the (few) errors it diagnosed and then walk through the
> changes
> doing some minor reformatting. The ChangeLog entries took almost as
> long. Since the changes are mainly in comments a big bang approach is
> less risky than for PARAMS. Once the distraction of Roy & HG is over I
> should be able to
> supply patches with a few days turn around at most, so whenever it
> is convenient for you guys.

The big bang theory sounds fine.

	Andrew
From taylor@cygnus.com Mon Nov 06 13:25:00 2000
From: David Taylor <taylor@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: pathmap or dir command on drugs
Date: Mon, 06 Nov 2000 13:25:00 -0000
Message-id: <200011062125.QAA00561@texas.cygnus.com>
X-SW-Source: 2000-11/msg00024.html
Content-length: 2134

It has been requested that GDB support the ability to move the source
tree used to build the program being debugged -- without having to
type in lots of directories for a really long dir command.

The idea is that there would be a command which would take two path
arguments and would arrange that whenever gdb was asked to list source
code, it would replace the 'from' prefix with the 'to' prefix before
opening the file.

So, if you had a source tree

    /old/top/dir

	sub/dir1/file1.c
	subdir2/file2.c
	sub3/dir3/file3.c

when you built your program, but you were now debugging on a different
system where it was mounted as

    /new/top/dir

Then to tell gdb how to find the source code you wouldn't have to give
a dir command with all the subdirectories

    /new/top/dir/sub/dir1
    /new/top/dir/subdir2
    /new/top/dir/sub3/dir3

you could instead just give one command which said that when presented
with

    /old/top/dir

replace it with

    /new/top/dir

The real value of such a mechanism is when there are many directories
it can save some typing.

If you had multiple trees, you could set up multiple mappings.  If you
made a typo when typing in a pathmap, you could delete that one pathmap.

There seems to be at least two camps on what the interface should be:

One camp, by comparison with breakpoints and displays, is:

    pathmap <from-prefix> <to-prefix>
    show pathmaps <optional-list>
    delete pathmaps <optional-list>

The other camp is

    pathmap add <from-prefix> <to-prefix>
    pathmap list <optional-list>
    pathmap delete <optional-list>

By further analogy with breakpoints and displays, we could also have:

    disable pathmaps <optional-list>
    enable pathmaps <optional-list>

or

    pathmap disable <optional-list>
    pathmap enable <optional-list>

[Though I have yet to hear a convincing argument for the need to have
enable and disable options.]

So, is this functionality people would like to see gdb have?  Is this
the form it should take?  And what interface do people feel it should
have? -- one of the above? or something else altogether?

Other comments are also welcome.
From fnasser@cygnus.com Mon Nov 06 13:48:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: David Taylor <taylor@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: pathmap or dir command on drugs
Date: Mon, 06 Nov 2000 13:48:00 -0000
Message-id: <3A072726.BB42BEA3@cygnus.com>
References: <200011062125.QAA00561@texas.cygnus.com>
X-SW-Source: 2000-11/msg00025.html
Content-length: 1667

David Taylor wrote:
> 
> One camp, by comparison with breakpoints and displays, is:
> 
>     pathmap <from-prefix> <to-prefix>
>     show pathmaps <optional-list>
>     delete pathmaps <optional-list>
> 
> The other camp is
> 
>     pathmap add <from-prefix> <to-prefix>
>     pathmap list <optional-list>
>     pathmap delete <optional-list>
> 

I vote for the second one for a few reasons:

1) I think displays and breakpoints are objects related to the 
   inferior program execution.  Let's say they are of the Exec class.
   This "pathmap" facility is related to the source level debugging 
   capabilities of gdb, lets say they are from the "Symbol" class.
   I would rather not mix.

2) These commands that have a show without a set are confusing (if we
   can say "show pathmap" we would expect to be able to say "set pathmap").
   I know that we already have may of those, but I would rather not add one
   more.

3) The second option keeps this feature completely independent and
   completely out of the way of someone who doesn't want to map paths.
   It doesn't show in help delete, as a show command option.  It is
   neatly separated.
   

But people may have arguments to the first option as well, so I will wait
to see what the general preference is.


As to the functionality, it is not my call, but I find it an interesting
to have around.  I have the feeling that I may have used this if it existed
before.


P.S.:  I guess one can say "pathmap delete all", right?
      (or "delete pathmap all")  



-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From jtc@redback.com Mon Nov 06 14:20:00 2000
From: jtc@redback.com (J.T. Conklin)
To: David Taylor <taylor@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: pathmap or dir command on drugs
Date: Mon, 06 Nov 2000 14:20:00 -0000
Message-id: <5m1ywo68v8.fsf@jtc.redback.com>
References: <200011062125.QAA00561@texas.cygnus.com>
X-SW-Source: 2000-11/msg00026.html
Content-length: 3709

>>>>> "David" == David Taylor <taylor@cygnus.com> writes:
David> It has been requested that GDB support the ability to move the
David> source tree used to build the program being debugged -- without
David> having to type in lots of directories for a really long dir
David> command.

Yes.  This gets old very fast, especially if your image is built from
sources in many subdirectories.

David> The idea is that there would be a command which would take two
David> path arguments and would arrange that whenever gdb was asked to
David> list source code, it would replace the 'from' prefix with the
David> 'to' prefix before opening the file.

Should this facility be limited only to prefixes?  A regex based
transformation scheme like used by the pax utility would be more
general.  While most of the time I've used pax's transformations to
change prefixes, once or twice I've done "more interesting" things.

David> The real value of such a mechanism is when there are many
David> directories it can save some typing.

s/some/lots and lots and lots and lots/

David> If you had multiple trees, you could set up multiple mappings.
David> If you made a typo when typing in a pathmap, you could delete
David> that one pathmap.

How do you envision multiple mappings work?  Does GDB process mappings
in order and terminate when the first successful substitution?  This
seems to be the only sane behavior to me, but it requires the ability
to maintain an ordered list from the CLI.

David> There seems to be at least two camps on what the interface should be:
David>
David> One camp, by comparison with breakpoints and displays, is:
David>
David>     pathmap <from-prefix> <to-prefix>
David>     show pathmaps <optional-list>
David>     delete pathmaps <optional-list>
David>
David> The other camp is
David>
David>     pathmap add <from-prefix> <to-prefix>
David>     pathmap list <optional-list>
David>     pathmap delete <optional-list>

Both interfaces are essentially the same, and neither handles a sorted
list very well.  After thinking about it as I've been composing this
message, I think this is a feature that must be provided for.

Imagine a situation where you have a product built from a tree like
the below, where third-party code is in a separate subdirectory.

        /foo/vendor/dir1
        /foo/dir2
        /foo/dir3

But then you have to process it on another machine where the third-
party code is on another filesystem (perhaps it's archived on a
cdrom).

        /cdrom/dir1
        /bar/dir2
        /bar/dir2

A pathmap like this:
        pathmap /foo/vendor     /cdrom
        pathmap /foo            /bar

will work fine, while:
        pathmap /foo            /bar
        pathmap /foo/vendor     /cdrom

will fail because the first map will match first.


An ordered pathmap is sort of like access-lists on Cisco's IOS.
Anyone know what kind of CLI they offer to edit them?  I can't recall
off hand.


David> By further analogy with breakpoints and displays, we could also have:
David>
David>     disable pathmaps <optional-list>
David>     enable pathmaps <optional-list>
David>
David> or
David>
David>     pathmap disable <optional-list>
David>     pathmap enable <optional-list>
David>
David> [Though I have yet to hear a convincing argument for the need to have
David> enable and disable options.]

I agree.  

If I was writing the code, I'd do it to not preclude adding enable and
disable options, but skip it until it's proven to be useful.  While
you could argue that because breakpoints, displays, etc. have enable
and disable options and this should to be orthogonal, I'm not convinced
that pathmaps are really that similar.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From Fabrice_Gautier@sdesigns.com Mon Nov 06 15:41:00 2000
From: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
To: "GDB (E-mail)" <gdb@sourceware.cygnus.com>
Subject: finish breakpoints not deleted.
Date: Mon, 06 Nov 2000 15:41:00 -0000
Message-id: <B1F6452C89AFD411AE0800A0CC734C23014FF0@EMAIL1>
X-SW-Source: 2000-11/msg00027.html
Content-length: 430

Hi,

When I use "finish" to return from the current function, it works but then
gdb will always stop at this point as if a breakpoint was set for the
"finish" and never deleted after. The only way I have to delete this
invisble breakpoint is to set and delete another one a the same point.

I'm using gdb (insight) do debug a remote i386 target running an eCos
program.

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

Re: Preferred format of Copyright statement

[Geoff Keating]

> 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