Re: (patch) hpjyg09: bcache optimizations

[Jim Blandy <jimb@cygnus.com>]

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

Ahh.  That, I didn't know.  So it would be correct to put the flag in
a file associated with a particular toolchain.

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

It's a big concern for us, too --- I'll explain why.

The memory consumed by the bcache depends only on the number of unique
strings it contains --- not on the presence or absence of duplicates.
Using pxdb has no effect on the amount of bcache memory overhead.  So
if HP is having problems with bcache memory overhead, others will have
problems, too.

It's not a toolchain-specific problem.  But disabling it is a
toolchain-specific fix.
From guo@cup.hp.com Fri Nov 05 13:36:00 1999
From: Jimmy Guo <guo@cup.hp.com>
To: gdb-patches@sourceware.cygnus.com
Subject: (patch) hpjyg13: dejagnu/lib/framework.exp
Date: Fri, 05 Nov 1999 13:36:00 -0000
Message-id: <Pine.LNX.4.10.9911051330510.12973-100000@hpcll168.cup.hp.com>
X-SW-Source: 1999-q4/msg00197.html
Content-length: 2049

Extends setup_xfail PRMS handling.  See ChangeLog.

ChangeLog:

1999-11-05	Jimmy Guo	<guo@cup.hp.com>

	* framework.exp (setup_xfail): extend PRMS number pattern to
	anything not containing '-' (target triplet spec).  This enables
	cleaner and more precise xfail message specification where
	target specific 'PRMS' numbers are specified in corresponding
	setup_xfail call instead of in the literal fail string (e.g.
	HP's bug tracking numbers associated with HP compilers on
	HP targets).

Index: dejagnu/lib/framework.exp
/opt/gnu/bin/diff -r -c -N  /view/guo.import//CLO/Components/WDB/Src/gnu/dejagnu/lib/framework.exp dejagnu/lib/framework.exp
*** /view/guo.import//CLO/Components/WDB/Src/gnu/dejagnu/lib/framework.exp	Tue Jun 22 22:46:11 1999
--- dejagnu/lib/framework.exp	Fri Jul 16 13:30:44 1999
***************
*** 417,424 ****
  # Setup a flag to control whether a failure is expected or not
  #
  # Multiple target triplet patterns can be specified for targets
! # for which the test fails.  A decimal number can be specified,
! # which is the PRMS number.
  #
  proc setup_xfail { args } {
      global xfail_flag
--- 417,424 ----
  # Setup a flag to control whether a failure is expected or not
  #
  # Multiple target triplet patterns can be specified for targets
! # for which the test fails.  A bug report ID can be specified,
! # which is a string without '-'.
  #
  proc setup_xfail { args } {
      global xfail_flag
***************
*** 428,435 ****
      set argc [ llength $args ]
      for { set i 0 } { $i < $argc } { incr i } {
  	set sub_arg [ lindex $args $i ]
! 	# is a prms number. we assume this is a number with no characters
! 	if [regexp "^\[0-9\]+$" $sub_arg] { 
  	    set xfail_prms $sub_arg
  	    continue
  	}
--- 428,435 ----
      set argc [ llength $args ]
      for { set i 0 } { $i < $argc } { incr i } {
  	set sub_arg [ lindex $args $i ]
! 	# is a prms number. we assume this is a string with no '-' characters
! 	if [regexp "^\[^\-\]+$" $sub_arg] { 
  	    set xfail_prms $sub_arg
  	    continue
  	}