From a3178c64fd40f4b33ce28a8765009b2b736e459f Mon Sep 17 00:00:00 2001 From: Jim Kingdon Date: Thu, 2 Sep 1993 19:12:37 +0000 Subject: [PATCH] * language.h: Add comment about current_language. --- gdb/ChangeLog | 2 ++ gdb/language.h | 14 +++++++++++++- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index bb820e75961..03ec13711a3 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,5 +1,7 @@ Thu Sep 2 00:07:36 1993 Jim Kingdon (kingdon@lioth.cygnus.com) + * language.h: Add comment about current_language. + * mips-tdep.c (_initialize_mips_tdep): Change heuristic-fence-post from var_uinteger to var_zinteger. diff --git a/gdb/language.h b/gdb/language.h index ac32290cb74..8bb76a0ca9e 100644 --- a/gdb/language.h +++ b/gdb/language.h @@ -185,7 +185,19 @@ struct language_defn /* Pointer to the language_defn for our current language. This pointer always points to *some* valid struct; it can be used without checking - it for validity. */ + it for validity. + + The current language affects expression parsing and evaluation + (FIXME: it might be cleaner to make the evaluation-related stuff + separate exp_opcodes for each different set of semantics. We + should at least think this through more clearly with respect to + what happens if the language is changed between parsing and + evaluation) and printing of things like types and arrays. It does + *not* affect symbol-reading-- each source file in a symbol-file has + its own language and we should keep track of that regardless of the + language when symbols are read. If we want some manual setting for + the language of symbol files (e.g. detecting when ".c" files are + C++), it should be a seprate setting from the current_language. */ extern const struct language_defn *current_language; -- 2.30.2