This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH/RFA] Don't apply line-number tweaks for non-GCC compilers
- From: Jim Blandy <jimb at redhat dot com>
- To: Mark Kettenis <kettenis at sibelius dot xs4all dot nl>
- Cc: gdb-patches at sources dot redhat dot com
- Date: 20 Sep 2004 17:24:23 -0500
- Subject: Re: [PATCH/RFA] Don't apply line-number tweaks for non-GCC compilers
- References: <200408141503.i7EF38O5004624@elgar.kettenis.dyndns.org><vt2mzzkipj2.fsf@zenia.home><200409202159.i8KLxTvs041757@elgar.sibelius.xs4all.nl>
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.