Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* 0324 snapshot issues
@ 2001-03-29 16:27 RDBrown
  0 siblings, 0 replies; only message in thread
From: RDBrown @ 2001-03-29 16:27 UTC (permalink / raw)
  To: gdb

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 <fnasser@redhat.com>
To: Steven Johnson <sjohnson@neurizon.net>
Cc: Andrew Cagney <ac131313@cygnus.com>, Steven Johnson <sbjohnson@ozemail.com.au>, 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 <ac131313@cygnus.com>
To: "Dan Olson (Seattle)" <dolson@dotcast.com>
Cc: "'gdb@sourceware.cygnus.com'" <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: <EC99B1554DB004429CE45256BBEDABD815B07C@DC-SRVR1.dotcast.com>
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 <cgf@redhat.com>
To: "'gdb@sources.redhat.com'" <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 <grante@visi.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: jtc@redback.com, Andrew Cagney <cagney@cygnus.com>, GDB Discussion <gdb@sources.redhat.com>
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> <o5snjxvnpk.fsf@touchme.toronto.redhat.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 <ac131313@cygnus.com>
To: Odd Lindahl <odd.lindahl@reterm.se>
Cc: "'gdb@sourceware.cygnus.com'" <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: <e89b0ca71f13be540ac8e5187315f6e1@NO-ID-FOUND.mhonarc.org>
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


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2001-03-29 16:27 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-03-29 16:27 0324 snapshot issues RDBrown

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox