| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The commit:
commit 08ec06d6440745ef9204d39197aa1e732df41056
Date: Wed Mar 29 10:41:07 2023 +0100
gdb/testsuite: special case '^' in gdb_test pattern
Added some special handling of '^' to gdb_test -- a leading '^' will
cause the command regexp to automatically be included in the expected
output pattern.
It was pointed out that the '-wrap' flag of gdb_test_multiple is
supposed to work in the same way as gdb_test, and that the recent
changes for '^' had not been replicated for gdb_test_multiple. This
patch addresses this issue.
So, after this commit, the following two constructs should have the
same meaning:
gdb_test "command" "^output" "test name"
gdb_test_multiple "command" "test name" {
-re -wrap "^output" {
pass $gdb_test_name
}
}
In both cases the '^' will case gdb.exp to inject a regexp that
matches 'command' after the '^' and before the 'output', this is in
addition to adding the $gdb_prompt pattern after 'output' in the
normal way.
The special '^' handling is only applied when '-wrap' is used, as this
is the only mode that aims to mimic gdb_test.
While working on this patch I realised that I could actually improve
the logic for the special '^' handling in the case where the expected
output pattern is empty. I replicated these updates for both gdb_test
and gdb_test_multiple in order to keep these two paths in sync.
There were a small number of tests that needed adjustment after this
change, mostly just removing command regexps that are now added
automatically, but the gdb.base/settings.exp case was a little weird
as it turns out trying to match a single blank line is probably harder
now than it used to be -- still, I suspect this is a pretty rare case,
so I think the benefits (improved anchoring) outweigh this small
downside (IMHO).
|
|
I spotted this behaviour:
(gdb) p $_gdb_maint_setting("xxx")
First argument of $_gdb_maint_setting must be a valid setting of the 'show' command.
Notice that GDB claims I need to use a setting from the 'show'
command, which isn't correct for $_gdb_maint_setting, in this case I
need to use a setting from 'maintenance show'.
This same issue is present for $_gdb_maint_setting_str.
This commit fixes this minor issue.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
When running test-case gdb.dwarf2/opt-out-not-implptr.exp with target board
unix/-m32 we have:
...
(gdb) print noptr^M
$1 = {0, <optimized out>, <optimized out>, <optimized out>}^M
(gdb) FAIL: gdb.dwarf2/opt-out-not-implptr.exp: print noptr
...
The problem happens when evaluating this dwarf expression:
...
<45> DW_AT_location : 13 byte block: 10 86 ea d7 d0 96 8e cf 92 5c 9f 93 8 \
(DW_OP_constu: 6639779683436459270; DW_OP_stack_value; DW_OP_piece: 8)
...
The DW_OP_constu pushes a value with "generic type" on to the DWARF stack, and
the "generic type" has the size of an address on the target machine, which for
target board unix/-m32 is 4 bytes. Consequently, the constant is abbreviated.
Next, the DW_OP_piece declares that the resulting 4-byte value is 8 bytes
large, and we hit this clause in rw_pieced_value:
...
/* Use zeroes if piece reaches beyond stack value. */
if (p->offset + p->size > stack_value_size_bits)
break;
...
and consequently get a zero.
We could just add require is_target_64 to the test-case, but instead, add a
32-bit case and require is_target_64 just for the 64-bit case.
Tested on x86_64-linux.
|
|
I ran test-case gdb.dwarf2/opt-out-not-implptr.exp with make-check-all.sh, and
with target board dwarf64 ran into:
...
FAIL: gdb.dwarf2/opt-out-not-implptr.exp: print noptr
...
due to is_target_64 failing because of:
...
builtin_spawn -ignore SIGHUP gcc -fno-stack-protector \
-fdiagnostics-color=never -w -c -gdwarf64 -g -o is_64_target.o \
is_64_target.c^M
gcc: error: '-gdwarf64' is ambiguous; use '-gdwarf-64' for DWARF version or \
'-gdwarf -g64' for debug level^M
compiler exited with status 1
...
The FAIL is the same FAIL I run into with target board unix/-m32: is_target_64
fails for both cases.
The reason that is_target_64 is failing for target board dwarf64, is because
of using system compiler 7.5.0 which doesn't support -gdwarf64.
Fix this by making is_target_64 use nodebug instead of debug for compilation.
Tested on x86_64-linux.
|
|
I. Auto-detected width (xterm vs. ansi)
Say we have a terminal with a width of 40 chars:
...
$ echo $COLUMNS
40
...
With TERM=xterm, we report a width of 40 chars:
...
$ TERM=xterm gdb
(gdb) show width
Number of characters gdb thinks are in a line is 40.
...
And with TERM=ansi, a width of 39 chars:
...
$ TERM=ansi gdb
(gdb) show width
Number of characters gdb thinks are in a line is 39.
...
Gdb uses readline to auto-detect screen size, and readline decides in the
TERM=ansi case that the terminal does not have reliable auto-wrap, and
consequently decides to hide the last terminal column from the readline user
(in other words GDB), hence we get 39 instead of 40.
II. Types of wrapping
Looking a bit more in detail inside gdb, it seems there are two types of
wrapping:
- readline wrapping (in other words, prompt edit wrapping), and
- gdb output wrapping (can be observed by issuing "info sources").
This type of wrapping attempts to wrap some of the gdb output earlier
than the indicated width, to not break lines in inconvenient places.
III. Readline wrapping, auto-detected screen size
Let's investigate readline wrapping with the auto-detected screen widths.
First, let's try with xterm:
...
$ TERM=xterm gdb
(gdb) 7890123456789012345678901234567890
123
...
That looks as expected, wrapping occurs after 40 chars.
Now, let's try with ansi:
...
$ TERM=ansi gdb
(gdb) 78901234567890123456789012345678
90123
...
It looks like wrapping occurred after 38, while readline should be capable of
wrapping after 39 chars.
This is caused by readline hiding the last column, twice.
In more detail:
- readline detects the screen width: 40,
- readline hides the last column, setting the readline screen width to 39,
- readline reports 39 to gdb as screen width,
- gdb sets its width setting to 39,
- gdb sets readline screen width to 39,
- readline hides the last column, again, setting the readline screen width to
38.
This is reported as PR cli/30346.
IV. gdb output wrapping, auto-detected screen size
Say we set the terminal width to 56. With TERM=xterm, we have:
...
/home/abuild/rpmbuild/BUILD/glibc-2.31/csu/elf-init.c,
/data/vries/hello.c,
...
but with TERM=ansi:
...
/home/abuild/rpmbuild/BUILD/glibc-2.31/csu/elf-init.c, /
data/vries/hello.c,
...
So what happened here? With TERM=ansi, the width setting is auto-detected to
55, and gdb assumes the terminal inserts a line break there, which it doesn't
because the terminal width is 56.
This is reported as PR cli/30411.
V. Fix PRs
Fix both mentioned PRs by taking into account the hidden column when readline
reports the screen width in init_page_info, and updating chars_per_line
accordingly.
Note that now we report the same width for both TERM=xterm and TERM=ansi,
which is much clearer.
The point where readline respectively expects or ensures wrapping is still
indicated by "maint info screen", for xterm:
...
Number of characters readline reports are in a line is 40.
...
and ansi:
...
Number of characters readline reports are in a line is 39.
...
VI. Testing
PR cli/30346 is covered by existing regression tests gdb.base/wrap-line.exp
and gdb.tui/wrap-line.exp, so remove the KFAILs there.
I didn't manage to come up with a regression test for PR cli/30411. Perhaps
that would be easier if we had a maintenance command that echoes its arguments
while applying gdb output wrapping.
Tested on x86_64-linux.
PR cli/30346
PR cli/30411
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30346
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30411
|
|
... such that they wouldn't need forward declarations anymore. Note that
append_seg() already was suitably placed.
|
|
... such that none of them would need forward declarations anymore.
|
|
With the switch to parse_real_register() (commit 4faaa10f3fab) "bad_reg"
cannot come back anymore. Drop the respective check.
|
|
There are two problems: symbol_equated_p() doesn't recognize equates of
registers, and S_CAN_BE_REDEFINED() goes by section rather than by
expression type. Both together undermine .eqv and .equiv clearly meaning
to guard the involved symbols against re-definition (both ways).
To compensate pseudo_set() now using O_symbol and S_CAN_BE_REDEFINED()
now checking for O_register,
- for targets creating register symbols through symbol_{new,create}() ->
symbol_init() -> S_SET_VALUE() (alpha, arc, dlx, ia64, m68k, mips,
mmix, tic4x, tic54x, plus anything using cgen or itbl-ops), have
symbol_init() set their expressions to O_register,
- x86'es parse_register() also can't go by section anymore when
trying to "look through" equates; probably symbol_equated_p() should
have been used there from the beginning, if only that had worked for
equates of registers,
- various targets need to "look through" equates when parsing insn
operands (which also helps transitive forward equates); perhaps even
more ought to, but many don't look to consider the possibility of
register equates in the first place.
This was uncovered by code reported in PR gas/30274 (duplicating
PR gas/30272), except that there .eqv was used when really .equ was
meant. Therefore that bug report is addressed here only in so far as
gas wouldn't crash anymore; the code there still won't assemble
successfully, just that now the issues there are properly diagnosed.
|
|
|
|
A user reported a bug where printing a certain array of integer types
would result in the nonsensical:
(gdb) p l_126
$1 = {6639779683436459270, <synthetic pointer>, <synthetic pointer>, <synthetic pointer>}
I tracked this down to some issues in the DWARF expression code.
First, check_pieced_synthetic_pointer did not account for the
situation where a location expression does not describe all the bits
of a value -- in this case it returned true, meaning there is a
synthetic pointer, but in fact these bits are optimized out. (It
turns out this incorrect output had already been erroneously tested
for as well.)
Next, rw_pieced_value did not mark these bits as optimized-out,
either.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30296
|
|
gdb's debuginfod progress messages include the size of the file being
downloaded if the size information is available at the time the message
is printed. For example:
Downloading 10 MB separate debug info for /lib64/libxyz.so
This size information is omitted if it's not available at the time of
printing:
Downloading separate debug info for /lib64/libxyz.so
A pattern in crc_mismatch.exp fails to be matched if a progress message
includes a file size. Add a wildcard to the pattern so that it matches
the progress message whether or not it includes the file size.
|
|
Currently, when a local software watchpoint goes out of scope, GDB sets
the watchpoint's disposition to `delete at next stop' and then normal
stops (i.e., stop and wait for the next GDB command). When GDB normal
stops, it automatically deletes the breakpoints with their disposition
set to `delete at next stop'.
Suppose a Python script decides not to normal stop when a local
software watchpoint goes out of scope, the watchpoint will not be
automatically deleted even when its disposition is set to
`delete at next stop'.
Since GDB single-steps the program and tests the watched expression
after each instruction, not deleting the watchpoint causes the
watchpoint to be hit many more times than it should, as reported in
PR python/29603.
This was happening because the watchpoint is not deleted or disabled
when going out of scope.
This commit fixes this issue by disabling the watchpoint when going out
of scope. It also adds a test to ensure this feature isn't regressed in
the future.
Calling `breakpoint_auto_delete' on all kinds of stops (in
`fetch_inferior_event') seem to solve this issue, but is in fact
inappropriate, since `breakpoint_auto_delete' goes over all breakpoints
instead of just going through the bpstat chain (which only contains the
breakpoints that were hit right now).
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29603
Change-Id: Ia85e670b2bcba2799219abe4b6be3b582387e383
|
|
I noticed that "scheduler-locking" does not appear in the index of the
gdb manual. This patch corrects this oversight.
|
|
This is one part of the fix for GCC PR109128, along with a
corresponding GCC change. Without this patch, what happens in the
linker, when an unused object in a .a file has offload data, is that
elf_link_is_defined_archive_symbol calls bfd_link_plugin_object_p,
which ends up calling the plugin's claim_file_handler, which then
records the object as one with offload data. That is, the linker never
decides to use the object in the first place, but use of this _p
interface (called as part of trying to decide whether to use the
object) results in the plugin deciding to use its offload data (and a
consequent mismatch in the offload data present at runtime).
The new hook allows the linker plugin to distinguish calls to
claim_file_handler that know the object is being used by the linker
(from ldmain.c:add_archive_element), from calls that don't know it's
being used by the linker (from elf_link_is_defined_archive_symbol); in
the latter case, the plugin should avoid recording the object as one
with offload data.
bfd/
* plugin.c (struct plugin_list_entry): Add claim_file_v2.
(register_claim_file_v2): New.
(try_load_plugin): Use LDPT_REGISTER_CLAIM_FILE_HOOK_V2.
(ld_plugin_object_p): Take second argument.
(bfd_link_plugin_object_p): Update call to ld_plugin_object_p.
(register_ld_plugin_object_p): Update argument prototype.
(bfd_plugin_object_p): Update call to ld_plugin_object_p.
* plugin.h (register_ld_plugin_object_p): Update argument
prototype.
include/
* plugin.api.h (ld_plugin_claim_file_handler_v2)
(ld_plugin_register_claim_file_v2)
(LDPT_REGISTER_CLAIM_FILE_HOOK_V2): New.
(struct ld_plugin_tv): Add tv_register_claim_file_v2.
ld/
* plugin.c (struct plugin): Add claim_file_handler_v2.
(LDPT_REGISTER_CLAIM_FILE_HOOK_V2): New.
(plugin_object_p): Add second argument. Update call to
plugin_call_claim_file.
(register_claim_file_v2): New.
(set_tv_header): Handle LDPT_REGISTER_CLAIM_FILE_HOOK_V2.
(plugin_call_claim_file): Add argument known_used.
(plugin_maybe_claim): Update call to plugin_object_p.
* testplug.c, testplug2.c, testplug3.c, testplug4.c: Handle
LDPT_REGISTER_CLAIM_FILE_HOOK_V2.
* testsuite/ld-plugin/plugin-1.d, testsuite/ld-plugin/plugin-10.d,
testsuite/ld-plugin/plugin-11.d, testsuite/ld-plugin/plugin-13.d,
testsuite/ld-plugin/plugin-14.d, testsuite/ld-plugin/plugin-15.d,
testsuite/ld-plugin/plugin-16.d, testsuite/ld-plugin/plugin-17.d,
testsuite/ld-plugin/plugin-18.d, testsuite/ld-plugin/plugin-19.d,
testsuite/ld-plugin/plugin-2.d, testsuite/ld-plugin/plugin-26.d,
testsuite/ld-plugin/plugin-3.d, testsuite/ld-plugin/plugin-30.d,
testsuite/ld-plugin/plugin-4.d, testsuite/ld-plugin/plugin-5.d,
testsuite/ld-plugin/plugin-6.d, testsuite/ld-plugin/plugin-7.d,
testsuite/ld-plugin/plugin-8.d, testsuite/ld-plugin/plugin-9.d:
Update test expectations.
|
|
|
|
Andrew pointed out that the behaviour as tested in gdb.tui/compact-source.exp
is incorrect:
...
0 +-compact-source.c--------------------------------------------------------+
1 |___3_{ |
2 |___4_ return 0; |
3 |___5_} |
4 |___6_ |
5 |___7_ |
6 |___8_ |
7 |___9_ |
8 +-------------------------------------------------------------------------+
...
The last line number in the source file is 5, and there are 7 lines to display
source lines, so if we'd scroll all the way down, the first line number in the
source window would be 5, and the last one would be 11.
To represent 11 we'd need 2 digits, so we expect to see ___04_ here instead of
___4_, even though all line numbers currently in the src window (3-9) can be
represented with only 1 digit.
Fix this in tui_source_window::set_contents, by updating the computation of
max_line_nr:
...
- int max_line_nr = std::max (lines_in_file, last_line_nr_in_window);
+ int max_line_nr = lines_in_file + nlines - 1;
...
Tested on x86_64-linux.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
While working on another patch I did this:
(gdb) set debug expression 1
(gdb) set language rust
(gdb) p "foo"
Operation: OP_AGGREGATE
Type: &str
Fatal signal: Segmentation fault
... etc ...
The problem is that the second field of the rust_aggregate_operation
is created as a nullptr, this can be seen in rust-parse.c. in the
function rust_parser::parse_string().
However, in expop.h, in the function dump_for_expression, we make the
assumption that the expressions will never be nullptr.
I did consider moving the nullptr handling into a new function
rust_aggregate_operation::dump, however, as the expression debug
dumping code is not exercised as much as it might be, I would rather
that this code be hardened and able to handle a nullptr without
crashing, so I propose that we add nullptr handling into the general
dump_for_expression function. The behaviour is now:
(gdb) set debug expression 1
(gdb) set language rust
(gdb) p "foo"
Operation: OP_AGGREGATE
Type: &str
nullptr
Vector:
String: data_ptr
Operation: UNOP_ADDR
Operation: OP_STRING
String: foo
String: length
Operation: OP_LONG
Type: usize
Constant: 3
evaluation of this expression requires the target program to be active
(gdb)
There's a new test to check for this case.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
Apparently u.kindirect->slot can point at a NULL.
* debug.c (debug_write_type): Don't segfault on NULL indirect.
|
|
PR 30422
* elf32-or1k.c (or1k_elf_relocate_section): Prescan for R_OR1K_GOT_AHI16 relocs as they may occur after R_OR1K_GOT16 relocs.
|
|
PR 16566
* ldlang.c (ld_is_local_symbol): New function. (print_input_section): Add code to display local symbols in the section.
* ldlex.h (enum option_values): Add OPTION_PRINT_MAP_LOCALS and OPTION_PRINT_MAP_LOCALS.
* lexsup.c (ld_options[]): Add entries for --print-map-locals and --no-print-map-locals.
* NEWS: Mention the new feature.
* ld.h (struct ld_config_type): Add print_map_locals field.
* ld.texi: Document the new command line option.
* testsuite/ld-scripts/sizeof.s: Add a local symbol.
* testsuite/ld-scripts/map-locals.d: New test control file.
* testsuite/ld-scripts/map-address.exp: Run the new test.
|
|
Consider a hello.c, with less than 10 lines:
...
$ wc -l hello.c
8 hello.c
...
and compiled with -g into an a.out.
With compact-source off:
...
$ gdb -q a.out \
-ex "set tui border-kind ascii" \
-ex "maint set tui-left-margin-verbose on" \
-ex "set tui compact-source off" \
-ex "tui enable"
...
we get:
...
+-./data/hello.c-----------------------+
|___000005_{ |
|___000006_ printf ("hello\n"); |
|___000007_ return 0; |
|___000008_} |
|___000009_ |
|___000010_ |
|___000011_ |
...
but with compact-source on:
...
+-./data/hello.c-----------------------+
|___5{ |
|___6 printf ("hello\n"); |
|___7 return 0; |
|___8} |
|___9 |
|___1 |
|___1 |
...
There are a couple of problems with compact-source.
First of all the documentation mentions:
...
The default display uses more space for line numbers and starts the
source text at the next tab stop; the compact display uses only as
much space as is needed for the line numbers in the current file, and
only a single space to separate the line numbers from the source.
...
The bit about the default display and the next tab stop looks incorrect. The
source doesn't start at a tab stop, instead it uses a single space to separate
the line numbers from the source.
Then the documentation mentions that there's single space in the compact
display, but evidently that's missing.
Then there's the fact that the line numbers "10" and "11" are both abbreviated
to "1" in the compact case.
The abbreviation is due to allocating space for <lines in source>, which is
8 for this example, and takes a single digit. The line numbers though
continue past the end of the file, so fix this by allocating space for
max (<lines in source>, <last line in window>), which in this example takes 2
digits.
The missing space is due to some confusion about what the "1" here in
tui_source_window::set_contents represent:
...
double l = log10 ((double) offsets->size ());
m_digits = 1 + (int) l;
...
It could be the trailing space that's mentioned in tui-source.h:
...
/* How many digits to use when formatting the line number. This
includes the trailing space. */
int m_digits;
...
Then again, it could be part of the calculation for the number of digits
needed for printing. With this minimal example:
...
int main () {
for (int i = 8; i <= 11; ++i) {
double l = log10 ((double) i);
printf ("%d %d\n", i, (int)l);
}
return 0;
}
...
we get:
...
$ ./a.out
8 0
9 0
10 1
11 1
...
which shows that the number of digits needed for printing i is
"1 + (int)log10 ((double) i)".
Fix this by introducing named variables needed_digits and trailing_space, each
adding 1.
With the fixes, we get for compact-source on:
...
+-./data/hello.c-----------------------+
|___05_{ |
|___06_ printf ("hello\n"); |
|___07_ return 0; |
|___08_} |
|___09_ |
|___10_ |
|___11_ |
|...
Also fix the documentation and help text to actually match effect of
compact-source.
Tested on x86_64-linux.
|
|
|
|
On Linux at least, baud rate codes are defined up to B4000000. Allow the
user to select them if they are present in the system headers.
Change-Id: I393ff32e4a4b6127bdf97e3306ad5b6ebf7c934e
|
|
Commit 7a8de0c33019 ("Remove ALL_BREAKPOINTS_SAFE") introduced a
use-after-free in the breakpoints iterations (see below for full ASan
report). This makes gdb.base/stale-infcall.exp fail when GDB is build
with ASan.
check_longjmp_breakpoint_for_call_dummy iterates on all breakpoints,
possibly deleting the current breakpoint as well as related breakpoints.
The problem arises when a breakpoint in the B->related_breakpoint chain
is also B->next. In that case, deleting that related breakpoint frees
the breakpoint that all_breakpoints_safe has saved.
The old code worked around that by manually changing B_TMP, which was
the next breakpoint saved by the "safe iterator":
while (b->related_breakpoint != b)
{
if (b_tmp == b->related_breakpoint)
b_tmp = b->related_breakpoint->next;
delete_breakpoint (b->related_breakpoint);
}
(Note that this seemed to assume that b->related_breakpoint->next was
the same as b->next->next, not sure this is guaranteed.)
The new code kept the B_TMP variable, but it's not useful in that
context. We can't go change the next breakpoint as saved by the safe
iterator, like we did before. I suggest fixing that by saving the
breakpoints to delete in a map and deleting them all at the end.
Here's the full ASan report:
(gdb) PASS: gdb.base/stale-infcall.exp: continue to breakpoint: break-run1
print infcall ()
=================================================================
==47472==ERROR: AddressSanitizer: heap-use-after-free on address 0x611000034980 at pc 0x563f7012c7bc bp 0x7ffdf3804d70 sp 0x7ffdf3804d60
READ of size 8 at 0x611000034980 thread T0
#0 0x563f7012c7bb in next_iterator<breakpoint>::operator++() /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/next-iterator.h:66
#1 0x563f702ce8c0 in basic_safe_iterator<next_iterator<breakpoint> >::operator++() /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/safe-iterator.h:84
#2 0x563f7021522a in check_longjmp_breakpoint_for_call_dummy(thread_info*) /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:7611
#3 0x563f714567b1 in process_event_stop_test /home/smarchi/src/binutils-gdb/gdb/infrun.c:6881
#4 0x563f71454e07 in handle_signal_stop /home/smarchi/src/binutils-gdb/gdb/infrun.c:6769
#5 0x563f7144b680 in handle_inferior_event /home/smarchi/src/binutils-gdb/gdb/infrun.c:6023
#6 0x563f71436165 in fetch_inferior_event() /home/smarchi/src/binutils-gdb/gdb/infrun.c:4387
#7 0x563f7136ff51 in inferior_event_handler(inferior_event_type) /home/smarchi/src/binutils-gdb/gdb/inf-loop.c:42
#8 0x563f7168038d in handle_target_event /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:4219
#9 0x563f72fccb6d in handle_file_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573
#10 0x563f72fcd503 in gdb_wait_for_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694
#11 0x563f72fcaf2b in gdb_do_one_event(int) /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:217
#12 0x563f7262b9bb in wait_sync_command_done() /home/smarchi/src/binutils-gdb/gdb/top.c:426
#13 0x563f7137a7c3 in run_inferior_call /home/smarchi/src/binutils-gdb/gdb/infcall.c:650
#14 0x563f71381295 in call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) /home/smarchi/src/binutils-gdb/gdb/infcall.c:1332
#15 0x563f7137c0e2 in call_function_by_hand(value*, type*, gdb::array_view<value*>) /home/smarchi/src/binutils-gdb/gdb/infcall.c:780
#16 0x563f70fe5960 in evaluate_subexp_do_call(expression*, noside, value*, gdb::array_view<value*>, char const*, type*) /home/smarchi/src/binutils-gdb/gdb/eval.c:649
#17 0x563f70fe6617 in expr::operation::evaluate_funcall(type*, expression*, noside, char const*, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:677
#18 0x563f6fd19668 in expr::operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/expression.h:136
#19 0x563f70fe6bba in expr::var_value_operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:689
#20 0x563f704b71dc in expr::funcall_operation::evaluate(type*, expression*, noside) /home/smarchi/src/binutils-gdb/gdb/expop.h:2219
#21 0x563f70fe0f02 in expression::evaluate(type*, noside) /home/smarchi/src/binutils-gdb/gdb/eval.c:110
#22 0x563f71b1373e in process_print_command_args /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1319
#23 0x563f71b1391b in print_command_1 /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1332
#24 0x563f71b147ec in print_command /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1465
#25 0x563f706029b8 in do_simple_func /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:95
#26 0x563f7061972a in cmd_func(cmd_list_element*, char const*, int) /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:2735
#27 0x563f7262d0ef in execute_command(char const*, int) /home/smarchi/src/binutils-gdb/gdb/top.c:572
#28 0x563f7100ed9c in command_handler(char const*) /home/smarchi/src/binutils-gdb/gdb/event-top.c:543
#29 0x563f7101014b in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/smarchi/src/binutils-gdb/gdb/event-top.c:779
#30 0x563f72777942 in tui_command_line_handler /home/smarchi/src/binutils-gdb/gdb/tui/tui-interp.c:104
#31 0x563f7100d059 in gdb_rl_callback_handler /home/smarchi/src/binutils-gdb/gdb/event-top.c:250
#32 0x7f5a80418246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb)
#33 0x563f7100ca06 in gdb_rl_callback_read_char_wrapper_noexcept /home/smarchi/src/binutils-gdb/gdb/event-top.c:192
#34 0x563f7100cc5e in gdb_rl_callback_read_char_wrapper /home/smarchi/src/binutils-gdb/gdb/event-top.c:225
#35 0x563f728c70db in stdin_event_handler /home/smarchi/src/binutils-gdb/gdb/ui.c:155
#36 0x563f72fccb6d in handle_file_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573
#37 0x563f72fcd503 in gdb_wait_for_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694
#38 0x563f72fcb15c in gdb_do_one_event(int) /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:264
#39 0x563f7177ec1c in start_event_loop /home/smarchi/src/binutils-gdb/gdb/main.c:412
#40 0x563f7177f12e in captured_command_loop /home/smarchi/src/binutils-gdb/gdb/main.c:476
#41 0x563f717846e4 in captured_main /home/smarchi/src/binutils-gdb/gdb/main.c:1320
#42 0x563f71784821 in gdb_main(captured_main_args*) /home/smarchi/src/binutils-gdb/gdb/main.c:1339
#43 0x563f6fcedfbd in main /home/smarchi/src/binutils-gdb/gdb/gdb.c:32
#44 0x7f5a7e43984f (/usr/lib/libc.so.6+0x2384f) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e)
#45 0x7f5a7e439909 in __libc_start_main (/usr/lib/libc.so.6+0x23909) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e)
#46 0x563f6fcedd84 in _start (/home/smarchi/build/binutils-gdb/gdb/gdb+0xafb0d84) (BuildId: 50bd32e6e9d5e84543e9897b8faca34858ca3995)
0x611000034980 is located 0 bytes inside of 208-byte region [0x611000034980,0x611000034a50)
freed by thread T0 here:
#0 0x7f5a7fce312a in operator delete(void*, unsigned long) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:164
#1 0x563f702bd1fa in momentary_breakpoint::~momentary_breakpoint() /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:304
#2 0x563f702771c5 in delete_breakpoint(breakpoint*) /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:12404
#3 0x563f702150a7 in check_longjmp_breakpoint_for_call_dummy(thread_info*) /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:7673
#4 0x563f714567b1 in process_event_stop_test /home/smarchi/src/binutils-gdb/gdb/infrun.c:6881
#5 0x563f71454e07 in handle_signal_stop /home/smarchi/src/binutils-gdb/gdb/infrun.c:6769
#6 0x563f7144b680 in handle_inferior_event /home/smarchi/src/binutils-gdb/gdb/infrun.c:6023
#7 0x563f71436165 in fetch_inferior_event() /home/smarchi/src/binutils-gdb/gdb/infrun.c:4387
#8 0x563f7136ff51 in inferior_event_handler(inferior_event_type) /home/smarchi/src/binutils-gdb/gdb/inf-loop.c:42
#9 0x563f7168038d in handle_target_event /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:4219
#10 0x563f72fccb6d in handle_file_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573
#11 0x563f72fcd503 in gdb_wait_for_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694
#12 0x563f72fcaf2b in gdb_do_one_event(int) /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:217
#13 0x563f7262b9bb in wait_sync_command_done() /home/smarchi/src/binutils-gdb/gdb/top.c:426
#14 0x563f7137a7c3 in run_inferior_call /home/smarchi/src/binutils-gdb/gdb/infcall.c:650
#15 0x563f71381295 in call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) /home/smarchi/src/binutils-gdb/gdb/infcall.c:1332
#16 0x563f7137c0e2 in call_function_by_hand(value*, type*, gdb::array_view<value*>) /home/smarchi/src/binutils-gdb/gdb/infcall.c:780
#17 0x563f70fe5960 in evaluate_subexp_do_call(expression*, noside, value*, gdb::array_view<value*>, char const*, type*) /home/smarchi/src/binutils-gdb/gdb/eval.c:649
#18 0x563f70fe6617 in expr::operation::evaluate_funcall(type*, expression*, noside, char const*, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:677
#19 0x563f6fd19668 in expr::operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/expression.h:136
#20 0x563f70fe6bba in expr::var_value_operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:689
#21 0x563f704b71dc in expr::funcall_operation::evaluate(type*, expression*, noside) /home/smarchi/src/binutils-gdb/gdb/expop.h:2219
#22 0x563f70fe0f02 in expression::evaluate(type*, noside) /home/smarchi/src/binutils-gdb/gdb/eval.c:110
#23 0x563f71b1373e in process_print_command_args /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1319
#24 0x563f71b1391b in print_command_1 /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1332
#25 0x563f71b147ec in print_command /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1465
#26 0x563f706029b8 in do_simple_func /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:95
#27 0x563f7061972a in cmd_func(cmd_list_element*, char const*, int) /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:2735
#28 0x563f7262d0ef in execute_command(char const*, int) /home/smarchi/src/binutils-gdb/gdb/top.c:572
#29 0x563f7100ed9c in command_handler(char const*) /home/smarchi/src/binutils-gdb/gdb/event-top.c:543
previously allocated by thread T0 here:
#0 0x7f5a7fce2012 in operator new(unsigned long) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:95
#1 0x563f7029a9a3 in new_momentary_breakpoint<program_space*&, frame_id&, int&> /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:8129
#2 0x563f702212f6 in momentary_breakpoint_from_master /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:8169
#3 0x563f70212db1 in set_longjmp_breakpoint_for_call_dummy() /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:7582
#4 0x563f713804db in call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) /home/smarchi/src/binutils-gdb/gdb/infcall.c:1260
#5 0x563f7137c0e2 in call_function_by_hand(value*, type*, gdb::array_view<value*>) /home/smarchi/src/binutils-gdb/gdb/infcall.c:780
#6 0x563f70fe5960 in evaluate_subexp_do_call(expression*, noside, value*, gdb::array_view<value*>, char const*, type*) /home/smarchi/src/binutils-gdb/gdb/eval.c:649
#7 0x563f70fe6617 in expr::operation::evaluate_funcall(type*, expression*, noside, char const*, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:677
#8 0x563f6fd19668 in expr::operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/expression.h:136
#9 0x563f70fe6bba in expr::var_value_operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:689
#10 0x563f704b71dc in expr::funcall_operation::evaluate(type*, expression*, noside) /home/smarchi/src/binutils-gdb/gdb/expop.h:2219
#11 0x563f70fe0f02 in expression::evaluate(type*, noside) /home/smarchi/src/binutils-gdb/gdb/eval.c:110
#12 0x563f71b1373e in process_print_command_args /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1319
#13 0x563f71b1391b in print_command_1 /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1332
#14 0x563f71b147ec in print_command /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1465
#15 0x563f706029b8 in do_simple_func /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:95
#16 0x563f7061972a in cmd_func(cmd_list_element*, char const*, int) /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:2735
#17 0x563f7262d0ef in execute_command(char const*, int) /home/smarchi/src/binutils-gdb/gdb/top.c:572
#18 0x563f7100ed9c in command_handler(char const*) /home/smarchi/src/binutils-gdb/gdb/event-top.c:543
#19 0x563f7101014b in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/smarchi/src/binutils-gdb/gdb/event-top.c:779
#20 0x563f72777942 in tui_command_line_handler /home/smarchi/src/binutils-gdb/gdb/tui/tui-interp.c:104
#21 0x563f7100d059 in gdb_rl_callback_handler /home/smarchi/src/binutils-gdb/gdb/event-top.c:250
#22 0x7f5a80418246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb)
Change-Id: Id00c17ab677f847fbf4efdf0f4038373668d3d88
Approved-By: Tom Tromey <tom@tromey.com>
|
|
|
|
Another fuzzer attack. This one was a "set" with elements using an
indirect type pointing back at the set. The existing recursion check
only prevented simple recursion.
* debug.c (struct debug_type_s): Add mark.
(debug_write_type): Set mark and check before recursing into
indirect types.
|
|
Stops fuzzed files triggering reads past the end of the reloc buffer.
* vms-alpha.c (alpha_vms_slurp_relocs): Sanity check reloc records.
|
|
|
|
|
|
This was previously clearing the upper 32 bytes of ZMM0-15 rather than
ZMM16-31.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
These two methods are both overrides of public methods in base
classes.
|
|
When stopped inside an inline function, trying to jump to a different line
of the same function currently results in a warning about jumping to another
function. Fix this by taking inline functions into account.
Before:
Breakpoint 1, function_inline (x=510) at jump-inline.cpp:22
22 a = a + x; /* inline-funct */
(gdb) j 21
Line 21 is not in `function_inline(int)'. Jump anyway? (y or n)
After:
Breakpoint 2, function_inline (x=510) at jump-inline.cpp:22
22 a = a + x; /* inline-funct */
(gdb) j 21
Continuing at 0x400679.
Breakpoint 1, function_inline (x=510) at jump-inline.cpp:21
21 a += 1020 + a; /* increment-funct */
This was regression-tested on X86-64 Linux.
Co-Authored-by: Cristian Sandu <cristian.sandu@intel.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
This is a little cleanup that I made when looking at pr30343 that
makes it more obvious that make_import_fixup in both files are
identical (and in fact the new pep.em read_addend could be used in
both files).
* emultempl/pep.em (read_addend): Extract from..
(make_import_fixup): ..here.
* emultempl/pe.em (read_addend): Similarly.
(make_import_fixup): Similarly. Add debug code from pep.em.
|
|
Make a reference to _pei386_runtime_relocator before LTO recompilation.
This is done regardless of whether such a reference will be used,
because it can't be known whether it is needed before LTO.
I also found it necessary to enable long section names for the bfd
created in make_runtime_pseudo_reloc, because otherwise when writing
it out to the bfd-in-memory we get the section written as .rdata_r
which when read back in leads to a linker warning ".rdata_r: section
below image base" and likely runtime misbehaviour.
PR 30343
* emultempl/pe.em (make_runtime_ref): New function.
(gld${EMULATION_NAME}_before_plugin_all_symbols_read): New function.
(LDEMUL_BEFORE_PLUGIN_ALL_SYMBOLS_READ): Define.
* emultempl/pep.em: Similarly to pe.em.
* pe-dll.c (make_runtime_pseudo_reloc): Set long section names.
|
|
|
|
I noticed that select_source_symtab is only ever called with nullptr
as an argument, so this patch removes the parameter and associated
logic.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
There's just a single remaining use of the ALL_BREAKPOINTS_SAFE macro;
this patch replaces it with a for-each and an explicit temporary
variable.
|
|
This replaces ALL_DICT_SYMBOLS with an iterator so that for-each can
be used.
|
|
This replaces ALL_OBJFILE_OSECTIONS with an iterator so that for-each
can be used.
|
|
I think objfile::sections makes sense as the name of the method to
iterate over an objfile's sections, so this patch renames the existing
field to objfile::sections_start in preparation for that.
|
|
|
|
Python pretty-printers haven't applied to static members for quite
some time. I tracked this down to the call to cp_print_value_fields
in cp_print_static_field -- it doesn't let pretty-printers have a
chance to print the value. This patch fixes the problem.
The way that static members are handled is very weird to me. I tend
to think this should be done more globally, like in value_print.
However, I haven't made any big change.
Reviewed-by: Keith Seitz <keiths@redhat.com>
Tested-by: Keith Seitz <keiths@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30057
|
|
It is added since 2016 by
Add support for .MIPS.abiflags and .gnu.attributes sections
b52717c0e104eb603e8189c3c0d3658ef5d903f5
But never documented.
|
|
|
|
The DAP scopes request examines the symbols in a block tree, but
neglects to omit types. This patch fixes the problem.
|
|
I found a couple of spots in ada-valprint.c that use an explicit loop,
but where discrete_position could be used instead.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
Currently, when we add a new python sub-system to GDB,
e.g. py-inferior.c, we end up having to create a new function like
gdbpy_initialize_inferior, which then has to be called from the
function do_start_initialization in python.c.
In some cases (py-micmd.c and py-tui.c), we have two functions
gdbpy_initialize_*, and gdbpy_finalize_*, with the second being called
from finalize_python which is also in python.c.
This commit proposes a mechanism to manage these initialization and
finalization calls, this means that adding a new Python subsystem will
no longer require changes to python.c or python-internal.h, instead,
the initialization and finalization functions will be registered
directly from the sub-system file, e.g. py-inferior.c, or py-micmd.c.
The initialization and finalization functions are managed through a
new class gdbpy_initialize_file in python-internal.h. This class
contains a single global vector of all the initialization and
finalization functions.
In each Python sub-system we create a new gdbpy_initialize_file
object, the object constructor takes care of registering the two
callback functions.
Now from python.c we can call static functions on the
gdbpy_initialize_file class which take care of walking the callback
list and invoking each callback in turn.
To slightly simplify the Python sub-system files I added a new macro
GDBPY_INITIALIZE_FILE, which hides the need to create an object. We
can now just do this:
GDBPY_INITIALIZE_FILE (gdbpy_initialize_registers);
One possible problem with this change is that there is now no
guaranteed ordering of how the various sub-systems are initialized (or
finalized). To try and avoid dependencies creeping in I have added a
use of the environment variable GDB_REVERSE_INIT_FUNCTIONS, this is
the same environment variable used in the generated init.c file.
Just like with init.c, when this environment variable is set we
reverse the list of Python initialization (and finalization)
functions. As there is already a test that starts GDB with the
environment variable set then this should offer some level of
protection against dependencies creeping in - though for full
protection I guess we'd need to run all gdb.python/*.exp tests with
the variable set.
I have tested this patch with the environment variable set, and saw no
regressions, so I think we are fine right now.
One other change of note was for gdbpy_initialize_gdb_readline, this
function previously returned void. In order to make this function
have the correct signature I've updated its return type to int, and we
now return 0 to indicate success.
All of the other initialize (and finalize) functions have been made
static within their respective sub-system files.
There should be no user visible changes after this commit.
|
|
After this commit:
commit e2f620135d92f7cd670af4e524fffec7ac307666
Date: Thu Mar 30 13:26:25 2023 +0100
gdb/testsuite: change newline patterns used in gdb_test
It was pointed out in PR gdb/30403 that the same patterns can be found
in other lib/gdb.exp procs and that it would probably be a good idea
if these procs remained in sync with gdb_test. Actually, the bug
specifically calls out gdb_test_multiple when using with '-wrap', but
I found a couple of other locations in gdb_continue_to_breakpoint,
gdb_test_multiline, get_valueof, and get_local_valueof.
In all these locations one or both of the following issues are
addressed:
1. A leading pattern of '[\r\n]*' is pointless. If there is a
newline it will be matched, but if there is not then the testsuite
doesn't care. Also, as expect is happy to skip non-matched output
at the start of a pattern, if there is a newline expect is happy to
skip over it before matching the rest. As such, this leading
pattern is removed.
2. Using '\[\r\n\]*$gdb_prompt' means that we will swallow
unexpected blank lines at the end of a command's output, but also,
if the pattern from the test script ends with a '\r', '\n', or '.'
then these will partially match the trailing newline, with the
remainder of the newline matched by the pattern from gdb.exp. This
split matching doesn't add any value, it's just something that has
appeared as a consequence of how gdb.exp was originally written. In
this case the '\[\r\n\]*' is replaced with '\r\n'.
I've rerun the testsuite and fixed the regressions that I saw, these
were places where GDB emits a blank line at the end of the command
output, which we now need to explicitly match in the test script, this
was for:
gdb.dwarf2/dw2-out-of-range-end-of-seq.exp
gdb.guile/guile.exp
gdb.python/python.exp
Or a location where the test script was matching part of the newline
sequence, while gdb.exp was previously matching the remainder of the
newline sequence. Now we rely on gdb.exp to match the complete
newline sequence, this was for:
gdb.base/commands.exp
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30403
|
|
I noticed in gdb.base/page.exp:
...
set fours [string repeat 4 40]
...
but then shortly afterwards:
...
[list 1\r\n 2\r\n 3\r\n 444444444444444444444444444444]
...
Summarize the long string in the same way using string repeat:
...
[list 1\r\n 2\r\n 3\r\n [string repeat 4 30]]
...
Tested on x86_64-linux.
|
