Re: [PATCH/RFA] Don't apply line-number tweaks for non-GCC compilers

[Jim Blandy <jimb@redhat.com>]

Mark Kettenis <kettenis@sibelius.xs4all.nl> writes:
>    From: Jim Blandy <jimb@redhat.com>
>    Date: 20 Sep 2004 16:44:33 -0500
> 
> [ That earned you a nice bounce I suppose.  I've moved, and therefore
>   got rid of my cable.  On the bright side, I've now got a decent ISP
>   and a fixed IP address. ]
> 
>    Mark Kettenis <kettenis@chello.nl> writes:
>    > The line-number tweaks we do for the sake of GCC 2.95.3 mess up the
>    > line number info for non-GCC compilers that emit stabs.  In particular
>    > this makes it annoying to debug code using the Sun compilers on SPARC.
>    > This patch attempts to fix that.  Please refer to the comment in the
>    > code for details.
>    > 
>    > I deliberately did not remove the while line-number hack.  In the end
>    > that's what we should really do, but I still do most of my GDB work on
>    > systems that have GCC 2.95.3 as their default compiler, and I really
>    > like being able to run the testsuite on those platforms.
>    > 
>    > OK?
> 
>    (Thanks for finding this, Andrew.)
> 
>    Is there any reason you're not testing processing_gcc_compilation,
>    instead of checking the last N_FUN's desc?
> 
> Other than that it's a global variable?  No not really.  I suppose it
> was because the patch actually is a slimmed down version of a patch
> that tried (and failed) to distinguish between a broken GCC and a
> fixed GCC too.
> 
> Do you prefer checking processing_gcc_compilation?  I suppose it's
> better because it makes the intent clearer.

Yes, I'd prefer that.  I see processing_gcc_compilation as one of the
global variables used to communicate with buildsym.c, like the context
stack, the subfile stack, and so on.