binutils-gdb/gdb/testsuite/gdb.python/py-xmethods.py

245 lines
7.4 KiB
Python
Raw Normal View History

# Copyright 2014-2023 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/>.
# 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):
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-05-07 22:56:20 +08:00
print("From Python <A_plus_A>:")
return obj["a"] + opr["a"]
def plus_plus_A(obj):
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-05-07 22:56:20 +08:00
print("From Python <plus_plus_A>:")
return obj["a"] + 1
def A_geta(obj):
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-05-07 22:56:20 +08:00
print("From Python <A_geta>:")
return obj["a"]
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"]
def A_getarrayind(obj, index):
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-05-07 22:56:20 +08:00
print("From Python <A_getarrayind>:")
return obj["array"][index]
def A_indexoper(obj, index):
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-05-07 22:56:20 +08:00
return obj["array"][index].reference_value()
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()
def B_indexoper(obj, index):
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-05-07 22:56:20 +08:00
return obj["array"][index].const_value().reference_value()
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
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()
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-05-07 22:56:20 +08:00
type_int = gdb.parse_and_eval("(int *) 0").type.target()
# The E class matcher and worker test two things:
# 1. xmethod returning None.
# 2. Matcher returning a list of workers.
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-05-07 22:56:20 +08:00
class E_method_char_worker(XMethodWorker):
def __init__(self):
pass
def get_arg_types(self):
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-05-07 22:56:20 +08:00
return gdb.lookup_type("char")
def get_result_type(self, obj, arg):
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-05-07 22:56:20 +08:00
return gdb.lookup_type("void")
def __call__(self, obj, arg):
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-05-07 22:56:20 +08:00
print("From Python <E_method_char>")
return None
class E_method_int_worker(XMethodWorker):
def __init__(self):
pass
def get_arg_types(self):
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-05-07 22:56:20 +08:00
return gdb.lookup_type("int")
# Note: get_result_type method elided on purpose
def __call__(self, obj, arg):
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-05-07 22:56:20 +08:00
print("From Python <E_method_int>")
return None
class E_method_matcher(XMethodMatcher):
def __init__(self):
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-05-07 22:56:20 +08:00
XMethodMatcher.__init__(self, "E_methods")
self.methods = [XMethod("method_int"), XMethod("method_char")]
def match(self, class_type, method_name):
class_tag = class_type.unqualified().tag
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-05-07 22:56:20 +08:00
if not re.match("^dop::E$", class_tag):
return None
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-05-07 22:56:20 +08:00
if not re.match("^method$", method_name):
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.
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-05-07 22:56:20 +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):
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
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
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):
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-05-07 22:56:20 +08:00
print("From Python G<>::size_mul()")
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):
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-05-07 22:56:20 +08:00
print("From Python G<>::mul()")
return obj["t"] * arg
class G_methods_matcher(XMethodMatcher):
def __init__(self):
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-05-07 22:56:20 +08:00
XMethodMatcher.__init__(self, "G_methods")
self.methods = [XMethod("size_diff"), XMethod("size_mul"), XMethod("mul")]
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
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-05-07 22:56:20 +08:00
if not re.match("^dop::G<[ ]*[_a-zA-Z][ _a-zA-Z0-9]*>$", class_tag):
return None
t_name = class_tag[7:-1]
try:
t_type = gdb.lookup_type(t_name)
except gdb.error:
return None
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
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"):
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
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-05-07 22:56:20 +08:00
if re.match("^size_mul<[ ]*[0-9]+[ ]*>$", method_name):
if not self._is_enabled("size_mul"):
return None
m_val = int(method_name[9:-1])
return G_size_mul_worker(t_type, m_val)
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
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"):
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 = [
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
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
),
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
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
),
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
2021-05-07 22:56:20 +08:00
SimpleXMethodMatcher(
r"B_indexoper", r"^dop::B$", r"operator\[\]", B_indexoper, type_int
),
]
for matcher in global_dm_list:
gdb.xmethod.register_xmethod_matcher(gdb, matcher)
gdb: re-format Python files using black 21.4b0 Re-format all Python files using black [1] version 21.4b0. The goal is that from now on, we keep all Python files formatted using black. And that we never have to discuss formatting during review (for these files at least) ever again. One change is needed in gdb.python/py-prettyprint.exp, because it matches the string representation of an exception, which shows source code. So the change in formatting must be replicated in the expected regexp. To document our usage of black I plan on adding this to the "GDB Python Coding Standards" wiki page [2]: --8<-- All Python source files under the `gdb/` directory must be formatted using black version 21.4b0. This specific version can be installed using: $ pip3 install 'black == 21.4b0' All you need to do to re-format files is run `black <file/directory>`, and black will re-format any Python file it finds in there. It runs quite fast, so the simplest is to do: $ black gdb/ from the top-level. If you notice that black produces changes unrelated to your patch, it's probably because someone forgot to run it before you. In this case, don't include unrelated hunks in your patch. Push an obvious patch fixing the formatting and rebase your work on top of that. -->8-- Once this is merged, I plan on setting a up an `ignoreRevsFile` config so that git-blame ignores this commit, as described here: https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame I also plan on working on a git commit hook (checked in the repo) to automatically check the formatting of the Python files on commit. [1] https://pypi.org/project/black/ [2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards gdb/ChangeLog: * Re-format all Python files using black. gdb/testsuite/ChangeLog: * Re-format all Python files using black. * gdb.python/py-prettyprint.exp (run_lang_tests): Adjust. Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
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())