This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: (patch) hpjyg09: bcache optimizations


> 
> 
> 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

	 

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]