From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geoff Keating To: RDBrown@mira.net, RodneyBrown@mynd.com Cc: gdb@sources.redhat.com, binutils@sources.redhat.com, gnu-misc-discuss@gnu.org Subject: Re: Preferred format of Copyright statement Date: Tue, 15 Aug 2000 10:14:00 -0000 Message-id: <200008151714.KAA08521@localhost.cygnus.com> References: <200008151314.XAA00259@iji.local> X-SW-Source: 2000-08/msg00076.html > From: Rodney Brown > 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 >From fnasser@cygnus.com Tue Aug 15 12:23:00 2000 From: Fernando Nasser To: Shaun Jackman Cc: gdb list 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 To: Eli Zaretskii 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 > > > > 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