[RFA 11/42] Move processing_gcc to stabsread

Tom Tromey
2018-05-23T04:59:14Z

processing_gcc is also only used by stabsread -- it is set by the
DWARF reader, but this turns out not to be needed. So, this patch
moves processing_gcc and removes the assignment from the DWARF reader.

gdb/ChangeLog
2018-05-22 Tom Tromey <tom@tromey.com>

* stabsread.h (processing_gcc_compilation): Move from buildsym.h.
* dwarf2read.c (dwarf2_start_symtab): Don't set
processing_gcc_compilation.
* buildsym.h (processing_gcc_compilation): Move to stabsread.h.
---
gdb/ChangeLog | 7 +++++++
gdb/buildsym.h | 5 -----
gdb/dwarf2read.c | 3 ---
gdb/stabsread.h | 5 +++++
4 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/gdb/buildsym.h b/gdb/buildsym.h
index 0b19c39305..01d9acc2c9 100644
--- a/gdb/buildsym.h
+++ b/gdb/buildsym.h
@@ -66,11 +66,6 @@ struct subfile

EXTERN struct subfile *current_subfile;

-/* Global variable which, when set, indicates that we are processing a
- .o file compiled with gcc */
-
-EXTERN unsigned char processing_gcc_compilation;
-
/* Record the symbols defined for each context in a list. We don't
create a struct block for the context until we know how long to
make it. */
diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index 49ce83ff20..4871787583 100644
--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -21144,9 +21144,6 @@ dwarf2_start_symtab (struct dwarf2_cu *cu,
record_debugformat ("DWARF 2");
record_producer (cu->producer);

- /* We assume that we're processing GCC output. */
- processing_gcc_compilation = 2;
-
cu->processing_has_namespace_info = 0;

return cust;
diff --git a/gdb/stabsread.h b/gdb/stabsread.h
index 7958990112..fdb404a25d 100644
--- a/gdb/stabsread.h
+++ b/gdb/stabsread.h
@@ -46,6 +46,11 @@ EXTERN unsigned int symnum;

EXTERN const char *(*next_symbol_text_func) (struct objfile *);

+/* Global variable which, when set, indicates that we are processing a
+ .o file compiled with gcc */
+
+EXTERN unsigned char processing_gcc_compilation;
+
/* Hash table of global symbols whose values are not known yet.
They are chained thru the SYMBOL_VALUE_CHAIN, since we don't
have the correct data for that slot yet.
--
2.13.6