Re: [patch] Correct `gcc -D' macros get ignored (PR 9873)

[Joel Brobecker <brobecker at adacore dot com>]

Hello Jan,

Sorry about the late review. I was a little scared off by the fact
that it was dealing with macro support from DWARF, but I finally got
around to looking at the DWARF reference and it's not so complex :).

> patched GCC + patched GDB:
> (gdb) info macro __STDC__
> Defined at ../.././gdb/testsuite/gdb.base/macscp1.c:0
> #define __STDC__ 1

Before we go into the details of the patch itself, I don't think
the behavior you are suggesting is right. Or at least I find it
confusing. I was expecting GDB to say "Defined from the command line"
or something like this.

What do you think?

> 	PR gdb/9873:
> 	* dwarf2read.c (dwarf_decode_macros): New variable `at_commandline'.
> 	Move the variable `macinfo_type' out of the loop.  Create a new
> 	processing pass before the current one to pre-create `current_file'.
> 	New complaint on misplaced zero/non-zero definitions/includes.
> 	Skip first DW_MACINFO_start_file with `at_commandline' set.

Regarding the patch itself, I'm a little unsure.  Are you sure that
the first start_file entry will necessarily be the actual source file?
It does seem to be the case with the example I tried:

    #include <stdio.h>
    void foo () {}

However, I wonder if this is the right approach.  What do you think
if we had a special macro_source_file for the command line? We would
initialize current_file to this special macro_source_file instead
of NULL before starting the macro decoding. Is that a workable plan
in practice?

If that works, then we'll need to enhance the "info macro" command
to take that special file into account and report that the macro
was defined using a command-line switch.

> +# Workaround ccache making lineno non-zero for command-line definitions.
> +if {[find_gcc] == "gcc" && [file executable "/usr/bin/gcc"]} {
> +    set result [catch "exec which gcc" output]
> +    if {$result == 0 && [string first "/ccache/" $output] >= -1} {
> +	lappend options "compiler=/usr/bin/gcc"
> +    }
> +}

Can you explain what this problem is about? Basically, when the gcc
used is "gcc" but you have a "/usr/bin/gcc" on your system, you check
which "gcc" is on the path, and if the patch contains the ccache
directory, then you force gcc to /usr/bin/gcc???

Apart from that, the testcase update will also depend on the question
about about the user-level behavior, so I only have a glance at it.
I'll take a look again if we determine that they test the behavior
we want.

-- 
Joel