Re: RFC: Change to gdb/README

Re: RFC: Change to gdb/README

[Eli Zaretskii]

> Date: Fri, 15 Dec 2000 20:47:36 +0000
> From: Fernando Nasser <fnasser@cygnus.com>
> 
> It will be much easier if people build in a separate directory.
> 
> Is it OK to change the instructions in the gdb/README file to
> somewhat favor that choice?

I think it is a good idea, but I would suggest to say a couple of
words _why_ this is the recommended alternative.  Otherwise, the
following text:

> You can build GDB right in the source directory:
> 
>         cd gdb-5.0
>         ./configure
>         make
>         cp gdb/gdb /usr/local/bin/gdb   (or wherever you want)
> 
> However, we recommend that an empty directory be used instead:

Leaves the naive reader wondering why one way is recommended more than
the other.
From jtc@redback.com Fri Dec 15 14:56:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: additional vector function to improve  register fetch performance
Date: Fri, 15 Dec 2000 14:56:00 -0000
Message-id: <5mae9xs391.fsf@jtc.redback.com>
References: <5m3dfzj2qs.fsf@jtc.redback.com> <3A396A70.20519EF8@cygnus.com>
X-SW-Source: 2000-12/msg00107.html
Content-length: 3387

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>> Might be changed to:
>> 
>> prefetch_sp ();
>> prefetch_fp ();
>> prefetch_pc ();
>> prefetch_register (R0_REGNUM);
>> sp = read_sp ();
>> fp = read_fp ();
>> pc = read_pc ();
>> r0 = read_register (R0_REGNUM);
>> 
>> (I'm assuming the prefetch* functions are added to regcache.c to do
>> whatever housekeeping is required and call the target vector
>> function).

Andrew> To follow on from Stephane's comments.  I have a feeling that
Andrew> this would make things unnecessarily complicated.
Andrew>
Andrew> Looking at the remote case and the ``T'' packet.  There isn't
Andrew> any reason why the ``T'' packet doesn't just return all of the
Andrew> registers.  Across a TCP connection that should have zero
Andrew> marginal cost.

Note that while I primarily use the remote protocol, I am looking at
this issue of register fetch performance more generically.

The problem is that the upper layer of GDB do not communicate with the
target layer in such that a target that can perform different types of
register fetches can select the optimum one.  

This is not an issue if the target can only fetch the entire register
set.  But I think it is desirable if a target can fetch a subset of
registers so that GDB would take advantage of that ability.

Imagine a processor with 32 4-byte integer registers, 32 4-byte float-
ing point registers, and a handful of control and other miscellaneous
registers.  If registers are ascii-hex encoded, the register data will
be ~1K bytes.  On a 9600bps link, assuming no other overhead, it will
takes over one second to receive.  If there was some way to fetch only
the registers that were needed, we'd be able to significantly improve
that time.  Even if the protocol is only able to fetch a single register,
assuming "reasonable" command latency GDB might be able to issue multiple
fetch register commands in less time.

The reason I suggested a cache model is that caches and prefetching
are already well understood concepts.  

Andrew> The other thing to consider is given a request for reg N, the
Andrew> target could satisfy it by fetching an entire block of
Andrew> registers M<=N<=O and entering them all into the cache.

How are M and O selected?  A target specific back end has knowledge
about the target and can select an appropriate block: Wind River's WDB
breaks things into integer registers, floating point registers,
control registers, etc. which works quite well in practice.  But I
don't know how something similar could be done with a generic target 
like remote.c

Andrew> In away the ``G'' (registers) packet does this - you ask for
Andrew> one register and get back a block.  Unfortunatly the block is
Andrew> very very large and fixed.

Agreed.  And as long as the remote protocol only requests full packets,
performance is reasonable.  But if you added support for a fetch single
register command to complement the existing store single register 
command, I think you would find that performance would suffer because 
GDB would fetch multiple single registers when a single register fetch 
would be optimal.  Today can see the same with single register stores in
some circumstances.  

I think we could recommend that single register stores only be
implemented for those targets where DECR_PC_AFTER_BREAK != 0.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From micrio@mv.com Fri Dec 15 17:36:00 2000
From: "Peter Reilley" <micrio@mv.com>
To: "gdb mailing list" <gdb@sources.redhat.com>
Cc: "Jim McGreggor" <jamesm@macraigor.com>
Subject: Re: GDB with Macraigors Raven
Date: Fri, 15 Dec 2000 17:36:00 -0000
Message-id: <001401c06700$888ae9c0$05d145cc@ppro>
X-SW-Source: 2000-12/msg00108.html
Content-length: 706

