[RFA,11/42] Move processing_gcc to stabsread

Message ID 20180523045851.11660-12-tom@tromey.com
State New, archived
Headers

Commit Message

Tom Tromey May 23, 2018, 4:58 a.m. UTC
  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(-)
  

Comments

Simon Marchi July 8, 2018, 4:45 p.m. UTC | #1
On 2018-05-23 12:58 AM, Tom Tromey wrote:
> 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.

Any idea if the assignment of processing_gcc_compilation in go32-nat.c is
useful?  In looks very strange to me to set that in nat code rather than
in symbol-reading code...

Either way, it LGTM, I am fine if you leave it there to stay on the safe side,
since I suppose you couldn't test that change easily.

Simon
  
Tom Tromey July 8, 2018, 4:56 p.m. UTC | #2
>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:

Simon> On 2018-05-23 12:58 AM, Tom Tromey wrote:
>> 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.

Simon> Any idea if the assignment of processing_gcc_compilation in go32-nat.c is
Simon> useful?  In looks very strange to me to set that in nat code rather than
Simon> in symbol-reading code...

Simon> Either way, it LGTM, I am fine if you leave it there to stay on the safe side,
Simon> since I suppose you couldn't test that change easily.

Yeah, I have no idea and didn't want to mess with that.

It does seem incorrect to set it there.  Here's the email about that
change:

    https://sourceware.org/ml/gdb-patches/2000-q1/msg00710.html

Not much to go on, and long enough ago that many other parts of gdb
might well have been very different.

Anyway I tend to think that this port in particular can mostly be
approached with benign neglect.

Tom
  

Patch

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.