This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: CPP + Debug Info chicken-and-egg problem
- To: Graham Stott <grahams at redhat dot com>
- Subject: Re: CPP + Debug Info chicken-and-egg problem
- From: Neil Booth <neil at daikokuya dot demon dot co dot uk>
- Date: Wed, 7 Nov 2001 20:22:16 +0000
- Cc: gcc at gcc dot gnu dot org
- References: <20011107193608.A5788@daikokuya.demon.co.uk> <3BE98F32.13622FB@redhat.com>
Graham Stott wrote:-
> Oh what a tangled web we weave.
>
> I had noticed this problem before but couldn't
> find a solution.
I _think_ I've got a solution. We can maybe split the current
cpp_start_read() into two.
1) The part that opens the input file. If -fpreprocessed, it can then
do a trivial scan to read the original file name (I already have
code for this). This would be called from the init routine. It
will create a file-change callback, both for the original open
(which does nothing debug-wise in c-lex.c), and secondly for the
"# 1 foo.c" line. c-lex.c would need to be modified to prevent
this doing things with debug hooks, and to set main_input_filename
for whatever it gets back.
2) The part that processes command line options. This is not done
for -fpreprocessed, so that is happy. For normal source, it's
business as usual since 1) has had no extra effects.
There may be unseen complications with other stuff that the callbacks
want to use that isn't initialized, but I think we should be able to
handle that somehow.
Sound workable?
Neil.