| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The manual for gdb.Parameter says:
If NAME consists of multiple words, and no prefix parameter group
can be found, an exception is raised.
This makes sense; we cannot create a parameter within a prefix group,
if the prefix doesn't exist. And this almost works, so:
(gdb) python gdb.Parameter("xxx foo", gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN)
Python Exception <class 'RuntimeError'>: Could not find command prefix xxx.
Error occurred in Python: Could not find command prefix xxx.
The prefix 'xxx' doesn't exist, and we get an error. But, if we try
multiple levels of prefix:
(gdb) python gdb.Parameter("print xxx foo", gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN)
This completes without error, however, we didn't get what we were
maybe expecting:
(gdb) show print xxx foo
Undefined show print command: "xxx foo". Try "help show print".
But we did get:
(gdb) show print foo
The current value of 'print foo' is "off".
GDB stopped scanning the prefix string at the unknown 'xxx', and just
created the parameter there. I don't think this makes sense, nor is
it inline with the manual.
An identical problem exists with gdb.Command creation; GDB stops
parsing the prefix at the first unknown prefix, and just creates the
command there. The manual for gdb.Command says:
NAME is the name of the command. If NAME consists of multiple
words, then the initial words are looked for as prefix commands.
In this case, if one of the prefix commands does not exist, an
exception is raised.
So again, the correct action is, I believe, to raise an exception.
The problem is in gdbpy_parse_command_name (python/py-cmd.c), GDB
calls lookup_cmd_1 to look through the prefix string and return the
last prefix group. If the very first prefix word is invalid then
lookup_cmd_1 returns NULL, and this case is handled. However, if
there is a valid prefix, followed by an invalid prefix, then
lookup_cmd_1 will return a pointer to the last valid prefix list, and
will update the input argument to point to the start of the invalid
prefix word. This final case, where the input is left pointing to an
unknown prefix, was previously not handled.
I've fixed gdbpy_parse_command_name, and added tests for command and
parameter creation to cover this case.
The exact same error is present in the guile API too. The guile
documentation for make-parameter and make-command says the same things
about unknown prefixes resulting in an exception, but the same error
is present in gdbscm_parse_command_name (guile/scm-cmd.c), so I've
fixed that too, and added some tests.
|
|
|
|
Running gdb.base/errno.exp with gcc <= 13 with split DWARF results in:
$ make check TESTS="gdb.base/errno.exp" RUNTESTFLAGS="CC_FOR_TARGET=gcc-13 --target_board=fission"
(gdb) break -qualified main
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:7549: internal-error: locate_dwo_sections: Assertion `!dw_sect->readin' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
...
FAIL: gdb.base/errno.exp: macros: gdb_breakpoint: set breakpoint at main (GDB internal error)
The assert being hit has been added in 28f15782adab ("gdb/dwarf: read
multiple .debug_info.dwo sections"), but it merely exposed an existing
problem.
gcc versions <= 13 are affected by this bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409
Basically, it produces .dwo files with multiple .debug_macro.dwo
sections, with some unresolved links between them. I think that this
macro debug info is unusable, and all we can do is ignore it.
In locate_dwo_sections, if we detect a second .debug_macro.dwo section,
forget about the previous .debug_macro.dwo and any subsequent one. This
will effectively make it as if the macro debug info wasn't there at all.
The errno test seems happy with it:
# of expected passes 84
# of expected failures 8
Change-Id: I6489b4713954669bf69f6e91865063ddcd1ac2c8
Approved-By: Tom Tromey <tom@tromey.com>
|
|
For a subsequent patch, it would be easier if the loop over sections
inside locate_dwo_sections (I want to maintain some state for the
duration of the loop). Move the for loop in there. And because
locate_dwz_sections is very similar, modify that one too, to keep both
in sync.
Change-Id: I90b3d44184910cc2d86af265bb4b41828a5d2c2e
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The documentation for the Source interface says
* The path of the source to be shown in the UI.
* It is only used to locate and load the content of the source if no
* `sourceReference` is specified (or its value is 0).
but the code used `path` first. I fixed it to use `sourceReference` first.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
breakpoints/13457 discusses issues with syscall catchpoints when
following forks, lamenting that there is no coverage for the
various permutations of `follow-fork-mode' and `detach-on-fork'.
This is an attempt to try and cover some of this ground. Unfortunately
the state of syscall support when detaching after the fork is
very, very inconsistent across various architectures. [I've tested
extensively Fedora/RHEL platforms.]
Right now, the only reliable platform to run tests on is x86_64/i?86
for the specific case where we do not detach from the fork. Consequently,
this patch limits testing to those architectures.
I have updated breakpoints/13457 with my findings on failures with the
detaching case.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13457
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
FEAT_RME_GPC3 - RME Granule Protection Check 3 Extension - introduces
a method for defining a set of windows in the memory map for which
Granule Protection Checks are skipped, and instead applies a set of
default settings associated with the window.
This patch introduces the sysreg gpcbw_el3. Add -march=armv9.5-a to
access this sysreg since this feature is optional from armv9.5-a.
|
|
FEAT_OCCMO - Outer Cacheable Cache Maintenance Operation - introduces
system instructions that provides software with a mechanism to publish
writes to the Outer cache level.
|
|
In update_wait_timeout function, microseconds were not taken into account
in poll timeout computation, resulting in 100% cpu time consumption in
the event loop while waiting for a sub-second timeout.
The bug has been introduced in commit c2c6d25.
This patch adds the microseconds converted to milliseconds in poll
timeout computation. Conversion by excess (ceil) is performed to
avoid the same problem with sub-millisecond timeouts too.
|
|
Update linux_find_memory_region_ftype to take 'const std::string &'
instead of 'const char *', update the two functions which are passed
as callbacks to linux_find_memory_regions_full.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
There's no need to declare a function immediately before its
definition. Lets not do that.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Now that dump_note_entry_p is always called (see previous commit), we
can move some of the checks out of linux_make_mappings_callback into
dump_note_entry_p.
The checks only exist in linux_make_mappings_callback because, before
the previous commit, we couldn't be sure that dump_note_entry_p would
be called or not, so linux_make_mappings_callback had to run its own
checks.
Now that dump_note_entry_p is always called we can rely on that
function to filter out which mappings should result in an NT_FILE
entry, and linux_make_mappings_callback can just create an entry for
everything it is passed.
As a result of this change I was able to remove the inode argument
from linux_make_mappings_callback and
linux_find_memory_regions_thunk. The inode check has now moved to
dump_note_entry_p.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This commit moves the logic for whether should_dump_mapping_p is
called out of linux_find_memory_regions_full and pushes it down into
the two callback functions that are used as the should_dump_mapping_p
callback; `dump_mapping_p` and `dump_note_entry_p`.
Older Linux kernels don't make the 'Anonymous' information available
in the smaps file, and currently, GDB handles this by not calling the
should_dump_mapping_p callback in linux_find_memory_regions_full,
instead the answer is hard-coded to true.
This is (maybe) fine for dump_mapping_p, but for dump_note_entry_p,
this choice makes little sense. The dump_note_entry_p function
doesn't even use the anonymous mapping information.
I propose that the 'has_anonymous' check should be moved out of
linux_find_memory_regions_full, and pushed into dump_mapping_p. Then
in dump_note_entry_p there will be no has_anonymous check; it just
isn't needed.
This allows linux_find_memory_regions_full to be simplified a little,
and will allow some additional clean ups in
linux_make_mappings_callback, which is the partner function to
dump_note_entry_p (see linux_make_mappings_corefile_notes), now that
we know dump_note_entry_p is always called. This follow on clean up
will be done in a later commit in this series.
Looking at dump_mapping_p, I do wonder if the ::has_anonymous check
could be moved later in the function. The first few checks in
dump_mapping_p don't rely on the anonymous information, so running
them might give better results. However, the lack of the anonymous
information is only for older kernels, so testing any changes in this
area would likely require spinning up an older kernel, and as the
years pass, we likely care about this case less. So for now I've left
the ::has_anonymous check as the first thing in dump_mapping_p as this
keeps the existing behaviour.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Simplify the argument passing in linux_find_memory_regions_full when
calling the should_dump_mapping_p callback. Instead of pulling all
the components from the smaps_data object and passing them separately,
just pass the smaps_data object.
I think this change is justified on its own; the code seems cleaner,
and easier to read to my eye. But additionally, in a later commit in
this series I want to pass smaps_data::has_anonymous to the
should_dump_mapping_p callback, which would mean adding yet another
argument, and I think the argument list is already long enough.
Changing the function now to pass the smaps_data object means that I
will already have the ::has_anonymous field available in the later
commit.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Convert linux_dump_mapping_p_ftype to return a bool, and then update
everything that is needed to handle the fallout from this change.
There should be no user visible changes from this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Add two options to "info threads": `-stopped` and `-running`.
The purpose of these options is to filter the output of the command.
The `-stopped` option means "print stopped threads only" and,
similarly, `-running` means "print the running threads only". When
both options are provided by the user, the indication is that the user
wants the union. That is, the output contains both stopped and
running threads.
Suppose we have an application with 5 threads, 2 of which have hit a
breakpoint. The "info threads" command in the non-stop mode gives:
(gdb) info threads
Id Target Id Frame
* 1 Thread 0x7ffff7d99740 (running)
2 Thread 0x7ffff7d98700 something () at file.c:30
3 Thread 0x7ffff7597700 (running)
4 Thread 0x7ffff6d96700 something () at file.c:30
5 Thread 0x7ffff6595700 (running)
(gdb)
Using the "-stopped" flag, we get
(gdb) info threads -stopped
Id Target Id Frame
2 Thread 0x7ffff7d98700 something () at file.c:30
4 Thread 0x7ffff6d96700 something () at file.c:30
(gdb)
Using the "-running" flag, we get
(gdb) info threads -running
Id Target Id Frame
* 1 Thread 0x7ffff7d99740 (running)
3 Thread 0x7ffff7597700 (running)
5 Thread 0x7ffff6595700 (running)
(gdb)
Using both flags prints all:
(gdb) info threads -stopped -running
Id Target Id Frame
* 1 Thread 0x7ffff7d99740 (running)
2 Thread 0x7ffff7d98700 something () at file.c:30
3 Thread 0x7ffff7597700 (running)
4 Thread 0x7ffff6d96700 something () at file.c:30
5 Thread 0x7ffff6595700 (running)
(gdb)
When combined with a thread ID, filtering applies to those threads that
are matched by the ID.
(gdb) info threads 3
Id Target Id Frame
3 Thread 0x7ffff7597700 (running)
(gdb) info threads -stopped 3
No threads matched.
(gdb)
Regression-tested on X86_64 Linux.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-by: Pedro Alves <pedro@palves.net
|
|
If "info threads" is provided with the thread ID argument but no such
threads matching the thread ID(s) are found, GDB prints
No threads match '<ID...>'.
Update this output to the more generalized
No threads matched.
The intention is that the next patch, and potentially future ones,
will extend the command with more filter/match arguments. We cannot
customize the output to each such argument. Hence, be more generic.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-by: Pedro Alves <pedro@palves.net
|
|
The "info threads" command tracks its options in a struct named
'info_threads_opts', which currently has only one option. Pass the
whole options object to helper functions, instead of passing
the option value individually. This is a refactoring to make adding
more options easier.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-by: Pedro Alves <pedro@palves.net
|
|
|
|
Fix a fuzzer testcase where a large positive line_delta causes signed
overflow when subtracting -5. Signed overflow is perfectly OK here.
|
|
This completely bogus oss-fuzz x86 testcase results in a read from an
uninitialised (at the time check_eh_frame is called) part of an insn
frag:
.section .debug_frame
orl $1,x
.long x
.uleb128 0,x,0
x:
Fix the problem by verifying the assumption in get_cie_info that a CIE
starts at the beginning of .eh_frame or .debug_frame. Or at least
exclude silliness involving instructions placed there. That seems a
useful sanity check. Also sanity check sizes of initial FDE fields.
Yes, this doesn't completely stop the problem since you could place an
insn with a relocated field later in the CIE. If fuzzers find such a
testcase I'll ignore it.
* ehopt.c (struct cie_info): Add "f" field.
(get_cie_info): Return a bool. Verify frag at start of chain
is one with the CIE size found by check_eh_frame.
(check_eh_frame): Save CIE start frag. Only accept 4 or 8
byte fields in state_saw_size, state_saw_cie_offset and
state_saw_pc_begin. Formatting. Localise "fix" variable.
|
|
|
|
Add bceqz and bcnez cases in loongarch_insn_is_cond_branch() and
loongarch_next_pc() to emulate floating-point branch instructions.
Here are the references:
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#_bceqz_bcnez
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#table-table-of-instruction-encoding
Approved-by: Kevin Buettner <kevinb@redhat.com>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
|
|
Update my email address and move up Surya's name as the main PPC contact.
Signed-off-by: Peter Bergner <bergner@tenstorrent.com>
|
|
I noticed that a couple of new comments in cli-style.c mentioned the
wrong command name. This patch fixes the comments.
|
|
I noticed that I had inadvertently put the "set style warning-prefix"
documentation between the paragraph for "set style sources" and the
paragraph for "show style sources". This patch moves the latter up a
bit to clean this up.
|
|
Using explicit pseudo aliases is clearer and more consistent with other
instruction aliases.
This does not change behaviour. For the non-alias instructions
(everything except mov) we already picked the first matching entry for
disassembly by default. For mov we picked the last matching aliased
entry, which remained the original alias since do_misc_decoding doesn't
recognise OP_MOV_PN_PN.
|
|
This was an early name for the clrbhb hint instruction. Some software
was written with the old name before it was renamed, so we support it
for assembly but should never use it in disassembly.
This patch has no functional change, because we already pick (by
default) the last matching alias in the opcode table, and clrbhb is
listed later than clearbhb.
|
|
|
|
|
|
This will only change behaviour during disassembly with -M no-aliases.
|
|
This is more natural than raising the priority of rev with F_P1, and
is functionally equivalent.
|
|
This test file includes all the remaining untested instructions that
weren't part of a larger group of new or existing tests.
|
|
Only movn was previously untested.
|
|
svc and dcps* were already tested, but are included here as part of the
same encoding group.
|
|
The register form of ccmp was already tested.
|
|
beq, bne, bcs and bcc were already tested, and bge and ble are also used
in scfi tests.
|
|
All instructions were previously untested.
|
|
All instructions were previously untested.
|
|
lsl was already tested but is included here as part of the same encoding
group.
|
|
rev16 and the 64-bit rev/rev64 instructions were already tested, but are
included here as part of the same encoding group.
|
|
All instructions were previously untested.
|
|
All instructions were previously untested.
|
|
sqabs, sqneg, abs and neg were already tested, but are included here as
part of the same encoding group.
|
|
All instructions were previously untested.
|
|
All instructions were previously untested.
|
|
Only smov and the second dup variant were previously untested. However,
the only test for umov was a disassembly test with -M no-aliases, and
the first dup variant was only tested in assembly in diagnostic.d with
the non-architectural syntax `dup v0.2d, v1.2d[0]`.
|
|
All instructions were previously untested.
|
|
All instructions (7 opcode table entries) were previously untested.
|
