From mboxrd@z Thu Jan 1 00:00:00 1970 From: RDBrown@mira.net To: gdb@sources.redhat.com Subject: 0324 snapshot issues Date: Thu, 29 Mar 2001 16:27:00 -0000 Message-id: X-SW-Source: 2001-03/msg00293.html Attempting to build on alpha-dec-osf4.0e and i586-sco-sysv5uw7.1.0 using gcc-2.95.2 needed NSIG supplied since _XOPEN_SOURCE etc disable it's definition. Probably this should be done directly with autoconf. On alpha-dec-osf4.0e the gdb link failed /usr/bin/ld: Unresolved: in_solib_dynsym_resolve_code collect2: ld returned 1 exit status make[1]: *** [gdb] Error 1 Also what precisely do you want uploaded to the test results page? gdb/testsuite/gdb.log or gdb/testsuite/gdb.sum? >o a test results page be created > http://sources.redhat.com/cgi-bin/gdb.cgi > (Chris Faylor and Tom Tromey did this) --- expect/exp_trap.c.orig Tue Mar 27 00:17:00 2001 +++ expect/exp_trap.c Mon Mar 26 13:18:59 2001 @@ -22,6 +22,12 @@ #ifndef NSIG #ifdef _NSIG #define NSIG _NSIG +#else +#ifdef __osf__ /* alpha-dec-osf4.0e workaround */ +#define NSIG 49 +#else /* i586-sco-sysv5uw7.1.0 workaround */ +#define NSIG 35 +#endif #endif #endif --- expect/exp_command.c.orig Tue Mar 27 00:17:15 2001 +++ expect/exp_command.c Mon Mar 26 13:18:50 2001 @@ -53,6 +53,12 @@ #ifndef NSIG #ifdef _NSIG #define NSIG _NSIG +#else +#ifdef __osf__ /* alpha-dec-osf4.0e workaround */ +#define NSIG 49 +#else /* i586-sco-sysv5uw7.1.0 workaround */ +#define NSIG 35 +#endif #endif #endif >From fnasser@redhat.com Thu Mar 29 16:27:00 2001 From: Fernando Nasser To: Steven Johnson Cc: Andrew Cagney , Steven Johnson , gdb@sources.redhat.com Subject: Re: Register Cache. Date: Thu, 29 Mar 2001 16:27:00 -0000 Message-id: <3ABFEA3A.87B2FF9@redhat.com> References: <8AE4B526B977D411841F00A0CC334020052C28@cuz-exchange.sdesigns.net> <39AC598A.DFAF67E9@ozemail.com.au> <3ABF562F.2144AF18@cygnus.com> <3ABF5DF9.4D630216@redhat.com> <3ABFD062.17EDADAF@neurizon.net> X-SW-Source: 2001-03/msg00295.html Content-length: 1225 Steven Johnson wrote: > > Fernando Nasser wrote: > > However, I vaguely remember our register cache being a > > "write-through" cache. > > It is, unless the data you are writing is already believed to be in the > register. > > ie, Register contains 0xAA55 > > Write 0x55AA to Register, and GDB updates target register with 0x55AA > > Write 0x55AA to Register again, and GDB checks it's cache, determines > the value is already 0x55AA and does NOT write. > That is true. I forgot this little detail. > I have gotten around the issues by invalidating the register cache > between writes. This is obviously sub-optimal but it works OK. > > A better implementation would be to allow a setting on a register by > register basis that sets how it will be cached by reg-cache. At the > time of the original post, this was a fairly major undertaking. > Regcache currently seems to be undergoing changes that will make > implementing this easier but for the moment flushing works fine. > Yes, like "not cached" :-) For hardware/control registers caching is just not good. -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 >From ac131313@cygnus.com Thu Mar 29 16:27:00 2001 From: Andrew Cagney To: "Dan Olson (Seattle)" Cc: "'gdb@sourceware.cygnus.com'" Subject: Re: Hacking gdb and binutils (gas especially) Date: Thu, 29 Mar 2001 16:27:00 -0000 Message-id: <3AC21964.A88C432C@cygnus.com> References: X-SW-Source: 2001-03/msg00310.html Content-length: 685 "Dan Olson (Seattle)" wrote: > > Hi all, > > What is the best way to get a matched version of gdb and gas,binutils. I'm > tweaking BFD and opcodes and want gdb and gas to share the same libs. Right > now I'm am trying to use binutils-2.10.1 with the gdb-5.0 unique directories > moved in. Seems to kinda work but some targets I don't care about won't > build (sim/v850 - I see the problem is having libintl linked in). > > Is there a better way to get a src tree with both gdb and binutils that all > play together? >From memory: cvs -d :pserver:sources.redhat.com:/src co binutils gdb dejagnu there is also a way of mixing in GCC if you're feeling really daring :-) Andrew >From cgf@redhat.com Thu Mar 29 16:27:00 2001 From: Christopher Faylor To: "'gdb@sources.redhat.com'" Cc: jim.kleck@NetergyNet.COM Subject: Re: lost query Date: Thu, 29 Mar 2001 16:27:00 -0000 Message-id: <20010328200107.A3869@redhat.com> References: <3AC26491.D32FE995@netergynet.com> X-SW-Source: 2001-03/msg00315.html Content-length: 405 On Wed, Mar 28, 2001 at 02:24:17PM -0800, Jim Kleck wrote: >This AM Keith Seitz forwarded a query to this list for me, but I >did not get subscribed until later. Could you please forward my >amy replies that this generated? Thanks. I'm not sure whom you are addressing here, but you should refer to the mailing list archives to read past email. Check them out at: http://sources.redhat.com/ml/gdb/ cgf >From grante@visi.com Thu Mar 29 16:27:00 2001 From: Grant Edwards To: "Frank Ch. Eigler" Cc: jtc@redback.com, Andrew Cagney , GDB Discussion Subject: Re: gdb/remote - I/O Date: Thu, 29 Mar 2001 16:27:00 -0000 Message-id: <20010328144026.A3827@visi.com> References: <3ABBDDE4.7C22709D@cygnus.com> <5mhf0fov3q.fsf@jtc.redback.com> X-SW-Source: 2001-03/msg00313.html Content-length: 1533 On Wed, Mar 28, 2001 at 11:54:15AM -0500, Frank Ch. Eigler wrote: > : Most targets, even the cheap eval boards available for low end > : microcontrollers have more than one I/O channel, so I use one for > : GDB and another for system I/O. > > From the point of view of test suites and similar automated control, > the fewer physical connections, the better. Several remote debugging > protocols include console I/O already; we would like to finally bring > "remote" closer. > > : But if I needed to route I/O through GDB, I think I'd want some- > : thing richer than a single serial i/o stream. Perhaps some sort of > : lightweight filesystem layer with open/read/write/close primitives. > : [...] If we're going to change the protocol, why not make it something > : richer than a single stream? [...] > > Yes, this would be a worthwhile exercise, but is way outside > the realm of reasonably small extensions of the remote > protocol. FWIW, RDI defines several independent comm channels between host and target that are multiplexed into one data stream. The RDI target code supports open/read/write/close semantics for using the "semi-hosting" channel (or whatever it's called) to open/read/write file descriptors. I'm not recommending RDI as a good model -- RDI is an overly complicated protocol even considering the features that are supported (like semi-hosting). I don't know how well the semi-hosting stuff works, but it's there as an example of how ARM Ltd. addressed the problem. -- Grant Edwards grante@visi.com >From ac131313@cygnus.com Thu Mar 29 16:27:00 2001 From: Andrew Cagney To: Odd Lindahl Cc: "'gdb@sourceware.cygnus.com'" Subject: Re: missing headerfile windows.h Date: Thu, 29 Mar 2001 16:27:00 -0000 Message-id: <3AC21A00.1001BB9@cygnus.com> References: <10DFD823BCD8D311ACCD00805FE950B6343EFD@mail.reterm.se> X-SW-Source: 2001-03/msg00311.html Content-length: 544 Odd Lindahl wrote: > > Hi, > > I'm trying to compile gdb 5.0 and or insight 5.0 in a cygnus 1.18 > environment > with newlib 1.9.0 and binutils 2.10.1 and gcc 2.95.2 as a cross compiler > with target=arm-elf. > > I've successfully compiled binutils,newlib,gcc and when I do: > > $mkdir -p /tmp/build/gdb > $cd /tmp/build/gdb > $/src/gdb/gdb-5.0/configure --target=arm-elf \ > >--prefix=/tools \ > >--exec-prefix=/tools/H-i686-pc-cygwin \ > >-v 2>&1 | tee configure.out Try: CC="gcc -mwin32" CXX="g++ -mwin32" /.../confgure ..... Andrew >From robin.mitra@exgate.tek.com Thu Mar 29 17:53:00 2001 From: robin.mitra@exgate.tek.com To: gdb@sourceware.cygnus.com Subject: RE: Hacking gdb and binutils (gas especially) Date: Thu, 29 Mar 2001 17:53:00 -0000 Message-id: X-SW-Source: 2001-03/msg00316.html Content-length: 1003 > -----Original Message----- > From: Andrew Cagney [ mailto:ac131313@cygnus.com ] > Sent: Wednesday, March 28, 2001 7:04 PM > To: Dan Olson (Seattle) > Cc: 'gdb@sourceware.cygnus.com' > Subject: Re: Hacking gdb and binutils (gas especially) > > > "Dan Olson (Seattle)" wrote: > > > > Hi all, > > > > What is the best way to get a matched version of gdb and > gas,binutils. I'm > > tweaking BFD and opcodes and want gdb and gas to share the > same libs. Right > > now I'm am trying to use binutils-2.10.1 with the gdb-5.0 > unique directories > > moved in. Seems to kinda work but some targets I don't > care about won't > > build (sim/v850 - I see the problem is having libintl linked in). > > > > Is there a better way to get a src tree with both gdb and > binutils that all > > play together? > > From memory: > > cvs -d :pserver:sources.redhat.com:/src co binutils gdb dejagnu > And having done that, can I just do a configure and make all, or must I make specific targets? Robin