* Re: GDB's bcache improved
[not found] ` <o57ljbn9vd.fsf@toenail.to.cygnus.com>
@ 1999-11-21 8:59 ` Jim Blandy
1999-11-24 8:46 ` Jim Blandy
1 sibling, 0 replies; 2+ messages in thread
From: Jim Blandy @ 1999-11-21 8:59 UTC (permalink / raw)
To: Frank Ch. Eigler; +Cc: gdb
> > 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
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: GDB's bcache improved
[not found] ` <o57ljbn9vd.fsf@toenail.to.cygnus.com>
1999-11-21 8:59 ` GDB's bcache improved Jim Blandy
@ 1999-11-24 8:46 ` Jim Blandy
1 sibling, 0 replies; 2+ messages in thread
From: Jim Blandy @ 1999-11-24 8:46 UTC (permalink / raw)
To: gdb
Okay, the bcache hash table grows now. The memory overhead is larger,
but the hash chain lengths are shorter, so the bcache is probably
faster, and its performance will scale better when debugging large
applications.
The new figures:
Made bcache hash table grow.
Luddite!
To disable command-line taunts, run gdb with "-w".
GNU gdb 4.18.1
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
Setting up the environment for debugging gdb.
Breakpoint 1 at 0x80a201b: file /ecliptic/jimb/main/comp-tools/devo/gdb/utils.c, line 644.
Breakpoint 2 at 0x809fd97: file /ecliptic/jimb/main/comp-tools/devo/gdb/top.c, line 2930.
Breakpoint 3 at 0x804eaa8: file /ecliptic/jimb/main/comp-tools/devo/gdb/main.c, line 821.
Breakpoint 3, main (argc=1, argv=0xbffff544)
at /ecliptic/jimb/main/comp-tools/devo/gdb/main.c:821
821 args.argc = argc;
Statistics for '/umbra/jimb/i686/build/comp-tools/gdb/gdb':
Number of "stab" symbols read: 205514
Number of "minimal" symbols read: 10349
Number of "partial" symbols read: 31744
Number of "types" defined: 4502
Space used by a.out string tables: 1356093
Total memory used for psymbol obstack: 1551649
Total memory used for psymbol cache: 969136
Total memory used for symbol obstack: 1584552
Total memory used for type obstack: 518932
Statistics for '/usr/lib/libncurses.so.4':
Number of "minimal" symbols read: 648
Total memory used for psymbol obstack: 4072
Total memory used for psymbol cache: 4072
Total memory used for symbol obstack: 35680
Total memory used for type obstack: 4072
Statistics for '/usr/X11R6/lib/libX11.so.6':
Number of "minimal" symbols read: 2425
Total memory used for psymbol obstack: 4072
Total memory used for psymbol cache: 4072
Total memory used for symbol obstack: 140372
Total memory used for type obstack: 4072
Statistics for '/lib/libdl.so.2':
Number of "stab" symbols read: 1701
Number of "minimal" symbols read: 61
Number of "partial" symbols read: 832
Space used by a.out string tables: 36806
Total memory used for psymbol obstack: 57266
Total memory used for psymbol cache: 32576
Total memory used for symbol obstack: 4072
Total memory used for type obstack: 4072
Statistics for '/lib/libm.so.6':
Number of "stab" symbols read: 21013
Number of "minimal" symbols read: 1264
Number of "partial" symbols read: 5712
Space used by a.out string tables: 41957
Total memory used for psymbol obstack: 107209
Total memory used for psymbol cache: 57008
Total memory used for symbol obstack: 61928
Total memory used for type obstack: 4072
Statistics for '/lib/libc.so.6':
Number of "stab" symbols read: 137855
Number of "minimal" symbols read: 3972
Number of "partial" symbols read: 26684
Space used by a.out string tables: 520856
Total memory used for psymbol obstack: 814140
Total memory used for psymbol cache: 329832
Total memory used for symbol obstack: 216424
Total memory used for type obstack: 4072
Statistics for '/lib/ld-linux.so.2':
Number of "stab" symbols read: 13541
Number of "minimal" symbols read: 303
Number of "partial" symbols read: 2245
Number of "types" defined: 626
Space used by a.out string tables: 83852
Total memory used for psymbol obstack: 124672
Total memory used for psymbol cache: 57008
Total memory used for symbol obstack: 126212
Total memory used for type obstack: 65152
Byte cache statistics for '/umbra/jimb/i686/build/comp-tools/gdb/gdb':
Cached 'partial symbol cache' statistics:
Total object count: 63488
Unique object count: 28851
Percentage of duplicates, by count: 54%
Total object size: 1507674
Unique object size: 709564
Percentage of duplicates, by size: 52%
Total memory used by bcache, including overhead: 973136
Percentage memory overhead: 37%
Net memory savings: 35%
Hash table size: 8191
Hash table population: 96%
Median hash chain length: 3
Average hash chain length: 3
Maximum hash chain length: 12
Byte cache statistics for '/usr/lib/libncurses.so.4':
Cached 'partial symbol cache' statistics:
Total object count: 0
Unique object count: 0
Percentage of duplicates, by count: (not applicable)
Total object size: 0
Unique object size: 0
Percentage of duplicates, by size: (not applicable)
Total memory used by bcache, including overhead: 0
Percentage memory overhead: (not applicable)
Net memory savings: (not applicable)
Hash table size: 0
Hash table population: (not applicable)
Median hash chain length: 0
Average hash chain length: (not applicable)
Maximum hash chain length: 0
Byte cache statistics for '/usr/X11R6/lib/libX11.so.6':
Cached 'partial symbol cache' statistics:
Total object count: 0
Unique object count: 0
Percentage of duplicates, by count: (not applicable)
Total object size: 0
Unique object size: 0
Percentage of duplicates, by size: (not applicable)
Total memory used by bcache, including overhead: 0
Percentage memory overhead: (not applicable)
Net memory savings: (not applicable)
Hash table size: 0
Hash table population: (not applicable)
Median hash chain length: 0
Average hash chain length: (not applicable)
Maximum hash chain length: 0
Byte cache statistics for '/lib/libdl.so.2':
Cached 'partial symbol cache' statistics:
Total object count: 1664
Unique object count: 1006
Percentage of duplicates, by count: 39%
Total object size: 37604
Unique object size: 23125
Percentage of duplicates, by size: 38%
Total memory used by bcache, including overhead: 35257
Percentage memory overhead: 52%
Net memory savings: 6%
Hash table size: 1021
Hash table population: 63%
Median hash chain length: 1
Average hash chain length: 0
Maximum hash chain length: 5
Byte cache statistics for '/lib/libm.so.6':
Cached 'partial symbol cache' statistics:
Total object count: 11424
Unique object count: 1847
Percentage of duplicates, by count: 83%
Total object size: 247267
Unique object size: 40078
Percentage of duplicates, by size: 83%
Total memory used by bcache, including overhead: 58938
Percentage memory overhead: 47%
Net memory savings: 76%
Hash table size: 1021
Hash table population: 83%
Median hash chain length: 2
Average hash chain length: 1
Maximum hash chain length: 7
Byte cache statistics for '/lib/libc.so.6':
Cached 'partial symbol cache' statistics:
Total object count: 53368
Unique object count: 10223
Percentage of duplicates, by count: 80%
Total object size: 1184808
Unique object size: 235800
Percentage of duplicates, by size: 80%
Total memory used by bcache, including overhead: 325796
Percentage memory overhead: 38%
Net memory savings: 72%
Hash table size: 2053
Hash table population: 99%
Median hash chain length: 5
Average hash chain length: 4
Maximum hash chain length: 13
Byte cache statistics for '/lib/ld-linux.so.2':
Cached 'partial symbol cache' statistics:
Total object count: 4490
Unique object count: 1735
Percentage of duplicates, by count: 61%
Total object size: 99728
Unique object size: 39578
Percentage of duplicates, by size: 60%
Total memory used by bcache, including overhead: 57542
Percentage memory overhead: 45%
Net memory savings: 42%
Hash table size: 1021
Hash table population: 81%
Median hash chain length: 2
Average hash chain length: 1
Maximum hash chain length: 7
^ permalink raw reply [flat|nested] 2+ messages in thread