2023-01-01 20:49:04 +08:00
|
|
|
# Copyright 2014-2023 Free Software Foundation, Inc.
|
2014-05-20 21:53:04 +08:00
|
|
|
|
|
|
|
# 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/>.
|
|
|
|
|
|
|
|
# This file is part of the GDB testsuite. It test the xmethods support
|
|
|
|
# in the Python extension language.
|
|
|
|
|
|
|
|
import gdb
|
|
|
|
import re
|
|
|
|
|
|
|
|
from gdb.xmethod import XMethod
|
|
|
|
from gdb.xmethod import XMethodMatcher, XMethodWorker
|
|
|
|
from gdb.xmethod import SimpleXMethodMatcher
|
|
|
|
|
|
|
|
|
|
|
|
def A_plus_A(obj, opr):
|
2021-05-07 22:56:20 +08:00
|
|
|
print("From Python <A_plus_A>:")
|
|
|
|
return obj["a"] + opr["a"]
|
2014-05-20 21:53:04 +08:00
|
|
|
|
|
|
|
|
|
|
|
def plus_plus_A(obj):
|
2021-05-07 22:56:20 +08:00
|
|
|
print("From Python <plus_plus_A>:")
|
|
|
|
return obj["a"] + 1
|
2014-05-20 21:53:04 +08:00
|
|
|
|
|
|
|
|
|
|
|
def A_geta(obj):
|
2021-05-07 22:56:20 +08:00
|
|
|
print("From Python <A_geta>:")
|
|
|
|
return obj["a"]
|
2014-05-20 21:53:04 +08:00
|
|
|
|
|
|
|
|
GDB: Ignore `max-value-size' setting with value history accesses
We have an inconsistency in value history accesses where array element
accesses cause an error for entries exceeding the currently selected
`max-value-size' setting even where such accesses successfully complete
for elements located in the inferior, e.g.:
(gdb) p/d one
$1 = 0
(gdb) p/d one_hundred
$2 = {0 <repeats 100 times>}
(gdb) p/d one_hundred[99]
$3 = 0
(gdb) set max-value-size 25
(gdb) p/d one_hundred
value requires 100 bytes, which is more than max-value-size
(gdb) p/d one_hundred[99]
$7 = 0
(gdb) p/d $2
value requires 100 bytes, which is more than max-value-size
(gdb) p/d $2[99]
value requires 100 bytes, which is more than max-value-size
(gdb)
According to our documentation the `max-value-size' setting is a safety
guard against allocating an overly large amount of memory. Moreover a
statement in documentation says, concerning this setting, that: "Setting
this variable does not affect values that have already been allocated
within GDB, only future allocations." While in the implementer-speak
the sentence may be unambiguous I think the outside user may well infer
that the setting does not apply to values previously printed.
Therefore rather than just fixing this inconsistency it seems reasonable
to lift the setting for value history accesses, under an implication
that by having been retrieved from the debuggee they have already passed
the safety check. Do it then, by suppressing the value size check in
`value_copy' -- under an observation that if the original value has been
already loaded (i.e. it's not lazy), then it must have previously passed
said check -- making the last two commands succeed:
(gdb) p/d $2
$8 = {0 <repeats 100 times>}
(gdb) p/d $2 [99]
$9 = 0
(gdb)
Expand the testsuite accordingly, covering both value history handling
and the use of `value_copy' by `make_cv_value', used by Python code.
2023-02-11 07:49:19 +08:00
|
|
|
def A_getarray(obj):
|
|
|
|
print("From Python <A_getarray>:")
|
|
|
|
return obj["array"]
|
|
|
|
|
|
|
|
|
2014-05-20 21:53:04 +08:00
|
|
|
def A_getarrayind(obj, index):
|
2021-05-07 22:56:20 +08:00
|
|
|
print("From Python <A_getarrayind>:")
|
|
|
|
return obj["array"][index]
|
|
|
|
|
2014-05-20 21:53:04 +08:00
|
|
|
|
2015-04-25 22:04:40 +08:00
|
|
|
def A_indexoper(obj, index):
|
2021-05-07 22:56:20 +08:00
|
|
|
return obj["array"][index].reference_value()
|
|
|
|
|
2015-04-25 22:04:40 +08:00
|
|
|
|
GDB: Ignore `max-value-size' setting with value history accesses
We have an inconsistency in value history accesses where array element
accesses cause an error for entries exceeding the currently selected
`max-value-size' setting even where such accesses successfully complete
for elements located in the inferior, e.g.:
(gdb) p/d one
$1 = 0
(gdb) p/d one_hundred
$2 = {0 <repeats 100 times>}
(gdb) p/d one_hundred[99]
$3 = 0
(gdb) set max-value-size 25
(gdb) p/d one_hundred
value requires 100 bytes, which is more than max-value-size
(gdb) p/d one_hundred[99]
$7 = 0
(gdb) p/d $2
value requires 100 bytes, which is more than max-value-size
(gdb) p/d $2[99]
value requires 100 bytes, which is more than max-value-size
(gdb)
According to our documentation the `max-value-size' setting is a safety
guard against allocating an overly large amount of memory. Moreover a
statement in documentation says, concerning this setting, that: "Setting
this variable does not affect values that have already been allocated
within GDB, only future allocations." While in the implementer-speak
the sentence may be unambiguous I think the outside user may well infer
that the setting does not apply to values previously printed.
Therefore rather than just fixing this inconsistency it seems reasonable
to lift the setting for value history accesses, under an implication
that by having been retrieved from the debuggee they have already passed
the safety check. Do it then, by suppressing the value size check in
`value_copy' -- under an observation that if the original value has been
already loaded (i.e. it's not lazy), then it must have previously passed
said check -- making the last two commands succeed:
(gdb) p/d $2
$8 = {0 <repeats 100 times>}
(gdb) p/d $2 [99]
$9 = 0
(gdb)
Expand the testsuite accordingly, covering both value history handling
and the use of `value_copy' by `make_cv_value', used by Python code.
2023-02-11 07:49:19 +08:00
|
|
|
def B_getarray(obj):
|
|
|
|
print("From Python <B_getarray>:")
|
|
|
|
return obj["array"].const_value()
|
|
|
|
|
|
|
|
|
2015-04-25 22:04:40 +08:00
|
|
|
def B_indexoper(obj, index):
|
2021-05-07 22:56:20 +08:00
|
|
|
return obj["array"][index].const_value().reference_value()
|
2015-04-25 22:04:40 +08:00
|
|
|
|
2014-05-20 21:53:04 +08:00
|
|
|
|
2021-05-07 22:56:20 +08:00
|
|
|
type_A = gdb.parse_and_eval("(dop::A *) 0").type.target()
|
|
|
|
type_B = gdb.parse_and_eval("(dop::B *) 0").type.target()
|
GDB: Ignore `max-value-size' setting with value history accesses
We have an inconsistency in value history accesses where array element
accesses cause an error for entries exceeding the currently selected
`max-value-size' setting even where such accesses successfully complete
for elements located in the inferior, e.g.:
(gdb) p/d one
$1 = 0
(gdb) p/d one_hundred
$2 = {0 <repeats 100 times>}
(gdb) p/d one_hundred[99]
$3 = 0
(gdb) set max-value-size 25
(gdb) p/d one_hundred
value requires 100 bytes, which is more than max-value-size
(gdb) p/d one_hundred[99]
$7 = 0
(gdb) p/d $2
value requires 100 bytes, which is more than max-value-size
(gdb) p/d $2[99]
value requires 100 bytes, which is more than max-value-size
(gdb)
According to our documentation the `max-value-size' setting is a safety
guard against allocating an overly large amount of memory. Moreover a
statement in documentation says, concerning this setting, that: "Setting
this variable does not affect values that have already been allocated
within GDB, only future allocations." While in the implementer-speak
the sentence may be unambiguous I think the outside user may well infer
that the setting does not apply to values previously printed.
Therefore rather than just fixing this inconsistency it seems reasonable
to lift the setting for value history accesses, under an implication
that by having been retrieved from the debuggee they have already passed
the safety check. Do it then, by suppressing the value size check in
`value_copy' -- under an observation that if the original value has been
already loaded (i.e. it's not lazy), then it must have previously passed
said check -- making the last two commands succeed:
(gdb) p/d $2
$8 = {0 <repeats 100 times>}
(gdb) p/d $2 [99]
$9 = 0
(gdb)
Expand the testsuite accordingly, covering both value history handling
and the use of `value_copy' by `make_cv_value', used by Python code.
2023-02-11 07:49:19 +08:00
|
|
|
type_array = gdb.parse_and_eval("(int[10] *) 0").type.target()
|
2021-05-07 22:56:20 +08:00
|
|
|
type_int = gdb.parse_and_eval("(int *) 0").type.target()
|
2014-05-20 21:53:04 +08:00
|
|
|
|
|
|
|
|
|
|
|
# The E class matcher and worker test two things:
|
|
|
|
# 1. xmethod returning None.
|
|
|
|
# 2. Matcher returning a list of workers.
|
|
|
|
|
2021-05-07 22:56:20 +08:00
|
|
|
|
2014-05-20 21:53:04 +08:00
|
|
|
class E_method_char_worker(XMethodWorker):
|
|
|
|
def __init__(self):
|
|
|
|
pass
|
|
|
|
|
|
|
|
def get_arg_types(self):
|
2021-05-07 22:56:20 +08:00
|
|
|
return gdb.lookup_type("char")
|
2014-05-20 21:53:04 +08:00
|
|
|
|
2015-04-30 04:24:21 +08:00
|
|
|
def get_result_type(self, obj, arg):
|
2021-05-07 22:56:20 +08:00
|
|
|
return gdb.lookup_type("void")
|
2015-04-30 04:24:21 +08:00
|
|
|
|
2014-05-20 21:53:04 +08:00
|
|
|
def __call__(self, obj, arg):
|
2021-05-07 22:56:20 +08:00
|
|
|
print("From Python <E_method_char>")
|
2014-05-20 21:53:04 +08:00
|
|
|
return None
|
|
|
|
|
|
|
|
|
|
|
|
class E_method_int_worker(XMethodWorker):
|
|
|
|
def __init__(self):
|
|
|
|
pass
|
|
|
|
|
|
|
|
def get_arg_types(self):
|
2021-05-07 22:56:20 +08:00
|
|
|
return gdb.lookup_type("int")
|
2014-05-20 21:53:04 +08:00
|
|
|
|
2015-04-30 04:24:21 +08:00
|
|
|
# Note: get_result_type method elided on purpose
|
|
|
|
|
2014-05-20 21:53:04 +08:00
|
|
|
def __call__(self, obj, arg):
|
2021-05-07 22:56:20 +08:00
|
|
|
print("From Python <E_method_int>")
|
2014-05-20 21:53:04 +08:00
|
|
|
return None
|
|
|
|
|
|
|
|
|
|
|
|
class E_method_matcher(XMethodMatcher):
|
|
|
|
def __init__(self):
|
2021-05-07 22:56:20 +08:00
|
|
|
XMethodMatcher.__init__(self, "E_methods")
|
|
|
|
self.methods = [XMethod("method_int"), XMethod("method_char")]
|
2014-05-20 21:53:04 +08:00
|
|
|
|
|
|
|
def match(self, class_type, method_name):
|
|
|
|
class_tag = class_type.unqualified().tag
|
2021-05-07 22:56:20 +08:00
|
|
|
if not re.match("^dop::E$", class_tag):
|
2014-05-20 21:53:04 +08:00
|
|
|
return None
|
2021-05-07 22:56:20 +08:00
|
|
|
if not re.match("^method$", method_name):
|
2014-05-20 21:53:04 +08:00
|
|
|
return None
|
|
|
|
workers = []
|
|
|
|
if self.methods[0].enabled:
|
|
|
|
workers.append(E_method_int_worker())
|
|
|
|
if self.methods[1].enabled:
|
|
|
|
workers.append(E_method_char_worker())
|
|
|
|
return workers
|
|
|
|
|
|
|
|
|
|
|
|
# The G class method matcher and worker illustrate how to write
|
|
|
|
# xmethod matchers and workers for template classes and template
|
|
|
|
# methods.
|
|
|
|
|
2021-05-07 22:56:20 +08:00
|
|
|
|
2014-05-20 21:53:04 +08:00
|
|
|
class G_size_diff_worker(XMethodWorker):
|
|
|
|
def __init__(self, class_template_type, method_template_type):
|
|
|
|
self._class_template_type = class_template_type
|
|
|
|
self._method_template_type = method_template_type
|
|
|
|
|
|
|
|
def get_arg_types(self):
|
|
|
|
pass
|
|
|
|
|
|
|
|
def __call__(self, obj):
|
2021-05-07 22:56:20 +08:00
|
|
|
print("From Python G<>::size_diff()")
|
|
|
|
return self._method_template_type.sizeof - self._class_template_type.sizeof
|
2014-05-20 21:53:04 +08:00
|
|
|
|
|
|
|
|
|
|
|
class G_size_mul_worker(XMethodWorker):
|
|
|
|
def __init__(self, class_template_type, method_template_val):
|
|
|
|
self._class_template_type = class_template_type
|
|
|
|
self._method_template_val = method_template_val
|
|
|
|
|
|
|
|
def get_arg_types(self):
|
|
|
|
pass
|
|
|
|
|
|
|
|
def __call__(self, obj):
|
2021-05-07 22:56:20 +08:00
|
|
|
print("From Python G<>::size_mul()")
|
2014-05-20 21:53:04 +08:00
|
|
|
return self._class_template_type.sizeof * self._method_template_val
|
|
|
|
|
|
|
|
|
|
|
|
class G_mul_worker(XMethodWorker):
|
|
|
|
def __init__(self, class_template_type, method_template_type):
|
|
|
|
self._class_template_type = class_template_type
|
|
|
|
self._method_template_type = method_template_type
|
|
|
|
|
|
|
|
def get_arg_types(self):
|
|
|
|
return self._method_template_type
|
|
|
|
|
|
|
|
def __call__(self, obj, arg):
|
2021-05-07 22:56:20 +08:00
|
|
|
print("From Python G<>::mul()")
|
|
|
|
return obj["t"] * arg
|
2014-05-20 21:53:04 +08:00
|
|
|
|
|
|
|
|
|
|
|
class G_methods_matcher(XMethodMatcher):
|
|
|
|
def __init__(self):
|
2021-05-07 22:56:20 +08:00
|
|
|
XMethodMatcher.__init__(self, "G_methods")
|
|
|
|
self.methods = [XMethod("size_diff"), XMethod("size_mul"), XMethod("mul")]
|
2014-05-20 21:53:04 +08:00
|
|
|
|
|
|
|
def _is_enabled(self, name):
|
|
|
|
for method in self.methods:
|
|
|
|
if method.name == name and method.enabled:
|
|
|
|
return True
|
|
|
|
|
|
|
|
def match(self, class_type, method_name):
|
|
|
|
class_tag = class_type.unqualified().tag
|
2021-05-07 22:56:20 +08:00
|
|
|
if not re.match("^dop::G<[ ]*[_a-zA-Z][ _a-zA-Z0-9]*>$", class_tag):
|
2014-05-20 21:53:04 +08:00
|
|
|
return None
|
|
|
|
t_name = class_tag[7:-1]
|
|
|
|
try:
|
|
|
|
t_type = gdb.lookup_type(t_name)
|
|
|
|
except gdb.error:
|
|
|
|
return None
|
2021-05-07 22:56:20 +08:00
|
|
|
if re.match("^size_diff<[ ]*[_a-zA-Z][ _a-zA-Z0-9]*>$", method_name):
|
|
|
|
if not self._is_enabled("size_diff"):
|
2014-05-20 21:53:04 +08:00
|
|
|
return None
|
|
|
|
t1_name = method_name[10:-1]
|
|
|
|
try:
|
|
|
|
t1_type = gdb.lookup_type(t1_name)
|
|
|
|
return G_size_diff_worker(t_type, t1_type)
|
|
|
|
except gdb.error:
|
|
|
|
return None
|
2021-05-07 22:56:20 +08:00
|
|
|
if re.match("^size_mul<[ ]*[0-9]+[ ]*>$", method_name):
|
|
|
|
if not self._is_enabled("size_mul"):
|
2014-05-20 21:53:04 +08:00
|
|
|
return None
|
|
|
|
m_val = int(method_name[9:-1])
|
|
|
|
return G_size_mul_worker(t_type, m_val)
|
2021-05-07 22:56:20 +08:00
|
|
|
if re.match("^mul<[ ]*[_a-zA-Z][ _a-zA-Z0-9]*>$", method_name):
|
|
|
|
if not self._is_enabled("mul"):
|
2014-05-20 21:53:04 +08:00
|
|
|
return None
|
|
|
|
t1_name = method_name[4:-1]
|
|
|
|
try:
|
|
|
|
t1_type = gdb.lookup_type(t1_name)
|
|
|
|
return G_mul_worker(t_type, t1_type)
|
|
|
|
except gdb.error:
|
|
|
|
return None
|
|
|
|
|
|
|
|
|
|
|
|
global_dm_list = [
|
2021-05-07 22:56:20 +08:00
|
|
|
SimpleXMethodMatcher(
|
|
|
|
r"A_plus_A",
|
|
|
|
r"^dop::A$",
|
|
|
|
r"operator\+",
|
|
|
|
A_plus_A,
|
|
|
|
# This is a replacement, hence match the arg type
|
|
|
|
# exactly!
|
|
|
|
type_A.const().reference(),
|
|
|
|
),
|
|
|
|
SimpleXMethodMatcher(r"plus_plus_A", r"^dop::A$", r"operator\+\+", plus_plus_A),
|
|
|
|
SimpleXMethodMatcher(r"A_geta", r"^dop::A$", r"^geta$", A_geta),
|
GDB: Ignore `max-value-size' setting with value history accesses
We have an inconsistency in value history accesses where array element
accesses cause an error for entries exceeding the currently selected
`max-value-size' setting even where such accesses successfully complete
for elements located in the inferior, e.g.:
(gdb) p/d one
$1 = 0
(gdb) p/d one_hundred
$2 = {0 <repeats 100 times>}
(gdb) p/d one_hundred[99]
$3 = 0
(gdb) set max-value-size 25
(gdb) p/d one_hundred
value requires 100 bytes, which is more than max-value-size
(gdb) p/d one_hundred[99]
$7 = 0
(gdb) p/d $2
value requires 100 bytes, which is more than max-value-size
(gdb) p/d $2[99]
value requires 100 bytes, which is more than max-value-size
(gdb)
According to our documentation the `max-value-size' setting is a safety
guard against allocating an overly large amount of memory. Moreover a
statement in documentation says, concerning this setting, that: "Setting
this variable does not affect values that have already been allocated
within GDB, only future allocations." While in the implementer-speak
the sentence may be unambiguous I think the outside user may well infer
that the setting does not apply to values previously printed.
Therefore rather than just fixing this inconsistency it seems reasonable
to lift the setting for value history accesses, under an implication
that by having been retrieved from the debuggee they have already passed
the safety check. Do it then, by suppressing the value size check in
`value_copy' -- under an observation that if the original value has been
already loaded (i.e. it's not lazy), then it must have previously passed
said check -- making the last two commands succeed:
(gdb) p/d $2
$8 = {0 <repeats 100 times>}
(gdb) p/d $2 [99]
$9 = 0
(gdb)
Expand the testsuite accordingly, covering both value history handling
and the use of `value_copy' by `make_cv_value', used by Python code.
2023-02-11 07:49:19 +08:00
|
|
|
SimpleXMethodMatcher(
|
|
|
|
r"A_getarray", r"^dop::A$", r"^getarray$", A_getarray, type_array
|
|
|
|
),
|
2021-05-07 22:56:20 +08:00
|
|
|
SimpleXMethodMatcher(
|
|
|
|
r"A_getarrayind", r"^dop::A$", r"^getarrayind$", A_getarrayind, type_int
|
|
|
|
),
|
|
|
|
SimpleXMethodMatcher(
|
|
|
|
r"A_indexoper", r"^dop::A$", r"operator\[\]", A_indexoper, type_int
|
|
|
|
),
|
GDB: Ignore `max-value-size' setting with value history accesses
We have an inconsistency in value history accesses where array element
accesses cause an error for entries exceeding the currently selected
`max-value-size' setting even where such accesses successfully complete
for elements located in the inferior, e.g.:
(gdb) p/d one
$1 = 0
(gdb) p/d one_hundred
$2 = {0 <repeats 100 times>}
(gdb) p/d one_hundred[99]
$3 = 0
(gdb) set max-value-size 25
(gdb) p/d one_hundred
value requires 100 bytes, which is more than max-value-size
(gdb) p/d one_hundred[99]
$7 = 0
(gdb) p/d $2
value requires 100 bytes, which is more than max-value-size
(gdb) p/d $2[99]
value requires 100 bytes, which is more than max-value-size
(gdb)
According to our documentation the `max-value-size' setting is a safety
guard against allocating an overly large amount of memory. Moreover a
statement in documentation says, concerning this setting, that: "Setting
this variable does not affect values that have already been allocated
within GDB, only future allocations." While in the implementer-speak
the sentence may be unambiguous I think the outside user may well infer
that the setting does not apply to values previously printed.
Therefore rather than just fixing this inconsistency it seems reasonable
to lift the setting for value history accesses, under an implication
that by having been retrieved from the debuggee they have already passed
the safety check. Do it then, by suppressing the value size check in
`value_copy' -- under an observation that if the original value has been
already loaded (i.e. it's not lazy), then it must have previously passed
said check -- making the last two commands succeed:
(gdb) p/d $2
$8 = {0 <repeats 100 times>}
(gdb) p/d $2 [99]
$9 = 0
(gdb)
Expand the testsuite accordingly, covering both value history handling
and the use of `value_copy' by `make_cv_value', used by Python code.
2023-02-11 07:49:19 +08:00
|
|
|
SimpleXMethodMatcher(
|
|
|
|
r"B_getarray", r"^dop::B$", r"^getarray$", B_getarray, type_array
|
|
|
|
),
|
2021-05-07 22:56:20 +08:00
|
|
|
SimpleXMethodMatcher(
|
|
|
|
r"B_indexoper", r"^dop::B$", r"operator\[\]", B_indexoper, type_int
|
|
|
|
),
|
2014-05-20 21:53:04 +08:00
|
|
|
]
|
|
|
|
|
|
|
|
for matcher in global_dm_list:
|
|
|
|
gdb.xmethod.register_xmethod_matcher(gdb, matcher)
|
2021-05-07 22:56:20 +08:00
|
|
|
gdb.xmethod.register_xmethod_matcher(gdb.current_progspace(), G_methods_matcher())
|
|
|
|
gdb.xmethod.register_xmethod_matcher(gdb.current_progspace(), E_method_matcher())
|