Re: JTAG debug support for ARM

[Michael Meissner <meissner@cygnus.com>]

On Thu, Jan 25, 2001 at 06:07:38PM -0500, Peter Reilley wrote:
> I do not believe that there is any question of legality.   Gdb
> is commonly used with libraries that are not available as 
> source.   For example; running it on Solaris, etc.   What
> about if I bought the accelerated X server that Red Hat
> sold.   Must I not run gdb?

Quoting from section 3 of the GPL:

	The source code for a work means the preferred form of the work for
	making modifications to it.  For an executable work, complete source
	code means all the source code for all modules it contains, plus any
	associated interface definition files, plus the scripts used to
	control compilation and installation of the executable.  However, as a
	special exception, the source code distributed need not include
	anything that is normally distributed (in either source or binary
	form) with the major components (compiler, kernel, and so on) of the
	operating system on which the executable runs, unless that component
	itself accompanies the executable.

So the answer is you can run GDB providing it was linked against system
libraries, even if you do not have source for those libraries.

> The Linux community recognizes that to win in the public
> arena some software will not be GPL'ed.   Indeed, most
> people actively encourage commercial software to be
> ported to Linux.

However, the Free Software Foundation does have the rights to control software
it writes (or is assigned to it).  If you don't like the controls, you are free
not to use the software.  You are not free to do something with GPL software
that goes against the owners wishes (ie, link with non-GPL software that isn't
provided with the major components of the system).

> I have written GLP'ed software and I have written commercial 
> software.  This project gives me the opportunity to give to the Linux
> community something that previously was only available
> under Windows.

It is GPL, not GLP.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482
From kevinb@cygnus.com Thu Jan 25 18:00:00 2001
From: Kevin Buettner <kevinb@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>, gdb-patches@sources.redhat.com
Cc: gdb@sources.redhat.com, taylor@cygnus.com
Subject: Re: [PATCH, RFA]: Revamp NaN detection & discussion
Date: Thu, 25 Jan 2001 18:00:00 -0000
Message-id: <1010126015949.ZM4533@ocotillo.lan>
References: <200101252103.f0PL3ig00326@delius.kettenis.local> <kettenis@wins.uva.nl>
X-SW-Source: 2001-01/msg00186.html
Content-length: 2148

On Jan 25, 10:03pm, Mark Kettenis wrote:

> I also have an itch about floatformat.{ch} and its functions.  I'd
> rather put all floatformat_* functions in there rather than in
> defs.h/utils.c.  But since it's part of libiberty that's a bit of a
> pain.  Is this stuff really used anywhere outside GDB?  If not,
> perhaps we could claim it back. > Otherwise I'd like to add a
> gdb_floatformat.{ch} and put all the floatformat stuff there.

To the best of my knowledge, the differences between the libiberty
floatformat support and that in GDB is that GDB converts to/from a
DOUBLEST whereas libiberty uses a double.  Also, GDB has fixed some
bugs that are still in the libiberty version.  The opposite may also
be true.

Clearly, it'd be best if only one version of the floatformat
functionality needed to be supported.  Ideally, the floatformat
functionality would reside in libiberty (or perhaps some other
library) and GDB would just make use of it.  It would then be
available for other programs to use as well.  (And indeed, I imagine
these were the original motives which caused this support to
be moved from GDB to libiberty.)  However, as shown by your patch,
GDB would like to extend the functionality from time to time in ways
that may break the other (perhaps mythical) applications which use it. 
So it would seem that GDB will need its own copy of this code.

I don't know if an immediate "claiming back" of the floatformat
support from libiberty is a realistic alternative.  While I don't know
of any other applications which use it, I haven't really looked around
either.  In any event, it seems to me that it would be really
difficult to know whether someone is using this functionality or not.

