| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Replace an htab with gdb::unordered_set. I think we could also use the
dwarf2_per_cu pointer itself as the identity, basically have the
functional equivalent of:
gdb::unordered_map<dwarf2_per_cu *, cutu_reader_up>
But I kept the existing behavior of using dwarf2_per_cu::index as the
identity.
Change-Id: Ief3df9a71ac26ca7c07a7b79ca0c26c9d031c11d
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The type_unit_group is an indirection between a stmt_list_hash (possible
dwo_unit + line table section offset) and a type_unit_group_unshareable
that provides no real value. In dwarf2_per_objfile, we maintain a
stmt_list_hash -> type_unit_group mapping, and in dwarf2_per_objfile, we
maintain a type_unit_group_unshareable mapping. The type_unit_group
type is empty and only exists to have an identity and to be a link
between the two mappings.
This patch changes it so that we have a single stmt_list_hash ->
type_unit_group_unshareable mapping.
Regression tested on Debian 12 amd64 with a bunch of DWARF target
boards.
Change-Id: I9c5778ecb18963f353e9dd058e0f8152f7d8930c
Approved-By: Tom Tromey <tom@tromey.com>
|
|
dwarf2_per_bfd::{quick_file_names_table,type_unit_groups}
Change these two hash tables to use gdb::unordered_map. I changed these
two at the same time because they both use the same key, a
stmt_list_hash. Unlike other previous patches that used a
gdb::unordered_set, use an unordered_map here because the key isn't
found in the element itself (well, it was before, because of how htab
works, but it didn't need to be).
You'll notice that the type_unit_group structure is empty. That
structure isn't really needed. It is removed in the following patch.
Regression tested on Debian 12 amd64 with a bunch of DWARF target
boards.
Change-Id: Iec2289958d0f755cab8198f5b72ecab48358ba11
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This removes attribute::is_nonnegative and attribute::as_nonnegative
in favor of a call to unsigned_constant.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
I noticed that gdb doesn't handle DW_END_default. This patch adds
support for this.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes get_alignment to assume that DW_AT_alignment refers to an
unsigned value.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes read_decl_line and new_symbol to assume that
DW_AT_decl_line should refer to an unsigned value.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes dwarf2_record_block_entry_pc to issue a complaint using
the form name rather than a value. This seems more correct to me.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This introduces a new 'unsigned_constant' method on attribute. This
method can be used to get the value as an unsigned number. Unsigned
scalar forms are handled, and signed scalar forms are handled as well
provided that the value is non-negative.
Several spots in the reader that expect small DWARF-defined constants
are updated to use this new method.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This renames attribute::form_is_signed to form_is_strictly_signed. I
think this more accurately captures what it does: it says whether a
form will always use signed data -- not whether a form might use
signed data, which DW_FORM_data* do depending on context.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
On arm-linux, I run into:
...
gdb compile failed, ld: warning: enum_cond.o uses variable-size enums yet \
the output is to use 32-bit enums; use of enum values across objects may fail
UNTESTED: gdb.base/enum_cond.exp: failed to compile
...
Fix this by using -nostdlib.
Tested on arm-linux and x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
read_cutu_die_from_dwo currently returns the dwo's top-level DIE through
a parameter. Following the previous patch, all code paths end up
setting m_top_level_die. Simplify this by having read_cutu_die_from_dwo
set m_top_level_die directly. I think it's easier to understand,
because there's one less indirection to follow.
Change-Id: Ib659f1d2e38501a8fe2b5dd0ca2add3ef55e8d60
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I built an application with -gsplit-dwarf (i.e. dwo), and some CUs are
considered "dummy" by the DWARF reader. That is, the top-level DIE
(DW_TAG_compile_unit) does not have any children. Here's the skeleton:
0x0000c0cb: Compile Unit: length = 0x0000001d, format = DWARF32, version = 0x0005, unit_type = DW_UT_skeleton, abbr_offset = 0x529b, addr_size = 0x08, DWO_id = 0x0ed2693dd2a756dc (next unit at 0x0000c0ec)
0x0000c0df: DW_TAG_skeleton_unit
DW_AT_stmt_list [DW_FORM_sec_offset] (0x09dee00f)
DW_AT_dwo_name [DW_FORM_strp] ("CMakeFiles/lib_crl.dir/crl/dispatch/crl_dispatch_queue.cpp.dwo")
DW_AT_comp_dir [DW_FORM_strp] ("/home/simark/src/tdesktop/build-relwithdebuginfo-split-nogz/Telegram/lib_crl")
DW_AT_GNU_pubnames [DW_FORM_flag_present] (true)
And here's the entire debug info in the .dwo file:
.debug_info.dwo contents:
0x00000000: Compile Unit: length = 0x0000001a, format = DWARF32, version = 0x0005, unit_type = DW_UT_split_compile, abbr_offset = 0x0000, addr_size = 0x08, DWO_id = 0x0ed2693dd2a756dc (next unit at 0x0000001e)
0x00000014: DW_TAG_compile_unit
DW_AT_producer [DW_FORM_strx] ("GNU C++20 14.2.1 20250207 -mno-direct-extern-access -mtune=generic -march=x86-64 -gsplit-dwarf -g3 -gz=none -O2 -std=gnu++20 -fPIC -fno-strict-aliasing")
DW_AT_language [DW_FORM_data1] (DW_LANG_C_plus_plus_14)
DW_AT_name [DW_FORM_strx] ("/home/simark/src/tdesktop/Telegram/lib_crl/crl/dispatch/crl_dispatch_queue.cpp")
DW_AT_comp_dir [DW_FORM_strx] ("/home/simark/src/tdesktop/build-relwithdebuginfo-split-nogz/Telegram/lib_crl")
When loading the binary in GDB, I see some warnings:
$ ./gdb -q -nx --data-directory=data-directory -ex 'maint set dwarf sync on' -ex "file /home/simark/src/tdesktop/build-relwithdebuginfo-split-nogz/telegram-desktop"
Reading symbols from /home/simark/src/tdesktop/build-relwithdebuginfo-split-nogz/telegram-desktop...
DWARF Error: unexpected tag 'DW_TAG_skeleton_unit' at offset 0xc0cb
DWARF Error: unexpected tag 'DW_TAG_skeleton_unit' at offset 0xc152
DWARF Error: unexpected tag 'DW_TAG_skeleton_unit' at offset 0xc194
DWARF Error: unexpected tag 'DW_TAG_skeleton_unit' at offset 0xc1b5
(gdb)
It turns out that these errors are not really justified. What happens
is:
- cutu_reader::read_cutu_die_from_dwo return 0, indicating that the CU
is "dummy"
- back in cutu_reader::cutu_reader, we omit setting m_top_level_die to
the DIE from the dwo file, meaning that m_top_level_die keeps
pointing to the DIE from the main file (DW_TAG_skeleton_unit)
- later, in cutu_reader::prepare_one_comp_unit, there is a check that
m_top_level_die->tag is one of DW_TAG_{compile,partial,type}_unit,
which triggers
My proposal to fix this is to set m_top_level_die even if the CU is
dummy. Even if the top-level DIE does not have any children, I don't
see any reason to leave cutu_reader::m_top_level_die in a different
state than when the CU is not dummy.
While at it, set m_dummy_p directly in read_cutu_die_from_dwo, instead
of returning a value and having the caller do it. This is all inside
cutu_reader anyway.
Change-Id: I483a68a369bb461a8dfa5bf2106ab1d6a0067198
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This function, as can be seen by its comment, is a remnant of past
design. Inline its content into create_cus_hash_table.
Change-Id: Id900bae2cdce8f33bf01199fb1d366646effc76e
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The function construct_inferior_arguments (gdbsupport/common-inferior.cc)
currently escapes all special shell characters. After this commit
there will be two "levels" of quoting:
1. The current "full" quoting, where all posix shell special
characters are quoted, and
2. a new "reduced" quoting, where only the characters that GDB sees
as special (quotes and whitespace) are quoted.
After this, almost all construct_inferior_arguments calls will use the
"full" quoting, which is the current quoting. The "reduced" quoting
will be used in this commit to restore the behaviour that was lost in
the previous commit (more details below).
In the future, the reduced quoting will be useful for some additional
inferior argument that I have planned. I already posted my full
inferior argument work here:
https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com
But that series is pretty long, and wasn't getting reviewed, so I'm
posted the series in parts now.
Before the previous commit, GDB behaved like this:
$ gdb -eiex 'set startup-with-shell off' --args /tmp/exec '$FOO'
(gdb) show args
Argument list to give program being debugged when it is started is "$FOO".
Notice that with 'startup-with-shell' off, the argument was left as
just '$FOO'. But after the previous commit, this changed to:
$ gdb -eiex 'set startup-with-shell off' --args /tmp/exec '$FOO'
(gdb) show args
Argument list to give program being debugged when it is started is "\$FOO".
Now the '$' is escaped with a backslash. This commit restores the
original behaviour, as this is (currently) the only way to unquoted
shell special characters into arguments from the GDB command line.
The series that I listed above includes a new command line option for
GDB which provides a better approach for controlling the quoting of
special shell characters, but that work requires these patches to be
merged first.
I've split out the core of construct_inferior_arguments into the new
function escape_characters, which takes a set of characters to escape.
Then the two functions escape_shell_characters and
escape_gdb_characters call escape_characters with the appropriate
character sets.
Finally, construct_inferior_arguments, now takes a boolean which
indicates if we should perform full shell escaping, or just perform
the reduced escaping.
I've updated all uses of construct_inferior_arguments to pass a
suitable value to indicate what escaping to perform (mostly just
'true', but one case in main.c is different), also I've updated
inferior::set_args to take the same boolean flag, and pass it through
to construct_inferior_arguments.
Tested-By: Guinevere Larsen <guinevere@redhat.com>
|
|
In the commit:
commit 0df62bf09ecf242e3a932255d24ee54407b3c593
Date: Fri Oct 22 07:19:33 2021 +0000
gdb: Support some escaping of args with startup-with-shell being off
nat/fork-inferior.c was updated such that when we are starting an
inferior without a shell we now remove escape characters. The
benefits of this are explained in that commit, but having made this
change we can now make an additional change.
Currently, in construct_inferior_arguments, when startup_with_shell is
false we construct the inferior argument string differently than when
startup_with_shell is true; when true we apply some escaping to
special shell character, when false we don't.
This commit simplifies construct_inferior_arguments by removing the
!startup_with_shell case, and instead we now apply escaping in all
cases. This is fine because, thanks to the above commit the escaping
will be correctly removed again when we call into nat/fork-inferior.c.
We should think of construct_inferior_arguments and
nat/fork-inferior.c as needing to cooperate in order for argument
handling to work correctly.
construct_inferior_arguments converts a list of separate arguments
into a single string, and nat/fork-inferior.c splits that single
string back into a list of arguments. It is critical that, if
nat/fork-inferior.c is expecting to remove a "layer" of escapes, then
construct_inferior_arguments must add that expected "layer",
otherwise, we end up stripping more escapes than expected.
The great thing (I think) about the new configuration, is that GDB no
longer cares about startup_with_shell at the point the arguments are
being setup. We only care about startup_with_shell at the point that
the inferior is started. This means that a user can set the inferior
arguments, and then change the startup-with-shell setting, and GDB
will do what they expect.
Under the previous system, where construct_inferior_arguments changed
its behaviour based on startup_with_shell, the user had to change the
setting, and then set the arguments, otherwise, GDB might not do what
they expect.
There is one slight issue with this commit though, which will be
addressed by the next commit.
For GDB's native targets construct_inferior_arguments is reached via
two code paths; first when GDB starts and we combine arguments from
the command line, and second when the Python API is used to set the
arguments from a sequence. It's the command line argument handling
which we are interested in.
Consider this:
$ gdb --args /tmp/exec '$FOO'
(gdb) show args
Argument list to give program being debugged when it is started is "\$FOO".
Notice that the argument has become \$FOO, the '$' is now quoted.
This is because, by quoting the argument in the shell command that
started GDB, GDB was passed a literal $FOO with no quotes. In order
to ensure that the inferior sees this same value, GDB added the extra
escape character. When GDB starts with a shell we pass \$FOO, which
results in the inferior seeing a literal $FOO.
But what if the user _actually_ wanted to have the shell GDB uses to
start the inferior expand $FOO? Well, it appears this can't be done
from the command line, but from the GDB prompt we can just do:
(gdb) set args $FOO
(gdb) show args
Argument list to give program being debugged when it is started is "$FOO".
And now the inferior will see the shell expanded version of $FOO.
It might seem like we cannot achieve the same result from the GDB
command line, however, it is possible with this trick:
$ gdb -eiex 'set startup-with-shell off' --args /tmp/exec '$FOO'
(gdb) show args
Argument list to give program being debugged when it is started is "$FOO".
(gdb) show startup-with-shell
Use of shell to start subprocesses is off.
And now the $FOO is not escaped, but GDB is no longer using a shell to
start the inferior, however, we can extend our command line like this:
$ gdb -eiex 'set startup-with-shell off' \
-ex 'set startup-with-shell on' \
--args /tmp/exec '$FOO'
(gdb) show args
Argument list to give program being debugged when it is started is "$FOO".
(gdb) show startup-with-shell
Use of shell to start subprocesses is on.
Use an early-initialisation option to disable startup-with-shell, this
is done before command line argument processing, then a normal
initialisation option turns startup-with-shell back on after GDB has
processed the command line arguments!
Is this useful? Yes, absolutely. Is this a good user experience?
Absolutely not. And I plan to add a new command line option to
GDB (and gdbserver) that will allow users to achieve the same
result (this trick doesn't work in gdbserver as there's no
early-initialisation there) without having to toggle the
startup-with-shell option. The new option can be found in the series
here:
https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com
The problem is that, that series is pretty long, and getting it
reviewed is just not possible. So instead I'm posting the individual
patches in smaller blocks, to make reviews easier.
So, what's the problem? Well, by removing the !startup_with_shell
code path from GDB, there is no longer a construct_inferior_arguments
code path that doesn't quote inferior arguments, and so there's no
longer a way, from the command line, to set an unquoted '$FOO' as an
inferior argument. Obviously, this can still be done from GDB's CLI
prompt.
The trick above is completely untested, so this regression isn't going
to show up in the testsuite.
And the breakage is only temporary. In the next commit I'll add a fix
which restores the above trick.
Of course, I hope that this fix will itself, only be temporary. Once
the new command line options that I mentioned above are added, then
the fix I add in the next commit can be removed, and user should start
using the new command line option.
After this commit a whole set of tests that were added as xfail in the
above commit are now passing.
A change similar to this one can be found in this series:
https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/
which I reviewed before writing this patch. I don't think there's any
one patch in that series that exactly corresponds with this patch
though, so I've listed the author of the original series as co-author
on this patch.
Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392
Tested-By: Guinevere Larsen <guinevere@redhat.com>
|
|
I found another Ada test where LLVM optimizes away an unused local
variable. This patch fixes this problem -- but note the test now
fails for a different (currently expected) reason.
|
|
This changes a couple spots in regcache.c to use gdb::unordered_map.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes tui.c to use gdb::unordered_map. ui_file_style::color is
changed a little as well; operator< is no longer needed, but a simple
hash function is added.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes cp-namespace.c to use gdb::unordered_map.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes xml-tdesc.c to use gdb::unordered_map.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes some unit test code to use gdb:unordered_set and
gdb::unordered_map.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes corelow.c to use gdb::unordered_map.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes ravenscar.c to use gdb::unordered_map.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes a couple of files in the Python layer to use
gdb:unordered_set and gdb::unordered_map. Another use exists but I
think it is being handled by Jan's series.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes linux-procfs.c to use gdb:unordered_set.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes one spot in linux-nat.c to use gdb::unordered_map.
(There are still other spots that could be converted.)
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes the complaints code to use gdb::unordered_map.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes stap-probe.c to use gdb::unordered_map.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes inferior.h to use gdb::unordered_map.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes ada-exp.y to use gdb::unordered_map.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes symtab.c to use gdb:unordered_set.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes gdb_bfd.c to use gdb:unordered_map.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes dictionary.c to use gdb::unordered_map.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes breakpoint.c to use gdb:unordered_set.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes corelow.c to use gdb:unordered_set and
gdb::unordered_map.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes linux-nat.c:proc_mem_file to use a scoped_fd and fixes up
the users. Regression tested on x86-64 Fedora 40.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
There are currently two functions using macros SYSCALL_MAP and
UNSUPPORTED_SYSCALL_MAP: aarch64_canonicalize_syscall, and
loongarch_canonicalize_syscall.
Here [1] I propose to do the same in i386_canonicalize_syscall, using one
additional macro: SYSCALL_MAP_RENAME.
Add the same macro in aarch64_canonicalize_syscall and
loongarch_canonicalize_syscall, and use it to map aarch64_sys_mmap and
loongarch_sys_mmap to gdb_sys_mmap2.
While we're at it:
- reformat the macro definitions to be more readable,
- add missing macro undefs in aarch64_canonicalize_syscall, and
- fix indentation in aarch64_canonicalize_syscall.
No functional changes.
Tested by rebuilding on x86_64-linux.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
[1] https://sourceware.org/pipermail/gdb-patches/2025-March/216230.html
|
|
Following the previous patch, this parameter is now unused. Remove it.
Change-Id: I7e96a3ba61ad9a0d6b64f9129aeeb9a8f3da22a7
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Add a few -Wunused-* diagnostic flags that look useful. Some are known
to gcc, some to clang, some to both. Fix the fallouts.
-Wunused-const-variable=1 is understood by gcc, but not clang.
-Wunused-const-variable would be undertsood by both, but for gcc at
least it would flag the unused const variables in headers. This doesn't
make sense to me, because as soon as one source file includes a header
but doesn't use a const variable defined in that header, it's an error.
With `=1`, gcc only warns about unused const variable in the main source
file. It's not a big deal that clang doesn't understand it though: any
instance of that problem will be flagged by any gcc build.
Change-Id: Ie20d99524b3054693f1ac5b53115bb46c89a5156
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Put them one per line and sort alphabetically.
Change-Id: Idb6947d444dc6e556a75645b04f97a915bba7a59
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Update the gdb-add-index script to offer --help and --version options.
The script currently accepts the argument '-dwarf-5' with a single
leading '-'. As two '--' is more common for long options, the
preferred argument form is now '--dwarf-5', the docs have been
updated, and the new help text uses this form.
For backward compatibility, the old '-dwarf-5' form is still
accepted.
The new arguments are '--help' or '-h', but I also accept '-help' for
consistency with '-dwarf-5'. And likewise for the version argument.
Handling of the gdb-add-index script is done basically the same as for
gcore and gstack; we use config.status to create a .in file within the
build directory, which is then processed by the Makefile to create the
final script.
The difference with gdb-add-index is that I left the original script
as gdb/contrib/gdb-add-index.sh rather than renaming it to something
like gdb/contrib/gdb-add-index-1.in, which is how gcore and gstack are
handled (though they are not in the contrib directory).
The reason for this is that the contrib/cc-with-tweaks.sh script looks
for gdb-add-index.sh within the gdb/contrib/ source directory.
As the only reason we process gdb-add-index.sh into the build
directory is to support the PKGVERSION and VERSION variables, allowing
cc-with-tweaks to continue using the unprocessed version seems
harmless, and avoids having to change cc-with-tweaks.sh at all.
I tested that I can still run tests using the cc-with-gdb-index target
board, and that the installed gdb-add-index script correctly shows a
version number when asked.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The cli_styling variable is controlled by 'set style enabled on|off'
user setting, and is currently globally visible.
In a couple of places we access this variable directly, though in
ui-file.c the accesses are all performed through term_cli_styling(),
which is a function that wraps checking cli_styling along with a check
that GDB's terminal supports styling.
In a future commit, I'd plan to add a new parameter to gdb.execute()
which will allow styling to be temporarily suppressed. In an earlier
proposal, I made gdb.execute() disable styling by changing the value
of cli_styling, however, this approach has a problem.
If gdb.execute() is used to run 'show style enabled', the changing
cli_styling will change what is printed. Similarly, if gdb.execute()
is used to execute 'set style enabled on|off' then having
gdb.execute() save and restore the value of cli_styling will undo the
adjustment from 'set style enabled ...'.
So what I plan to do in the future, is add a new control flag which
can be used to temporarily disable styling.
To make this new control variable easier to add, lets force everyone
to call term_cli_styling() to check if styling is enabled or not. To
force everyone to use term_cli_styling() this commit makes cli_styling
static within gdb/cli/cli-style.c.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The following commit introduced a typo to the NEW file:
commit d21f28a067e94e0ab6548d97f650c14be76bfbde
Date: Sat Mar 15 12:03:50 2025 +0000
gdb/python: remove unused argument from builtin_disassemble
this commit fixes it.
I've also reworded the NEWS entry a little. Simon pointed out in
review that the unused argument was also documented in Python's help()
output, which I hadn't mentioned in the NEWS entry. I've updated the
NEWS entry to just highlight that the now removed argument was never
mentioned in the manual, I think that's all that really matters.
|
|
Direct replacement of an htab with a gdb::unordered_set.
Using a large test program, I see a small but consistent performance
improvement. The "file" command time goes on average from 7.88 to 7.73
seconds (~2%). To give a rough estimate of the scale of the test
program, the 8 seen_names hash tables (one for each worker thread) had
between 173846 and 866961 entries.
Change-Id: I0157cbd04bb55338bb1fcefd2690aeef52fe3afe
Approved-By: Tom Tromey <tom@tromey.com>
|
|
All 3 valid Guile pretty printer display hints are treated as the
value "string". As a result, if a printer specifies "array" or
"map", the output is instead formatted as a string.
This humble patch corrects the issue.
|
|
This commit:
commit 15e15b2d9cd3b1db68f99cd3b047352142ddfd1c
Date: Fri Sep 17 18:12:34 2021 +0100
gdb/python: implement the print_insn extension language hook
added the gdb.disassembler.builtin_disassemble Python API function.
By mistake, the implementation accepted two arguments, the second
being a "memory_source".
However, this second argument was never used, it was left over from an
earlier proposed version of the API.
Luckily, the only place the unused argument was documented was in the
NEWS file and in the output of `help(gdb.builtin_disassemble)`, and
neither of these locations really describe what the argument was, or
how it would be used. The manual only describes the first (actually
used) argument, so I think we are safe enough to delete the unused
argument.
This allows some additional cleanup, with the store for the argument
also being deleted.
As the NEWS file did originally document the second argument, I have
added a NEWS entry to explain the argument has now been removed.
This could potentially break users code if they somehow decided to
pass a second argument, however, fixing things is as simple as
removing the second (unused) argument.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
I noticed that it was not possible to return a string containing non
utf-8 characters using gdb.execute(). For example, using the binary
from the gdb.python/py-source-styling.exp test:
(gdb) file ./gdb/testsuite/outputs/gdb.python/py-source-styling/py-source-styling
Reading symbols from ./gdb/testsuite/outputs/gdb.python/py-source-styling/py-source-styling...
(gdb) set style enabled off
(gdb) list 26
21 int some_variable = 1234;
22
23 /* The following line contains a character that is non-utf-8. This is a
24 critical part of the test as Python 3 can't convert this into a string
25 using its default mechanism. */
26 char c[] = "�"; /* List this line. */
27
28 return 0;
29 }
(gdb) python print(gdb.execute('list 26', to_string=True))
Python Exception <class 'UnicodeDecodeError'>: 'utf-8' codec can't decode byte 0xc0 in position 250: invalid start byte
Error occurred in Python: 'utf-8' codec can't decode byte 0xc0 in position 250: invalid start byte
It is necessary to disable styling before the initial 'list 26',
otherwise the source will be passed through GNU source highlight, and
GNU source highlight seems to be smart enough to figure out the
character encoding, and convert it to UTF-8. This conversion is then
cached in the source cache, and the later Python gdb.execute call will
get back a pure UTF-8 string.
If source styling is disabled, then GDB caches the string without the
conversion to UTF-8, now the gdb.execute call gets back the string
with a non-UTF-8 character within it, and Python throws an error
during its attempt to create a string object.
I'm not, at this point, proposing a solution that tries to guess the
source file encoding, though I guess such a thing could be done.
Instead, I think we should make use of the host_charset(), as set by
the user with 'set host-charset ....' during the creation of the
Python string.
To do this, in execute_gdb_command, we should switch from
PyUnicode_FromString, which requires the input be a UTF-8 string, to
using PyUnicode_Decode, which allows GDB to specify the string
encoding. We will use host_charset().
With this done, it is now possible to list the file contents using
gdb.execute(), with the contents passing through a string:
(gdb) set host-charset ISO-8859-1
(gdb) python print(gdb.execute('list 26', to_string=True), end='')
21 int some_variable = 1234;
22
23 /* The following line contains a character that is non-utf-8. This is a
24 critical part of the test as Python 3 can't convert this into a string
25 using its default mechanism. */
26 char c[] = "À"; /* List this line. */
27
28 return 0;
29 }
(gdb)
There are already plenty of other places in GDB's Python code where we
use PyUnicode_Decode to create a string from something that might
contain user generated content, so I believe this is the correct
approach.
|
|
C++11 initially omitted specialization of std::hash for enumeration
types, but this was rectified in LWG issue 2148. This patch removes a
redundant specialization. Tested by rebuilding.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
After staring at the code, I got convinced that it was not possible for
load_full_comp_unit to be called while a dwarf2_cu object exists in
per_objfile for this_cu. If you follow all callers of
load_full_comp_unit, you can see that all calls to load_full_comp_unit
(except one, see below) are gated one way or another by the fact that:
per_objfile->get_cu (per_cu) == nullptr
Some calls are gated by maybe_queue_comp_unit returning true. If it
returns true, then necessarily the dwarf2_cu is unset for that per_cu.
The spot that didn't seem to check for whether the dwarf2_cu is already
set before calling load_full_comp_unit is dw2_do_instantiate_symtab. It
didn't trigger when running the testsuite, but I could imagine a made up
case where the dwarf2_cu would already be set because we looked up a DIE
reference to it (follow_die_ref) for whatever reason. Then, something
would cause the symtab for that CU to be expanded and
dw2_do_instantiate_symtab to be called.
I added a check in that function, because it seemed prudent to do so.
All other load_cu calls are gated by this check, so it makes this call
look just like the others.
Finally, because all call sites that use cutu_reader::release_cu pass
nullptr for `existing_cu` (and therefore cutu_reader creates a new
dwarf2_cu), we know that cutu_reader::release_cu will always return a
non-nullptr value. Add an assert in it and remove checks in
load_full_comp_unit and read_signatured_type.
Change-Id: I496be34bd4bf7edfa38d5135cf4bc4ccd960abe2
Approved-By: Tom Tromey <tom@tromey.com>
|
