This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug fortran/10154] GDB 6.6 won't display XMM registers: <error reading variable>
- From: "jim dot conyngham at amd dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: 18 May 2009 18:08:51 -0000
- Subject: [Bug fortran/10154] GDB 6.6 won't display XMM registers: <error reading variable>
- References: <20090514233216.10154.jim.conyngham@amd.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From jim dot conyngham at amd dot com 2009-05-18 18:08 -------
Sorry for the confusion -- I did not realize at first that this issue was
specific to Fortran source programs.
After more investigation, and debugging with the GDB sources, I've found that
the problem is you can't display the XMM registers if the source language is
Fortran. But they do display OK if the source language is C or C++.
A workaround for the problem is "set source c++" while debugging Fortran.
The problem is that the $xmm# registers are defined as objects of
TYPE_CODE_UNION and the Fortran language does not support unions. (The
EQUIVALENCE statement notwithstanding.)
When a user enters a "p $xmm0" command, this object is passed to the f_val_print
() function in gdb/f-valprint.c. The switch therein does not have a case
statement for that type code so the default case is executed, which throws and
error.
I've created my own local fix by implementing a case TYPE_CODE_UNION clause in
f-valprint.c, which is good enough for my own purposes as a temporary hack.
I'm attaching the diff of the patch below for information only; I am NOT
suggesting that this is an acceptable long-term solution.
Presumably, other languages besides Fortran that don't support the union type
would have the same problem.
Presumably, the same problem will be encountered when AVX registers are
supported by GDB. (I assume someone at Intel is working on this.)
-----------------------------------
605,620c605
< break;
<
< case TYPE_CODE_UNION:
< /* This is not a valid Fortran data type, but if the user is
< * debugging a Fortran source and tries to display a SIMD register
< * e.g., "print $xmm0" then we wind up here.
< * HACK: pass this to c++ language object
< */
< {
< const struct language_defn * lang_cpp = language_def (language_cplus);
< if ((lang_cpp != NULL) && (lang_cpp != current_language))
< return lang_cpp->la_val_print (type, valaddr, embedded_offset,
< address, stream, format,
< deref_ref, recurse, pretty);
< // else FALL THRU.
< }
---
> break;
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10154
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.