I think the best thing to do (which comes pretty close to "claiming it
back") is to stop using any of the libiberty floatformat support in
GDB.  In other words, GDB's floatformat support should be entirely
self contained.  (I like your idea of putting it in
gdb_floatformat.[hc].)  Once this is done, the libiberty maintainer
will have the freedom to slowly phase out the floatformat support
if that is deemed a desirable goal.

Kevin
From jtc@redback.com Thu Jan 25 18:01:00 2001
From: jtc@redback.com (J.T. Conklin)
To: gdb@sourceware.cygnus.com
Subject: remote protocol extension for memory access width
Date: Thu, 25 Jan 2001 18:01:00 -0000
Message-id: <5md7dbkr6i.fsf@jtc.redback.com>
X-SW-Source: 2001-01/msg00187.html
Content-length: 3703

Ok, now that the memory attribute code is in and we're working out the
kinks, I'm going to try to nail down the remote protocol extension to 
pass the access width to the debug agent.

The current memory read and write commands take the form:

        mAA..AA,LLLL            Read LLLL bytes at address AA..AA
        MAA..AA,LLLL:DDDD..     Write LLLL bytes at address AA..AA

Rather than add new commands, my thought is to add attribute support 
like:
        mAA..AA,LLLL[,attr=val[,attr=val[,...]]]
        MAA..AA,LLLL[,attr=val[,attr=val[,...]]]:DDDD...

This leaves the format open for additional attributes to be added in
the future.  Although this reduces the maximum payload of the memory
write command, I don't think it's significant enough to matter.  The
user presumably needs the attributes, otherwise s/he wouldn't have 
specified them.  

For memory access width, I propose using "width=X", where X is 8, 16,
32, or 64.  If no access width was specified (MEM_WIDTH_UNSPECIFIED),
no attribute would be appended to the commands.


I think the above is not controversial, but there are some issues that
I need some assistance working out.

* At present, there is nothing that ensures that an address and length
  passed to target_xfer_memory() are aligned to a access width boundry.
  IMHO it would be wrong to change this: target_xfer_memory() provides
  an abstraction layer between GDB's upper and lower layers.  But this
  implies that either within or somewhere below target_xfer_memory() we
  must handle misaligned transfer addresses and sizes.

* What does "handling" missaligned transfers entail?  IMO, this means
  that only part of the first and/or last "word" of a transfer may be
  required to complete the transfer.  This would require the whole
  word to be transfered, but only the needed byte(s) would copied to 
  the buffer.

* So at what layers should this occur?  One approach is to require the
  debug agent to handle it itself.  This is how I've been prototyping
  the facility.  But I have a couple of problems with it.  IMHO it is
  making a too large assumption about the capabilities of the target.
  We can get away with it with the remote protocol, since we control
  both ends.  But we shouldn't preclude using this with other back
  ends.  The SingleStep debugger has a similar facility, so if we ever
  got a hold of a SDS protocol description we should be able to support
  it there.  

  Even if we were to stick with only the remote protocol, I'm having a
  hard time reconciling the protocol's lean-and-mean design philosophy
  with the requirement that it handle misaligned accesses.  I would be
  comfortable with the idea that the debug agent could reject them out
  of hand.  However, I think I could probably be convinced otherwise.
  For example, the protocol was once stateless...

* So if we can't leave it to the remote systems, we could require it
  to be handled by the target vector xfer_memory functions.  This is
  distasteful to me because it requires support code to be added to 
  many places.

* This leads me to believe any misalignment handling should be done
  above the target layer.  This could be done in do_xfer_memory(),
  which sits below both target_xfer_memory() and the code that reads
  and writes a dcache line.  (although, since a cache line has greater
  alignment than can be specified by a memory attribute, it will not
  need any special handling).

For the remote protocol, I'm currently thinking that the protocol
extension be written up such that GDB "MUST" send a memory read/write
request.

Please share your thoughts, as I'm actively finishing up this feature.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From jtc@redback.com Thu Jan 25 19:50:00 2001
From: jtc@redback.com (J.T. Conklin)
To: gdb@sourceware.cygnus.com
Subject: remote protocol extension for step out of range
Date: Thu, 25 Jan 2001 19:50:00 -0000
Message-id: <5mwvbjj7k8.fsf@jtc.redback.com>
X-SW-Source: 2001-01/msg00188.html
Content-length: 1945

As I mentioned a few weeks ago, I'd like to add the ability for
step-out-of range to the remote protocol.  While there are still some
unresolved issues about how the range limits should be obtained by the
to_resume vector function, in worst case I could do what the vxWorks
RDB back end does and access the globals step_range_start and
step_range_end.

The current remote protocol "step" command is 

        SNN[,AA..AA]
or:
        s[AA..AA]

The first form encodes a signal number to be delivered and an optional
address that becomes the new PC.  The second form only encodes the new
PC.  Note that while the protocol supports setting the PC, GDB does
not use it.

Unfortunately it would be difficult to extend either command to
contain a range because neither the sample stubs distribued with GDB
or gdbserver completely parse the step commands and return a failure
indication.  Without this, it's pretty much impossible to probe the
stub to see if it supports this extension.

Since that's not practical, I don't think there is any other solution
other than to create a new set of commands.  They could be a superset
of the existing step commands or be used only for step out of range.
I'm not sure which is better.

Step-out-of-range only commands might look like:

        ENN,SS..SS,EE..EE[,AA...AA]
or:
        eSS...SS,EE..EE[,AA..AA]

Which would step from the PC and repeat until it moved out of the
range described by SS..SS and EE..EE.  I've also preserved the ability
to set the initial PC like the existing step commands for parallelism;
I don't expect that GDB will use it either.

To be able to successfully probe for this command, there should be a
return value.  An OK or EXX response should do.  Older stubs would
return "" as they do for all unrecognized commands.

Btw, I chose 'E/e' because that was the only letter in the word 'step'
that isn't already used.

Thoughts?

        --jtc

-- 
J.T. Conklin
RedBack Networks
From lache@tu-harburg.de Fri Jan 26 03:26:00 2001
From: Jens-Christian Lache <lache@tu-harburg.de>
To: crossgcc@sources.redhat.com, gdb@sources.redhat.com
Subject: ADEOS
Date: Fri, 26 Jan 2001 03:26:00 -0000
Message-id: <01012612241406.00741@lab04>
X-SW-Source: 2001-01/msg00189.html
Content-length: 374

Hi everybody! Using your tools, I have ported ADEOS to the ARM plattfrom.
You may find it at
www.tu-harburg.de/~sejl1601
   -> Documentation

Have a look at it and give me your feedback.


Best regards,

Jens-Christian
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756
From fnasser@cygnus.com Fri Jan 26 05:51:00 2001
From: Fernando Nasser <fnasser@cygnus.com>
To: Peter Reilley <micrio@mv.com>
Cc: gdb@sources.redhat.com, Jim MacGregor <jamesm@macraigor.com>
Subject: Re: JTAG debug support for ARM
Date: Fri, 26 Jan 2001 05:51:00 -0000
Message-id: <3A7180D0.541EE527@cygnus.com>
References: <006d01c08724$ad78a030$05d145cc@ppro>
X-SW-Source: 2001-01/msg00190.html
Content-length: 4025

Peter Reilley wrote:
> 
> The site is a work in progress, not everything is there.
> I perhaps should have waited before announcing it
> publicly, but some people asked about it.   The
> source is available.   Email me and I will send it
> to you, but it is changing daily.   It will be on the
> site.
>

Peter,

I am not the Copyright holder.  It is the Free Software Foundation.
They have "given" it to the world, but under the GPL, what means that 
legally it is "owned" by the FSF.

As I said, they distribute it under a license and we are free to use and
redistribute it under this license.  Violating this license in any of its
clauses is as illegal as making illegal copies of a Microsoft product.

As I was told, the first problem that befalls on someone who distributes
GPL software and does not comply with the GPL terms is that this person or
institution has the rights to redistributed it revoked for life (at the
FSF discretion, of course).

If you distribute the software by opto-magnetic means you have the option 
of making the source available by mail, charging a reasonable fee to cover the
media, processing and mailing.  But if you make it available for downloading
you *must* make the sources available from the same site and anyone must be
able to reproduce the binary you are distributing.

With regards to the DLL issue, the GPL makes clear exemption to the Operating
System and standard programing environment libraries that are distributed
with an Operating System.  It allows for nothing that are distributed 
separately or under a fee.  As any Lawyer will explain to you, if it is not
clear that you can do it, DON'T!

I understand that you have helped set up this site and that you made it 
available with the best intentions in mind: helping people who wants to
use this product (that I hear is quite nice) and the GNU tools.  This is
very commendable but you must first convince the Copyright holder and get
an exemption from them or comply with the existing terms.

You should inform whoever is responsible from that Web site of the terms and
conditions of the GPL and the legal consequences that can result of violating
a software license in the United States of America.




 
> Pete.
> 
> -----Original Message-----
> From: Fernando Nasser <fnasser@redhat.com>
> To: Christopher Faylor <cgf@redhat.com>
> Cc: gdb@sources.redhat.com <gdb@sources.redhat.com>
> Date: Thursday, January 25, 2001 4:23 PM
> Subject: Re: JTAG debug support for ARM
> 
> >Christopher Faylor wrote:
> >>
> >> On Wed, Jan 24, 2001 at 10:01:23PM -0500, Peter Reilley wrote:
> >> >There is nothing illegal about this site.  I have done most of the
> >> >Linux and Solaris code on this site.  If you doubt this, ask them at
> >> >their regular site www.macraigor.com The Wiggler is not supported under
> >> >Linux and Solaris.  The Wiggler is supported under Windows.  Under
> >> >Linux and Solaris the Raven and Ethernet products are supported.  The
> >> >site is still a work in progress so everything is not there yet but
> >> >keep checking.
> >>
> >> Unfortunately, the question of legality is open to interpretation if the
> >> sources for the DLL are not provided and if the DLL is used with GDB.
> >>
> >
> >Furthermore, the GPL has explicit rules for Web sites: if the binary is
> >available for downloading from a site, the same site must provide the
> >sources that are necessary and sufficient to regenerate those binaries.
> >
> >Providing a link to another site where there are some sources is not
> >enough.
> >And in this case the sources pointed to are not sufficient to regenerate
> >the
> >binary nor equivalent to what was used as there are certainly changes to
> >the
> >gdb code.
> >
> >
> >--
> >Fernando Nasser
> >Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
> >2323 Yonge Street, Suite #300
> >Toronto, Ontario   M4P 2C9
> >

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From kirshenberg_haim@emc.com Fri Jan 26 09:44:00 2001
From: "kirshenberg, haim" <kirshenberg_haim@emc.com>
To: "GDB Sourceware (E-mail)" <gdb@sourceware.cygnus.com>
Subject: remote.c protocol and stubs.
Date: Fri, 26 Jan 2001 09:44:00 -0000
Message-id: <221EA3AEAB55D411A2DA00D0B774E6F755488F@marino.lss.emc.com>
X-SW-Source: 2001-01/msg00191.html
Content-length: 483

	I am working on extending i386-stub.c to support threads in a manner
that will be confirm to remote.c as is.
	I looked for definition of the remote protocol other than what is
defined in the remote.c; but didn't find any.

	Any pointer / explanation to/of the remote protocol especially the
'set thread' ('Hct....' ) will be appreciate.
	Any pointer to a xxx-stub.zzz file that support the threads for
remote.c will be appreciate too.



	best wishes and a lot of joy for all, Haim
From qqi@world.std.com Fri Jan 26 10:55:00 2001
From: Quality Quorum <qqi@world.std.com>
To: "kirshenberg, haim" <kirshenberg_haim@emc.com>
Cc: "GDB Sourceware (E-mail)" <gdb@sourceware.cygnus.com>
Subject: Re: remote.c protocol and stubs.
Date: Fri, 26 Jan 2001 10:55:00 -0000
Message-id: <Pine.SGI.4.21.0101261352430.12420-100000@world.std.com>
References: <221EA3AEAB55D411A2DA00D0B774E6F755488F@marino.lss.emc.com>
X-SW-Source: 2001-01/msg00192.html
Content-length: 874

On Fri, 26 Jan 2001, kirshenberg, haim wrote:

> 
> 	I am working on extending i386-stub.c to support threads in a manner
> that will be confirm to remote.c as is.

It is not going to work. There are problems both with remote.c and 
with protocol.

> 	I looked for definition of the remote protocol other than what is
> defined in the remote.c; but didn't find any.
> 
> 	Any pointer / explanation to/of the remote protocol especially the
> 'set thread' ('Hct....' ) will be appreciate.
> 	Any pointer to a xxx-stub.zzz file that support the threads for
> remote.c will be appreciate too.

I made an attempt to address these issues. The refernce implementation 
(gdb-4.18 and i386-stub for i386-rtems target) and docs are accessible 
from the bottom of my home page

http://world.std.com/~qqi



> 
> 
> 
> 	best wishes and a lot of joy for all, Haim
> 

Thanks,

Aleksey