From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Meissner To: Peter Reilley Cc: gdb@sources.redhat.com Subject: Re: JTAG debug support for ARM Date: Thu, 25 Jan 2001 17:06:00 -0000 Message-id: <20010125200607.M6552@cse.cygnus.com> References: <005801c08723$9d270880$05d145cc@ppro> X-SW-Source: 2001-01/msg00185.html 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 To: Mark Kettenis , 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> 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 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 To: Peter Reilley Cc: gdb@sources.redhat.com, Jim MacGregor 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 > To: Christopher Faylor > Cc: 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" To: "GDB Sourceware (E-mail)" 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 To: "kirshenberg, haim" Cc: "GDB Sourceware (E-mail)" Subject: Re: remote.c protocol and stubs. Date: Fri, 26 Jan 2001 10:55:00 -0000 Message-id: 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