Yes, it is compatible with the Raven but you must get it from
the www.ocdemon.com site.   GDB has been modified and
the changes have not been put in the main source tree yet.
If you are running on Linux then there are libraries and a driver
required.   If you are running on Windows then a dll is required.

Pete.


-----Original Message-----
From: brenner <joel.brenner@tchip.ch>
To: gdb mailing list <gdb@sources.redhat.com>
Date: Friday, December 15, 2000 10:01 AM
Subject: GDB with Macraigors Raven


>Is GDB 5.0 compatible with RAVEN Jtag module or Jenni from EPI?? If yes
>wath are the configuratio options?
>(at the moment I've installed GDB 5.0 but there arent target like OCD)
>
>Tanks Brenner
>

Re: RFC: Change to gdb/README

[Eli Zaretskii]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7905 bytes --]

> Date: Thu, 21 Dec 2000 17:23:20 +0000
> From: Fernando Nasser <fnasser@cygnus.com>
> 
> I believe I have addressed Eli and Frank comments.  Here it is:
> 
> ---------
> You can build GDB right in the source directory:
> 
>         cd gdb-5.0
>         ./configure
>         make
>         cp gdb/gdb /usr/local/bin/gdb   (or wherever you want)
> 
> However, we recommend that an empty directory be used instead.
> This way you do not clutter your source tree with binary files
> and will be able to create different builds with different 
> configuration options.

Thanks, this is fine with me.
From fnasser@cygnus.com Fri Dec 22 07:03:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb@sources.redhat.com, fche@cygnus.com
Subject: Re: RFC: Change to gdb/README
Date: Fri, 22 Dec 2000 07:03:00 -0000
Message-id: <3A436CFC.CE0295F6@cygnus.com>
References: <3A3A8368.1AB607D@cygnus.com> <4839-Sat16Dec2000004058+0200-eliz@is.elta.co.il> <3A423C88.6C2402C6@cygnus.com> <3405-Fri22Dec2000112140+0200-eliz@is.elta.co.il>
X-SW-Source: 2000-12/msg00130.html
Content-length: 825

It is in.

Thank you.



Eli Zaretskii wrote:
> 
> > Date: Thu, 21 Dec 2000 17:23:20 +0000
> > From: Fernando Nasser <fnasser@cygnus.com>
> >
> > I believe I have addressed Eli and Frank comments.  Here it is:
> >
> > ---------
> > You can build GDB right in the source directory:
> >
> >         cd gdb-5.0
> >         ./configure
> >         make
> >         cp gdb/gdb /usr/local/bin/gdb   (or wherever you want)
> >
> > However, we recommend that an empty directory be used instead.
> > This way you do not clutter your source tree with binary files
> > and will be able to create different builds with different
> > configuration options.
> 
> Thanks, this is fine with me.

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From cgf@redhat.com Fri Dec 22 08:14:00 2000
From: Christopher Faylor <cgf@redhat.com>
To: gdb@sources.redhat.com
Subject: [qqi@world.std.com: link update]
Date: Fri, 22 Dec 2000 08:14:00 -0000
Message-id: <20001222111413.A11450@redhat.com>
X-SW-Source: 2000-12/msg00131.html
Content-length: 668

Who's maintaining the gdb web site these days?

cgf

----- Forwarded message from Quality Quorum <qqi@world.std.com> -----

From: Quality Quorum <qqi@world.std.com>
To: sourcemaster@sources.redhat.com
Subject: link update
Date: Fri, 22 Dec 2000 00:38:45 -0500


Hi,

There are two links to my website from http://sources.redhat.com/gdb:

http://www.std.com/qqi/labslave/rproxy.html
http://www.std.com/qqi/ftp/protocol.txt

They are moved to 

http://world.std.com/~qqi/labslave/rproxy.html
http://world.std.com/~qqi/download/protocol.txt

Please, update your links and let me know, I am going to 
remove old site.

Thanks,

Aleksey


----- End forwarded message -----
From benoit.millot@cstelecom.com Tue Dec 26 06:53:00 2000
From: "Benoit MILLOT" <benoit.millot@cstelecom.com>
To: ac131313 <ac131313@cygnus.com>, "geoffk@cygnus.com" <geoffk@cygnus.com>, ML GDB <gdb@sources.redhat.com>, ramasubr@aae.uiuc.edu
Subject: Pb in making GDB5.0 --host=sparc-sun-solaris2.6 --target=ppc-eabi
Date: Tue, 26 Dec 2000 06:53:00 -0000
Message-id: <3A48B202.A5806EC@cstelecom.com>
X-SW-Source: 2000-12/msg00132.html
Content-length: 1525

Hello,

