diff options
| author | Andrew Burgess <andrew.burgess@embecosm.com> | 2020-11-19 17:52:00 +0000 |
|---|---|---|
| committer | Andrew Burgess <andrew.burgess@embecosm.com> | 2020-12-23 20:53:14 +0000 |
| commit | 5cc0917c387350c47c350843e3b7a16059345529 (patch) | |
| tree | f1216a2bfd0c513658b3b1b460513267d6eb8655 /ld/testsuite/ld-x86-64/tlspie1.d | |
| parent | 1c4852651c26d88494b6c2988f9bee164f1f3d34 (diff) | |
| download | gdb-5cc0917c387350c47c350843e3b7a16059345529.zip gdb-5cc0917c387350c47c350843e3b7a16059345529.tar.gz gdb-5cc0917c387350c47c350843e3b7a16059345529.tar.bz2 | |
gdb: remove some uses of LA_PRINT_STRING
This commit removes some, but not all, uses of LA_PRINT_STRING. In
this commit I've removed those uses where there is an obvious language
object on which I can instead call the printstr method.
In the remaining 3 uses it is harder to know if the correct thing is
to call printstr on the current language, or on a specific language.
Currently obviously, we always call on the current language (as that's
what LA_PRINT_STRING does), and clearly this behaviour is good enough
right now, but is it "right"? I've left them for now and will give
them more thought in the future.
gdb/ChangeLog:
* expprint.c (print_subexp_standard): Replace uses of
LA_PRINT_STRING.
* f-valprint.c (f_language::value_print_inner): Likewise.
* guile/scm-pretty-print.c (ppscm_print_string_repr): Likewise.
* p-valprint.c (pascal_language::value_print_inner): Likewise.
* python/py-prettyprint.c (print_string_repr): Likewise.
Diffstat (limited to 'ld/testsuite/ld-x86-64/tlspie1.d')
0 files changed, 0 insertions, 0 deletions