[RFA] Fix printing frame arguments for COFF debug info

[Eli Zaretskii <eliz at gnu dot org>]

Currently, debugging DJGPP programs with COFF debug info fails to
print frame arguments:

  GNU gdb (GDB) 6.8.50.20090410
  Copyright (C) 2009 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "--host=i586-pc-msdosdjgpp --target=djgpp".
  For bug reporting instructions, please see:
  <http://www.gnu.org/software/gdb/bugs/>...
  (gdb) start
  Temporary breakpoint 1 at 0x1748: file tchset.c, line 6.
  Starting program: d:/usr/djgpp/gnu/gdb-68.410/gdb/./tchset45c.exe

  Temporary breakpoint 1, main (argc=<error reading variable>,
      argv=<error reading variable>) at tchset.c:6
  6         const char *cset = locale_charset ();
  (gdb) frame
  #0  main (argc=<error reading variable>, argv=<error reading variable>)
      at tchset.c:6
  6         const char *cset = locale_charset ();

GDB 6.1 does not have this problem, and neither does the current CVS
when DWARF-2 or stabs are used.

This started to happen because of this change:

  2008-05-06  Joel Brobecker  <brobecker@adacore.com>

	  * valprint.c (val_print): Add new language parameter and use it
	  instead of using the current_language. Update calls to val_print
	  throughout.
	  (common_val_print): Add new langauge parameter and pass it to
	  val_print.
	  * stack.c (print_frame_args): Update call to common_val_print
	  using the appropriate language.

After this change, print_frame_args uses the following logic to
compute the language with which to print frame arguments:

                  /* Use the appropriate language to display our symbol,
                     unless the user forced the language to a specific
                     language.  */
                  if (language_mode == language_mode_auto)
                    language = language_def (SYMBOL_LANGUAGE (sym));
                  else
                    language = current_language;

However, it does not check the value returned by language_def.  What
if that value is itself language_auto?  If that happens, val_print
will throw an error, because language_auto does not know how to print
values -- it's just a placeholder for some other, "real" language.

And it just so happens that coffread.c:process_coff_symbol does this:

  SYMBOL_LANGUAGE (sym) = language_auto;

The first step towards solving this is to fix coffread.c, as in the
patch I suggest below.  OK to commit it?

Even if this patch is accepted, I'm not sure that's all we need to do.
At least minsyms.c:prim_record_minimal_symbol_and_info also sets the
symbol's language to language_auto.  Should we make sure neither
common_val_print nor val_print ever get language_auto as the language?
That is, should we fall back to current_language in that case?

2009-05-16  Eli Zaretskii  <eliz@gnu.org>

	* coffread.c (process_coff_symbol): Set the symbol's language to
	the language of current_subfile.

--- coffread.c~0	2009-01-03 09:57:51.000000000 +0200
+++ coffread.c	2009-05-16 19:24:27.843781500 +0300
@@ -1482,7 +1482,7 @@ process_coff_symbol (struct coff_symbol 
   memset (sym, 0, sizeof (struct symbol));
   name = cs->c_name;
   name = EXTERNAL_NAME (name, objfile->obfd);
-  SYMBOL_LANGUAGE (sym) = language_auto;
+  SYMBOL_LANGUAGE (sym) = current_subfile->language;
   SYMBOL_SET_NAMES (sym, name, strlen (name), objfile);
 
   /* default assumptions */