I'm working on host sparc-sun-solaris2.6 with gcc2.8.1 and
DDD3.2.1 (GDB-5.0).
I have already built on sparc for target=ppc-eabi and it
work fine.
But now using the same archive, during making an error
occurs like that:

gcc -c -g -O2 -DDEFAULT_INLINE=INLINE_LOCALS        
-DWITH_HOST_BYTE_ORDER=BIG_ENDIAN 
-DWITH_SMP=5                           
-DHAVE_TERMIOS_STRUCTURE  -DHAVE_DEVZERO    -I.
-I../../../gdb+dejagnu-20001226/sim/ppc
-I../../../gdb+dejagnu-20001226/sim/ppc/../../include
-I../../bfd
-I../../../gdb+dejagnu-20001226/sim/ppc/../../bfd
-I../../gdb
-I../../../gdb+dejagnu-20001226/sim/ppc/../../gdb 
-I../../../gdb+dejagnu-20001226/sim/ppc/../../gdb/config
-I../../../gdb+dejagnu-20001226/sim/ppc/../../mmalloc
semantics.c
make: Fatal error: Don't know how to make target
`../common/gentmap.c'
Current working directory
/home/millot/develop/gdbdev/essai/sim/ppc
*** Error code 1
make: Fatal error: Command failed for target `all'
Current working directory
/home/millot/develop/gdbdev/essai/sim
*** Error code 1
make: Fatal error: Command failed for target `all-sim'

I don't know if tool had changed but according the diff
between the old built archive and a new one (config.status
config.cache), it seems to be same.
So i have took the archive gdb+dejagnu-20001226 and the same
errors occurs. Moreover, this error seems to be similar to 
http://sources.redhat.com/ml/gdb/2000-12/msg00113.html

So I'd like to known if one tool is broken and which? or how
do I correct this.

Thanks a lot .
		Benoît
From pedwards@disaster.jaj.com Tue Dec 26 12:52:00 2000
From: Phil Edwards <pedwards@disaster.jaj.com>
To: gdb@sources.redhat.com
Subject: bad demangling, strange line numbers, caused by...?
Date: Tue, 26 Dec 2000 12:52:00 -0000
Message-id: <20001226160130.A8025@disaster.jaj.com>
X-SW-Source: 2000-12/msg00133.html
Content-length: 1516

Using current CVS gdb to debug some code built with current CVS g++.
(The code is a varation on "hello world" meant to point out some redirecting
bugs in the library; it's nothing wacky.)

Trying to step into a function gives me undemangled symbols (I thought that
the autodetection was on now?), and then an "out of range" line number
which I've never seen before.  Pressing Enter (marked as <CR> below)
still gets me into that function correctly, however.

    (gdb) n
    8           std::cout << "Hello, Filesystem World!" << std::endl;
    (gdb) s
    _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5Kc (__out=@0x21058, 
        __s=0x10d68 "Hello, Filesystem World!") at std_ostream.h:635
    Line number 635 out of range; std_ostream.h has 288 lines.
    (gdb) <CR>
    _ZNSo6sentryC1ERSo (this=0xffbef848, __os=@0x21058) at ostream.tcc:39
    39          : _M_ok(__os.good()), _M_os(__os)
    (gdb) 

std_ostream.h does an #include of ostream.tcc; both files are mentioned
above.  The line numbers are way way off for ostream.tcc though.  I suspect
that's a compiler problem, but walking through other header files which
do the same thing hasn't been a problem with this build.

If I can get the demangling thing beat, that'd be nice.  Anybody know
what's doing this?


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.
From dberlin@redhat.com Tue Dec 26 13:19:00 2000
From: Daniel Berlin <dberlin@redhat.com>
To: Phil Edwards <pedwards@disaster.jaj.com>
Cc: gdb@sources.redhat.com
Subject: Re: bad demangling, strange line numbers, caused by...?
Date: Tue, 26 Dec 2000 13:19:00 -0000
Message-id: <Pine.LNX.4.10.10012261616550.13476-100000@www.cgsoftware.com>
References: <20001226160130.A8025@disaster.jaj.com>
X-SW-Source: 2000-12/msg00134.html
Content-length: 708

On Tue, 26 Dec 2000, Phil Edwards wrote:

> 
> Using current CVS gdb to debug some code built with current CVS g++.
> (The code is a varation on "hello world" meant to point out some redirecting
> bugs in the library; it's nothing wacky.)
> 
> Trying to step into a function gives me undemangled symbols (I thought that
> the autodetection was on now?), 

No, nobody with the power over the right files has approved the change
jason made, for some reason.
Unless someone objects, i'll approve it, and take responsibility since
it's a very small change, and I can say it falls under the obvious bugfix
rule, as far as I am concerned (I'm not just pulling this out of thin air,
I really feel it does).

--Dan