From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23698 invoked by alias); 14 Oct 2004 13:24:06 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 23688 invoked from network); 14 Oct 2004 13:24:05 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 14 Oct 2004 13:24:05 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CI5aN-0002Oz-Ds; Thu, 14 Oct 2004 09:24:03 -0400 Date: Thu, 14 Oct 2004 14:46:00 -0000 From: Daniel Jacobowitz To: Zack Weinberg Cc: gcc-patches@gcc.gnu.org Subject: Re: RFC Speed up dbxout.c a bit Message-ID: <20041014132402.GA8948@nevyn.them.org> Mail-Followup-To: Zack Weinberg , gcc-patches@gcc.gnu.org References: <877jptn0qm.fsf@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <877jptn0qm.fsf@codesourcery.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-10/txt/msg01181.txt.bz2 On Thu, Oct 14, 2004 at 01:49:05AM -0700, Zack Weinberg wrote: > > This patch restructures dbxout.c not to use printf under any > circumstances. It also overhauls the handling of continued stabs > strings -- formerly each place that emitted part of a string would > keep count of how many characters had been emitted, and at designated > 'continuation points' the line would be split if there were too > many. This meant that DBX_CONTIN_LENGTH had to be viewed as more of a > guideline than an upper limit; there are several target headers which > complain about not being able to use the correct value. Also, this > structure forced the subsequent parameters to the .stabs directive to > be carried around in global variables. > > Now we build the .stabs string in an obstack and break it up into > appropriately-sized chunks when it's done. This means that > DBX_CONTIN_LENGTH is now accurate, and the globals go away. Note that > the obstack is used even when there is no limit on the length of a > .stabs string. This is because it would take more #ifdefs to write > straight to stdio in that case. Also, strange but true, writing > straight to stdio is slower. Yes, I profiled it. Unfortunately this won't work. Did you test on a target which breaks up stab strings? GDB (and probably other consumers) do a similar process of only putting the string back together in certain places. The majority of the code will fall down if you insert backslashes arbitrarily. I can't figure out what targets are affected, since the default is 80 rather than 0. At least MIPS, Alpha, SPARC. You could fix this but I'm not sure how many other programs may be affected. -- Daniel Jacobowitz