From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: Srikanth Adayapalam Cc: gdb-patches@sourceware.cygnus.com Subject: Re: (patch) hpjyg09: bcache optimizations Date: Fri, 05 Nov 1999 13:29:00 -0000 Message-id: References: <199911051850.KAA28555@flytrap.cup.hp.com> X-SW-Source: 1999-q4/msg00196.html > 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 To: gdb-patches@sourceware.cygnus.com Subject: (patch) hpjyg13: dejagnu/lib/framework.exp Date: Fri, 05 Nov 1999 13:36:00 -0000 Message-id: X-SW-Source: 1999-q4/msg00197.html Content-length: 2049 Extends setup_xfail PRMS handling. See ChangeLog. ChangeLog: 1999-11-05 Jimmy Guo * 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 }