Re: RFC Speed up dbxout.c a bit

[Daniel Jacobowitz <drow@false.org>]

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