binutils-gdb/gdb/testsuite/gdb.base/address_space_qualifier.exp
Felix Willgerodt 525174e886 gdb: Allow address space qualifier parsing in C++.
The goal of this patch is to allow target dependent address space qualifiers
in the C++ expression parser.  This can be useful for memory examination on
targets that actually use different address spaces in hardware without
having to deep-dive into implementation details of the whole solution.

GDB uses the @ symbol to parse address space qualifiers.  The only current
user that I am aware of is the __flash support for avr, which was added in
"Add support for the __flash qualifier on AVR"
(487d975399)
and only works for C.

One use-case of the AVR patch is:

~~~
const __flash char data_in_flash = 0xab;

int
main (void)
{
  const __flash char *pointer_to_flash = &data_in_flash;
}
~~~

~~~
(gdb) print pointer_to_flash
$1 = 0x1e8 <data_in_flash> "\253"
(gdb) print/x *pointer_to_flash
$2 = 0xab
(gdb) x/x pointer_to_flash
0x1e8 <data_in_flash>: 0xXXXXXXab
(gdb)
(gdb) p/x *(char* @flash) pointer_to_flash
$3 = 0xab
~~~

I want to enable a similar usage of e.g. @local in C++.

Before this patch (using "set debug parser on"):

~~~
(gdb) p *(int* @local) 0x1234
(...)
Reading a token: Next token is token '@' ()
Shifting token '@' ()
Entering state 46
Reading a token: Next token is token UNKNOWN_CPP_NAME (ssym<name=local, sym=(null), field_of_this=0>)
A syntax error in expression, near `local) &x'.
~~~

After:
~~~
(gdb) p *(int* @local) 0x1234
(...)
Reading a token: Next token is token '@' ()
Shifting token '@' ()
Entering state 46
Reading a token: Next token is token UNKNOWN_CPP_NAME (ssym<name=local, sym=(null), field_of_this=0>)
Shifting token UNKNOWN_CPP_NAME (ssym<name=local, sym=(null), field_of_this=0>)
Entering state 121
Reducing stack by rule 278 (line 1773):
   $1 = token UNKNOWN_CPP_NAME (ssym<name=local, sym=(null), field_of_this=0>)
-> $$ = nterm name ()
Stack now 0 49 52 76 222 337 46
Entering state 167
Reducing stack by rule 131 (line 1225):
   $1 = token '@' ()
   $2 = nterm name ()
Unknown address space specifier: "local"
~~~

The "Unknown address space qualifier" is the right behaviour, as I ran this
on a target that doesn't have multiple address spaces and therefore obviously
no support for such qualifiers.

gdb/ChangeLog:
2021-04-20  Felix Willgerodt  <felix.willgerodt@intel.com>

	* c-exp.y (single_qualifier): Handle UNKNOWN_CPP_NAME.

gdb/testsuite/ChangeLog:
2021-04-20  Felix Willgerodt  <felix.willgerodt@intel.com>

	* gdb.base/address_space_qualifier.exp: New file.
2021-04-20 08:43:09 +02:00

36 lines
1.2 KiB
Plaintext

# Copyright 2021 Free Software Foundation, Inc.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>. */
# Regression test for expression evaluation of address space qualifiers
# in C and C++.
gdb_exit
gdb_start
gdb_reinitialize_dir $srcdir/$subdir
gdb_test_no_output "set language c"
with_test_prefix "C" {
gdb_test "p *(@somerandomqualifiername int *) 0x12345678" \
"Unknown address space specifier: \"somerandomqualifiername\""
}
gdb_test_no_output "set language c++"
with_test_prefix "C++" {
gdb_test "p *(@somerandomqualifiername int *) 0x12345678" \
"Unknown address space specifier: \"somerandomqualifiername\""
}