Re: GDB's bcache improved

[Jim Blandy <jimb@cygnus.com>]

> >     Hash table population: 100%
> >     Median hash chain length: 28
> >     Average hash chain length: 28
> >     Maximum hash chain length: 50
> >   [...]
> 
> 
> These population & chain length numbers look quite bad.  Can the hash
> table not grow?

No --- they don't grow.  :(

I think it's okay for the table population to be high --- that just
means your hash function is doing a good job of distributing objects
across the buckets.  The only assessment that matters is chain length.
But I do agree these chain lengths are not very good.
From chitti@wipinfo.soft.net Sun Nov 21 20:42:00 1999
From: Chitti Raju <chitti@wipinfo.soft.net>
To: jimb@cygnus.com (Jim Blandy)
Cc: gdb@sourceware.cygnus.com, chitti@wipinfo.soft.net
Subject: Re: 64bit GDB
Date: Sun, 21 Nov 1999 20:42:00 -0000
Message-id: <199911220443.KAA06645@gem.wipinfo.soft.net>
References: <np903r4wik.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00301.html
Content-length: 1024

> 
> > > The stock GDB distribution already works on many 64-bit targets,
> > > including Alpha, MIPS III, and PA 2.0.
> > > 
> >   sorry for mentioning the configurarion. It is solaris 2.7 & ultrasparc m/c
> >   Is there any plan to make gdb(64bit) work under this configuration.
> 
> Well, Cygnus would need a contract to do that work.  :)
> 
Was there any study(atleast) done to make gdb work on solaris2.7/sparc.
The 64bit gdb is a must for my project. For a guy new to gdb code, how long
will it take to make it work(if he spends 8hrs a day, 5days/week). rough 
estimations.  
It was mentioned that gdb works for some 64-bit targets. 
could anyone give some generic problems they have faced while making it to
work for 64-bit targets. Any guidelines on how to proceed will also be 
greatly helpful. Probably the people who have worked on the gdb 64-bit targets
can give lot more information.
repeated question: The libraries libbfd, libreadline, libopcodes etc, are they
64-bit compliant with respect to sol2.7/sparc. 
From jimb@cygnus.com Mon Nov 22 04:47:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: chitti@wipinfo.soft.net
Cc: gdb@sourceware.cygnus.com
Subject: Re: 64bit GDB
Date: Mon, 22 Nov 1999 04:47:00 -0000
Message-id: <npwvra3d8x.fsf@zwingli.cygnus.com>
References: <199911220443.KAA06645@gem.wipinfo.soft.net>
X-SW-Source: 1999-q4/msg00302.html
Content-length: 1137

> Was there any study(atleast) done to make gdb work on solaris2.7/sparc.
> The 64bit gdb is a must for my project. For a guy new to gdb code, how long
> will it take to make it work(if he spends 8hrs a day, 5days/week). rough 
> estimations.  

It depends on the guy.  You have several extant targets which have
made the 32- to 64-bit jump to use as examples: MIPS began life as a
32-bit machine, as did the PA.  I would recommend looking at MIPS,
though.  Compare gdb/config/mips/tm-mips.h vs 
gdb/config/mips/tm-mips64.h, etc.

Look also at gdb/doc/gdbint.texinfo, which describes GDB's internals.

You're welcome to ask specific questions here.  There are many people
on this list who have done ports.

> repeated question: The libraries libbfd, libreadline, libopcodes
> etc, are they 64-bit compliant with respect to sol2.7/sparc.

Repeated answer: we have the entire toolchain running on the DEC alpha
microprocessor, which is a 64-bit machine.  They have been tested and
used extensively on 64-bit machines other than the sparc.  Thus, any
problems you might find will be specific to the sparc, which seems
unlikely.

Good luck!
From jimb@cygnus.com Mon Nov 22 08:49:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb@sourceware.cygnus.com
Subject: Re: none
Date: Mon, 22 Nov 1999 08:49:00 -0000
Message-id: <npr9hi321d.fsf@zwingli.cygnus.com>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org>
X-SW-Source: 1999-q4/msg00303.html
Content-length: 2624

> Here are my $0.02 on this:
> 
> > - Assign them register numbers separate from the FP stack registers'.
> > - Assign them the same numbers as the FP stack registers, and treat them as
> >   an alternative way of looking at the FP registers' mantissas.
> > The first approach has some problems
> 
> Right.  If we do NOT treat the FP and MMX registers as the same
> registers, we are in for a lot of trouble.  the only sane way is to
> treat them as different views of the same register set.
> 
> > The problem is, we're using the same register number for %mm0 and
> > %st(0), but %mm0 doesn't really correspond to %st(0).  It depends on
> > the value of the FPU TOS register.
> 
> Yes, this is not right.  $mm0 should correspond to R0, not to $st0.
> However, I don't think it is wise to rely on the program's code to
> play by the rules (which effectively guarantee that $mm0 corresponds
> to $st0).  Some clever programmer out there is bound to produce code
> that uses FP instructions on data left from MMX instructions without
> issuing EMMS in between.  GDB should not be confused by such code.
> 
> But why is this a problem?  Can't we make the correspondence be
> dynamically computed at run time, using the current TOS?  If not, why
> not?

