This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: (patch) hpjyg09: bcache optimizations
- To: jimb at cygnus dot com
- Subject: Re: (patch) hpjyg09: bcache optimizations
- From: Srikanth Adayapalam <srikanth at cup dot hp dot com>
- Date: Fri, 05 Nov 1999 10:50:03 PST
- Cc: gdb-patches at sourceware dot cygnus dot com
>
>
> The first red flag here is that this patch adds a new target macro,
> BCACHE_ALLOW_DUPLICATES (in config/pa/tm-hppa.h), which is actually
> dependent on the application being debugged, not the architecture.
> Whether the bcache helps you depends on the contents of your debug
> info, not whether it's running on a PA microprocessor. Hmm.
While it is true that it is not tied to the microprocessor,
(and the placement of the macro is not ideal perhaps,) it is tied
somewhat to the HP-UX platform in that :
o The bcache is beneficial, when there is high degree of
duplication and redundancy in the debug info generated
by a set of compilers for a platform (e.g : stabs + gcc + linux.)
o and is useless and high overhead item , if there is little
or no duplication (e.g : som + HP cc + HP-UX).
On HP-UX systems, we have a tool called pxdb, which is a linker
post processor (or a debugger preprocessor if you want to look at it
that way) which runs thro the a.out and removes all duplicates. So when
gdb enters the picture there is no duplicate debug info at all. Further
this overhead is not particular to the C compiler, it is seen for all
applications compiled with HP compilers. The C compiler's case just
happened to be mentioned. That we waste 140 MB trying to eliminate the
non-existent dups was a big concern for us.
Hope this clarifies the picture. As for how to proceed with the patch,
I'll leave it to Jimmy and this forum to evolve the best course.
Thanks
Srikanth