aboutsummaryrefslogtreecommitdiff
path: root/gdb/cp-namespace.c
diff options
context:
space:
mode:
authorWalfred Tedeschi <walfred.tedeschi@intel.com>2016-07-07 17:33:05 +0200
committerWalfred Tedeschi <walfred.tedeschi@intel.com>2016-07-07 17:33:05 +0200
commit4f19a0e6b45c63c0b4afe27a19d144cca412d4ae (patch)
treeef85ba9f2225c91d57122d5d32b1555c3f5d9f5a /gdb/cp-namespace.c
parent3a5ce9503e93fd5b10ddbc4e54fbf6e2e3b46819 (diff)
downloadbinutils-4f19a0e6b45c63c0b4afe27a19d144cca412d4ae.zip
binutils-4f19a0e6b45c63c0b4afe27a19d144cca412d4ae.tar.gz
binutils-4f19a0e6b45c63c0b4afe27a19d144cca412d4ae.tar.bz2
Fix of default lookup for "this" symbol.
Using the default lookup for the symbol "this" might lead to segmentation fault in GDB. Some languages, e.g. Fortran, use as default lookup routine the C++ routines. For those languages "this" can be the instance of a class or even the definition of a class. When an instance of a class having the name "this" is evaluated in GDB a segmentation fault was observed. As example of the issue take into consideration the Fortran code: type foo real :: a type(bar) :: x character*7 :: b end type foo type(foo) :: this Issue appears when evaluating the variable "this" in GDB. Within the language definition structure there is a field that represents the name of the special symbol used for the C++ "this" for the language being described. The fix presented here takes into account the aforementioned field. In the case the aforementioned field is NULL "this" is not represented in the language described and the lookup should return a null_block_symbol. Tests: Performed tests with gfortran and ifort. Reviewed: https://sourceware.org/ml/gdb-patches/2016-04/msg00068.html After the commited patch: https://sourceware.org/ml/gdb-patches/2016-06/msg00364.html Patch can be applied. 2016-06-16 Walfred Tedeschi <walfred.tedeschi@intel.com> gdb/ChangeLog: * cp-namespace.c (cp_lookup_bare_symbol): Use language passed as parameter to look for the symbol "this". gdb/testsuite/ChangeLog: * gdb.fortran/derived-types.exp (result_line, result_line_2): New variables. (print this%a, print this%b, print this): New tests. * gdb.fortran/derived-types.f90 (this): New object and initialization.
Diffstat (limited to 'gdb/cp-namespace.c')
-rw-r--r--gdb/cp-namespace.c5
1 files changed, 4 insertions, 1 deletions
diff --git a/gdb/cp-namespace.c b/gdb/cp-namespace.c
index 016a42f..f34e383 100644
--- a/gdb/cp-namespace.c
+++ b/gdb/cp-namespace.c
@@ -206,10 +206,13 @@ cp_lookup_bare_symbol (const struct language_defn *langdef,
struct block_symbol lang_this;
struct type *type;
- lang_this = lookup_language_this (language_def (language_cplus), block);
+ if (langdef != NULL)
+ lang_this = lookup_language_this (langdef, block);
+
if (lang_this.symbol == NULL)
return null_block_symbol;
+
type = check_typedef (TYPE_TARGET_TYPE (SYMBOL_TYPE (lang_this.symbol)));
/* If TYPE_NAME is NULL, abandon trying to find this symbol.
This can happen for lambda functions compiled with clang++,