When the compiler allocates a variable to the MMX register MM0, it
needs to use some number in the debug info to represent MM0.  If it
allocates a variable to the FP register ST(0), it needs to use some
number.

The compiler cannot assign numbers to the absolute FP registers R0,
R1, etc. because the compiler has no idea where TOS is upon function
entry.  Whatever numbering it uses has to be TOS-dependent in some
way.

So, does the compiler use separate numbers in the debug for MMX
registers and FP stack registers, or the same numbers?

If the compiler uses separate register numbers, then we have the
problems discussed before: as far as I can tell, GDB simply isn't set
up to cope with the idea that certain bits might be part of two
registers.

If the compiler uses the same register numbers, how can the
architecture-specific code tell whether GDB is accessing MM0 (which
lives in R0) or ST(0) (which lives in R(TOS))?

Do you see the problem here?

One principle I want any solution to follow is: don't mess with the
generic part of GDB.  This is stupid ugly hair from an architecture
pushed beyond its proper limits, with crushing backward compatibility
requirements.  It's an x86 problem, and it should be addressed in
x86-specific code.

Given that restriction, I'm not sure we can do any better than the
solution I've described.  I'd love to hear suggestions.
From ebachalo@cygnus.com Mon Nov 22 13:14:00 1999
From: Eric Bachalo <ebachalo@cygnus.com>
To: chitti@wipinfo.soft.net
Cc: gdb@sourceware.cygnus.com
Subject: Re: 64bit GDB
Date: Mon, 22 Nov 1999 13:14:00 -0000
Message-id: <3839B0D5.FB1D4AC3@cygnus.com>
References: <199911201027.PAA10114@gem.wipinfo.soft.net>
X-SW-Source: 1999-q4/msg00304.html
Content-length: 802

Chitti,

http://www.cygnus.com/news/gnusolaris012199.html

As you can see from our press release, we do have a contract to support 64-bit
Solaris.  This work is quite extensive.  The 64-bit Solaris support should be
showing up in the GDB snapshots in early to late summer, 2000.


Best Regards,

Eric Bachalo



Chitti Raju wrote:
> 
> This is regarding the 64-bit version of GDB.
> I have some questions on this subject:
> 1. Is there any work in progress to make GDB 64-bit
> 2. GDB depends on libraries like libbfd, libreadline, libopcodes and libiberty
>    Are these libraries 64-bit compliant
> 3. has anyone worked on this earlier and willing to share their work.
> Even if you know some issues related to 64-bit GDB, pls feel free
> to mail me at chitti@wipinfo.soft.net
> 
> Thanks,
> Chitti.
From davidwilliams@ozemail.com.au Mon Nov 22 13:29:00 1999
From: David Williams <davidwilliams@ozemail.com.au>
To: "'gdb mail list'" <gdb@sourceware.cygnus.com>
Subject: GDB and Dragonball EZ.
Date: Mon, 22 Nov 1999 13:29:00 -0000
Message-id: <01BF358C.DD0A5A40.davidwilliams@ozemail.com.au>
X-SW-Source: 1999-q4/msg00305.html
Content-length: 1821

Hi All,

I need some help to get started in modifying the appropriate parts of GDB 
so that I can remotely debug my system.
I am using the Motorola MC68EZ328 (Dragonball EZ). It has a hardware 
breakpoint capability built in (not BDM as Dragonball is a 68000 core not 
CPU32). The hardware breakpoint capability would seem to be peculiar to 
this processor so I believe I will have to modify some parts(drivers etc) 
of GDB to use it. The processors breakpoint facility allows you to define a 
single address (and mask for ranges) to set a break-point on for either 
instruction or data accesses - read or write. This is great as can then set 
break-points in code without having to have code in RAM! A small problem is 
it only allows one hardware breakpoint to be set at a time.

Another "small" problem is that I don't have a spare RS-232 port to 
communicate to GDB with. I have only one on my system. I have two options, 
as I see it. Firstly I could share the serial port between GDB and my 
application. One problem with this approach is will make debugging the IrDA 
part of my application more difficult. Secondly I could try and implement a 
software UART using the handshaking lines. Currently I think this second 
option may be better as long as a simple half duplex software UART can be 
implemented and provide adequate communications.

Anyway what I would like to know is which parts of GDB to look at and what 
existing drivers/stubs etc I should use as templates for modification? Are 
DLDT drivers appropriate? Is GDB stub ("remote target") appropriate?

Please point me in the right direction I am currently lost in a sea of 
documentation and source code with no maps!

Note: I am currenty using ECGS 1.1.2 and have downloaded GDB 4.18 
distribution.

TIA
David Williams
davidwilliams@ozemail.com.au