| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Use const pointers for function arguments and local vars where
applicable. 'cfi_insn' contains the DWARF CFI instruction data which,
for the purpose of SFrame generation, is read-only. Similarly, some
getter APIs and output related APIs now document their argument as
read-only.
While at it, also remove the ATTRIBUTE_UNUSED from argument xlate_ctx in
sframe_xlate_do_register () because the argument is indeed conditionally
used.
|
|
|
|
Add test-case gdb.tui/tui-mode-switch.exp, a regression test for
PR tui/30523.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30523
|
|
Add Term::with_term that allows us to override the default TERM used in
tuiterm:
...
Term::with_term xterm {
Term::clean_restart 12 40
}
...
|
|
Add support for:
- DECKPAM (Application Keypad)
ESC =
- DECKPNM (Normal Keypad)
ESC >
|
|
Add support for:
- Designate G0 Character Set, USASCII
ESC ( B
- Designate G0 Character Set, DEC Special Character and Line Drawing Set
ESC ( 0
|
|
Add support for:
- Set Scrolling Region (DECSTBM)
CSI r
|
|
Add support for:
- Window manipulation (XTWINOPS)
CSI t
|
|
Add support for:
- DECSET
CSI ? h
- DECRST
CSI ? l
|
|
Add support for:
- Set Mode (SM)
CSI h
- Reset Mode (RM)
CSI l
|
|
Consider the following scenario. We start gdb and type foo:
...
$ gdb -q
(gdb) foo
^
...
Then we switch to TUI using C-x C-a, and switch back using the same key
combination.
We get back the same, but with the cursor after the prompt:
...
(gdb) foo
^
...
Typing b<ENTER> gives us:
...
(gdb) boo
❌️ No default breakpoint address now.
(gdb)
...
which means gdb didn't see "boo" here, just "b".
So while "foo" is part of the readline buffer when leaving CLI, it's not upon
returning to CLI, but it is still on screen, which is confusing.
Fix this by using rl_clear_visible_line in tui_rl_switch_mode to clear the
readline buffer when leaving CLI.
This only reproduces for me with TERM=xterm.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30523
|
|
This commit continues the theme of the previous commit, restoring the
behaviour of forward-search and reverse-search to what it was before
GDB 10, but adds tests to guard the behaviour. I believe this
restored behaviour is inline with the documentation of the two search
commands.
This time, I'm looking at what happens when no source lines end up
being printed. This can happen for two reasons, a request is made to
list a line number outside the file, or, a request is made to list a
reverse series of lines (e.g. line 100 to line 50).
Before GDB 10, a 'list' command that resulted in no lines being
printed would not change the notion of the last line listed. As a
result a future forward or reverse search would continue from the
previous last line. As an example, here's current master branch
behaviour:
(gdb) list 50
45 /* Line 45 */
46 /* Line 46 */
47 /* Line 47 */
48 /* Line 48 */
49 /* Line 49 */
50 /* Line 50 */
51 /* Line 51 */
52 /* Line 52 */
53 /* Line 53 */
54 /* Line 54 */
(gdb) list 1000
Line number 995 out of range; long-file.c has 101 lines.
(gdb) forward-search Line
Expression not found
(gdb)
But on GDB 9, the forward-search instead acts like this:
(gdb) forward-search Line
55 /* Line 55 */
(gdb)
Similarly, reverse-search reports "Expression not found" on master,
but would return line 53 on GDB 9.
The reverse-search result for master might be a little surprising,
surely, if we tried to list line 1000, then every line before that
should be searched.
The problem is that last_line_listed ends up being set to 995 (which
is 1000 minus half the listsize). Then, when the reverse-search kicks
in GDB tried to read line 994, fails, and abandons the search.
This problem was introduced with commit:
commit 8b7fcda2744145f2380af01c9db8e11986f7af6d
Date: Sun Dec 22 14:58:22 2019 +0100
Fix search in TUI
This commit wants last_line_listed updated so that the search
functions would work correctly (see notes below) when GDB is in TUI
mode. Without this commit last_line_listed would never be updated in
TUI mode, and so every search would effectively start from the
beginning of the file.
The fix I propose is to delay updating the current_source_location
until the source code has been printed successfully. That is, just
before we leave print_source_lines_base, after a successful print.
This update happens inside the 'if (noprint)' block, a the return here
isn't really considered an error condition, this is a specific choice
_not_ to print the source code.
However, in the 'if (stopline <= line)' block, the
current_source_location is not updated, that's because this 'if'
represents an error condition.
The last_line_listed is also updated at the end of the function still,
which is the path taken in CLI mode when source lines are actually
printed.
I've added some CLI tests to confirm the forward/reverse search
behaviour. And I've also added some TUI tests to check search works
within the TUI. The TUI tests cover more than just the fix for this
issue.
There is one slight issue with the TUI. At this point you should
definitively go read the previous commit. OK, so, the forward and
reverse searches are supposed to search from the last line listed.
The previous commit fixed this for CLI mode, but for the TUI the
last_line_listed is _still_ being set to the first line displayed.
The problem is that print_source_lines_base doesn't know the size of
the TUI src window, and so, doesn't know what the last line listed
will be, and so cannot set last_line_listed correctly.
This indicates to me that setting last_line_listed from the core GDB
code is likely the wrong approach, or, at least, the way it is done
now is the wrong approach.
Currently the 'list' command converts the arguments into a set of
lines to be printed based on the CLI environment, e.g. using the
'listsize' if necessary. But the 'listsize' doesn't make sense for
the TUI, where the src window height really overrides the 'listsize'.
The list command then calls the core GDB print_source_lines
function to do the printing, but for the TUI we don't actually print
anything, we just update the internal state (including
last_line_listed) and are done.
I think that the current interpreter, CLI or TUI, needs to get
involved in the 'list' command implementation much sooner. This would
allow, for example, the CLI to use 'listsize' and the TUI to use the
src window height. It might then be up to the interpreter to track
the last line listed maybe?
I mention all this only to acknowledge this issue. The problem
existed before this commit, and continues to exist after this commit.
I'm not proposing to fix this problem right now.
The TUI forward/reverse search continue to work as well as they have
since commit 8b7fcda2744.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The forward-search and reverse-search commands were broken by this
commit:
commit a75cd9a2c129dfc086cbe570ef9cff9b84570bbd
Date: Thu Nov 14 16:11:15 2019 -0700
Add observable to watch current source symtab
while builds on the work in this commit:
commit 1dd588507782591478882a891f64945af9e2b86c
Date: Thu Aug 1 09:34:40 2019 -0600
Make current_source_* per-program-space
both of these commits went into GDB 10.
The documentation for these commands is pretty clear:
'forward-search REGEXP'
'search REGEXP'
The command 'forward-search REGEXP' checks each line, starting with
the one following the last line listed, for a match for REGEXP. It
lists the line that is found. You can use the synonym 'search
REGEXP' or abbreviate the command name as 'fo'.
'reverse-search REGEXP'
The command 'reverse-search REGEXP' checks each line, starting with
the one before the last line listed and going backward, for a match
for REGEXP. It lists the line that is found. You can abbreviate
this command as 'rev'.
Both searches should start searching based on the last line listed.
But currently:
(gdb) list 3
1 int
2 main (void)
3 {
4 /* Line 4 */
5 /* Line 5 */
6 /* Line 6 */
7 /* Line 7 */
8 /* Line 8 */
9 /* Line 9 */
10 /* Line 10 */
(gdb) forward-search Line
4 /* Line 4 */
(gdb)
This should have found line 11. And for reverse-search:
(gdb) list 3
1 int
2 main (void)
3 {
4 /* Line 4 */
5 /* Line 5 */
6 /* Line 6 */
7 /* Line 7 */
8 /* Line 8 */
9 /* Line 9 */
10 /* Line 10 */
(gdb) reverse-search Line
Expression not found
(gdb)
The reverse-search should have returned line 9.
This new behaviour started with the above commits in GDB 10. On GDB 9
we see behaviour that matches the documentation.
Where the forward and reverse searches start from is controlled by a
global, last_line_listed, found in source.c.
Before commit 1dd588507782, in print_source_lines_base, the
last_line_listed variable was updated as each source line was printed,
and it was updated with the current line being printed.
After commit 1dd588507782, the current symtab and line are moved into
a current_source_location object, but the symtab and line member
variables are public. The last_line_listed is still set based on the
value held in the current_source_location object, and this object is
updated each time around the source printing loop. So despite the
restructure, the logic, and behaviour, is unchanged.
After commit a75cd9a2c129, the member variables of
current_source_location are now private. The source printing loop in
print_source_lines_base uses a local variable, new_lineno, to track
the current source line number, and updates the
current_source_location at the end of print_source_lines_base.
However, last_line_listed is still updated inside the loop, using the
original line value within current_source_location, which is no longer
being updated each time around the loop.
As a result, last_line_listed is now just the first line listed!
This didn't show up in testing because, as far as I can tell, the
last_line_listed is _only_ used for forward and reverse searching, and
the testing for these commands is minimal.
In this commit I move the setting of last_line_listed outside of the
source printing loop, this only needs to be updated once, when we have
finished printing the source lines.
I've also done a couple of other cleanups in the same area, I moved
'buf' a local variable into the most inner scope where it is required,
and I converted the 'while' loop into a 'for' loop, moving the
increment out of the loop body.
There's now a test which does some more detailed checks of the forward
and reverse search commands.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Commit 3fa785190a4f ("Altered the CREATE_xxx_COFF_TARGET_VEC macro
arguments") pretty clearly screwed up the data swapping functions in the
new CREATE_BIGHDR_COFF_TARGET_VEC() macro. Since the flaw went unnoticed,
and since the correction doesn't cause any testsuite fallout, it further
seems pretty clear that all of this is entirely untested and largely
unused.
|
|
They were dropped from spec version 007.
|
|
There's no reason to have the compiler materialize objects onto the
stack.
In fact we can save some space and a level of indirection (and hence
relocation entries in the final binary) by converting to an array of
char[12] or larger. Pick char[16] for easier / faster calculations.
|
|
The spec doesn't tie entity size to just SHF_MERGE and SHF_STRINGS
sections. Introduce a new "section letter" 'E' to allow recording (and
checking) of entity size even without 'M' or 'S'.
|
|
Being told of a problem with .section when .pushsection was used can be
irritating, especially when several of them are on the same line.
|
|
Indicate to obj_elf_parse_section_letters() whether to recognize GNU-
specific flags by conditionally passing NULL in place of a pointer to
the GNU attributes. This way wrong use of d and R can be diagnosed just
like any other use of unrecognized letters.
Furthermore adjust the md_elf_section_letter() interface: Have targets
merely return the extra letters they support. There's no point having
them customize the entire diagnostic. Even more so that additions in
common code would then reflecting in every target's diagnostic as well,
which - as can be seen - wasn't always properly done.
There's also no reason for wrong letters to be a fatal error; switch to
as_bad() while making other adjustments there.
While making the target specific adjustments, also drop IA-64's dead
handling of 'o' (SHF_LINK_ORDER), which has been covered by common code
for a long time.
Also re-arrange the switch() in obj_elf_parse_section_letters() to be
alphabetically sorted again.
|
|
obj_elf_parse_section_letters() checking for that ABI, when the checking
at the bottom of obj_elf_section() and the logic in
_bfd_elf_final_write_processing() don't, makes no sense. Either
STANDALONE is meant to be GNU-ish, or it is not, I would think. Drop the
one inconsistent check.
If it was not GNU-ish (as the other two locations suggest), what did the
section23b testcase actually mean to check? The numeric attribute value
0x200000 has an entirely unknown (or more precisely, OS-defined, which
we may or may not know of) meaning then, so ought to be accepted. If it
was GNU-ish, the other testcase, elf/section23a, would want running for
those targets as well, and the testcase in question would still be wrong
to have. Hence that testcase is removed, and section23a is renamed to
just section23.
|
|
Silently zapping them is certainly wrong. When they're not replaced due
to user request, simply keeping them may not always be correct (we don't
know what such a flag means, after all), but is certainly at least
closer to having the output object still represent what the input object
had.
This introduces new binutils/ testsuite failures, but only for two
targets where most of the tests there fail anyway (amdgcn-elf and
nfp-elf), due to there not being an assembler available.
|
|
Slim LLVM IR object is a standalone file whose first 4 bytes are 'B',
'C', 0xc0, 0xde. GCC IR object is regular ELF object with sections
whose names start with .gnu.lto_.* or .gnu.debuglto_.*. GCC IR object
uses a .gnu.lto_.lto.<some_hash> section to encode the LTO bytecode
information:
struct lto_section
{
int16_t major_version;
int16_t minor_version;
unsigned char slim_object;
/* Flags is a private field that is not defined publicly. */
uint16_t flags;
};
In slim GCC IR object, the slim_object field is non-zero. Strip should
treat slim GCC/LLVM IR objects the same. Since strip won't change slim
LLVM IR objects, it should leave slim GCC IR object unchanged even when
asked to remove all IR objects:
1. Set the lto_type field to lto_slim_ir_object for slim LLVM IR object.
2. Always copy slim IR object as unknown object.
bfd/
PR binutils/33271
* format.c (bfd_set_lto_type): Set the lto_type field to
lto_slim_ir_object for slim LLVM IR object.
binutils/
PR binutils/33271
* objcopy.c (lto_sections_removed): Removed.
(copy_archive): Always copy slim IR object as unknown object.
(copy_file): Likewise.
(strip_main): Updated.
ld/
PR binutils/33271
* testsuite/ld-plugin/lto-binutils.exp: Don't check if fat IR is
available when running slim IR tests.
* testsuite/ld-plugin/strip-1a-s-all.nd: Expect full symbol list.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
|
|
Change AC_TRY_LINK to AC_LINK_IFELSE in config/dejagnu.m4.
Reviewed-by: Indu Bhagat <indu.bhagat@oracle.com>
|
|
With test-case gdb.base/dlmopen.exp and target board native-gdbserver, I get:
...
(gdb) info breakpoints 3^M
Num Type Disp Enb Address What^M
3 breakpoint keep y 0x00007ffff7fc8000 ^M
stop only if (0) (target evals)^M
(gdb) FAIL: $exp: test_solib_unmap_events: check b/p status
...
The problem is that the regexp doesn't allow for the "(target evals)" part:
...
-re -wrap "$bpnum\\s+breakpoint\\s+keep\\s+y\\s+$::hex\\s*\[^\r\n\]+\r\n\\s+stop o
nly if \\(0\\)" {
...
Fix this by updating the regexp.
While we're at it:
- rewrite the regexp using multiline, string_to_regexp, join and string cat to
make it more readable, and
- remove the redundant failure clause from the same gdb_test_multiple.
Tested on x86_64-linux using make-check-all.sh.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
With test-case gdb.tui/basic.exp and target board native-extended-gdbserver I
get:
...
status line: '<reverse:1>extended-r No process (asm) In: L?? PC: ?? <reverse:0>'
FAIL: gdb.tui/basic.exp: status window: reverse
...
because the regexp:
...
gdb_assert { [regexp "^<.*>exec" $status] == 1 } \
...
tries to match:
...
status line: '<reverse:1>exec No process (asm) In: L?? PC: ?? <reverse:0>'
...
Fix this by updating the regexp to allow both exec and extended-r.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The copyright notices printed by these programs still use year 2024.
Update to 2025.
It seems like a trivial patch to me, but I am posting it for review, in
case there's something wrong in the new-year process that caused them to
be missed, in which case we should address that too.
Change-Id: I7d9541bb154b8000e66cfead4e4228e33c49f18b
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
I ran gdb/copyright.py and these were changed.
Change-Id: If0cfb538eff45cbb51863b963405002689512285
|
|
Commit bedd6a7a44 ("gdb/dwarf: track compilation and type unit count")
causes this internal error:
$ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.dwarf2/debug-names-duplicate-cu/debug-names-duplicate-cu -ex "save gdb-index -dwarf-5 /tmp" -batch
warning: Section .debug_names has incorrect number of CUs in CU table, ignoring .debug_names.
/home/smarchi/src/binutils-gdb/gdb/dwarf2/index-write.c:1454: internal-error: write_debug_names: Assertion `comp_unit_counter == per_bfd->num_comp_units' failed.
This is visible when running this test:
$ make check TESTS="gdb.dwarf2/debug-names-duplicate-cu.exp" RUNTESTFLAGS="--target_board=cc-with-debug-names"
...
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.dwarf2/debug-names-duplicate-cu.exp ...
gdb compile failed, warning: Section .debug_names has incorrect number of CUs in CU table, ignoring .debug_names.
/home/smarchi/src/binutils-gdb/gdb/dwarf2/index-write.c:1454: internal-error: write_debug_names: Assertion `comp_unit_counter == per_bfd->num_comp_units' failed.
...
=== gdb Summary ===
# of untested testcases 1
However, it's easy to miss because it only causes an "UNTESTED" to be
recorded, not a FAIL or UNRESOLVED. This is because the problem happens
while trying to create the .debug_names index, as part of the test case
compilation.
The problem is: when we bail out from using .debug_names because we
detect it is inconsistent with the units in .debug_info, we clear
per_bfd->all_units, to destroy all units previously created, before
proceeding to read the units with an index. However, we don't clear
per_bfd->num_{comp,type}_units. As a result, per_bfd->all_units
contains one unit, while per_bfd->num_comp_units is 2. Whenever we
clear per_bfd->all_units, we should also clear
per_bfd->num_{comp,type}_units.
While at it, move this logic inside a scoped object.
I added an assertion in finalize_all_units to verify that the size of
per_bfd->all_units equals per_bfd->num_comp_units +
per_bfd->num_type_units. This makes the problem (if omitting the fix)
visible when running gdb.dwarf2/debug-names-duplicate-cu.exp with the
unix (default) target board:
ERROR: Couldn't load debug-names-duplicate-cu into GDB (GDB internal error).
FAIL: gdb.dwarf2/debug-names-duplicate-cu.exp: find index type (GDB internal error)
FAIL: gdb.dwarf2/debug-names-duplicate-cu.exp: find index type, check type is valid
=== gdb Summary ===
# of expected passes 1
# of unexpected failures 2
# of unresolved testcases 1
I considered changing the code to build a local vector of units first,
then move it in per_bfd->all_units on success, that would avoid having
to clean it up on error. I did not do it because it's a much larger
change, but we could consider it.
Change-Id: I49bcc0cb4b34aba3d882b27c8a93c168e8875c08
Approved-By: Tom Tromey <tom@tromey.com>
|
|
With test-case gdb.base/condbreak-multi-context.exp on target board
native-gdbserver, I run into:
...
(gdb) continue
Continuing.
gdb/ax-gdb.c:542: internal-error: gen_var_ref: \
LOC_CONST_BYTES symbols are not supported
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
FAIL: $exp: start_before=true: scenario_1: run until A::func (GDB internal error)
Resyncing due to internal error.
0x64cfa9 gdb_internal_backtrace_1
gdb/bt-utils.c:122
0x64d047 _Z22gdb_internal_backtracev
gdb/bt-utils.c:175
0x10cfdf1 internal_vproblem
gdb/utils.c:423
0x10d020b _Z15internal_verrorPKciS0_P13__va_list_tag
gdb/utils.c:503
0x19a6b4e _Z18internal_error_locPKciS0_z
gdbsupport/errors.cc:57
0x5b76f9 gen_var_ref
gdb/ax-gdb.c:541
0x5b9565 gen_static_field
gdb/ax-gdb.c:1460
0x5b91c9 gen_struct_ref_recursive
gdb/ax-gdb.c:1357
0x5b93f8 gen_struct_ref
gdb/ax-gdb.c:1427
0x5bba0d _Z17gen_expr_structopP10expression10exp_opcodePN4expr9operationEPKcP10agent_exprP9axs_value
gdb/ax-gdb.c:2253
0x678d94 _ZN4expr22structop_ptr_operation14do_generate_axEP10expressionP10agent_exprP9axs_valueP4type
gdb/expop.h:1089
0x5b9ab6 _ZN4expr9operation11generate_axEP10expressionP10agent_exprP9axs_valueP4type
gdb/ax-gdb.c:1602
0x5bb905 _Z14gen_expr_binopP10expression10exp_opcodePN4expr9operationES4_P10agent_exprP9axs_value
gdb/ax-gdb.c:2233
0x69815c _ZN4expr24usual_ax_binop_operationIL10exp_opcode14EXadL_Z13eval_op_equalP4typeP10expression6nosideS1_P5valueS8_EEE14do_generate_axES5_P10agent_exprP9axs_valueS3_
gdb/expop.h:1291
0x5b9ab6 _ZN4expr9operation11generate_axEP10expressionP10agent_exprP9axs_valueP4type
gdb/ax-gdb.c:1602
0x5bc034 _Z17gen_eval_for_exprmP10expression
gdb/ax-gdb.c:2396
0x5f16b6 parse_cond_to_aexpr
gdb/breakpoint.c:2582
0x5f18a5 build_target_condition_list
gdb/breakpoint.c:2640
0x5f2698 insert_bp_location
gdb/breakpoint.c:2970
0x5f3916 insert_breakpoint_locations
gdb/breakpoint.c:3400
0x60c1dd update_global_location_list
gdb/breakpoint.c:11771
0x5f3421 _Z18insert_breakpointsv
gdb/breakpoint.c:3293
0xaa0972 keep_going_pass_signal
gdb/infrun.c:9131
0xa91b23 proceed_resume_thread_checked
gdb/infrun.c:3579
0xa92490 _Z7proceedm10gdb_signal
gdb/infrun.c:3780
0xa72b9b _Z10continue_1i
gdb/infcmd.c:639
0xa72e4b continue_command
gdb/infcmd.c:730
0x6c01d1 do_simple_func
gdb/cli/cli-decode.c:95
0x6c683a _Z8cmd_funcP16cmd_list_elementPKci
gdb/cli/cli-decode.c:2827
0xff11a9 _Z15execute_commandPKci
gdb/top.c:565
0x959e0a _Z15command_handlerPKc
gdb/event-top.c:613
0x95a3e7 _Z20command_line_handlerOSt10unique_ptrIcN3gdb13xfree_deleterIcEEE
gdb/event-top.c:849
0x102b645 tui_command_line_handler
gdb/tui/tui-interp.c:101
0x959548 gdb_rl_callback_handler
gdb/event-top.c:288
0x1186dfd rl_callback_read_char
readline/readline/callback.c:302
0x95925a gdb_rl_callback_read_char_wrapper_sjlj
gdb/event-top.c:197
0x95934a gdb_rl_callback_read_char_wrapper_noexcept
gdb/event-top.c:240
0x9593c9 gdb_rl_callback_read_char_wrapper
gdb/event-top.c:252
0x1071253 stdin_event_handler
gdb/ui.c:154
0x19a7c80 handle_file_event
gdbsupport/event-loop.cc:551
0x19a825b gdb_wait_for_event
gdbsupport/event-loop.cc:672
0x19a711c _Z16gdb_do_one_eventi
gdbsupport/event-loop.cc:263
0x6ce4e3 _ZN6interp12do_one_eventEi
gdb/interps.h:87
0xb74717 start_event_loop
gdb/main.c:402
0xb748b6 captured_command_loop
gdb/main.c:467
0xb7638f captured_main
gdb/main.c:1345
0xb76438 _Z8gdb_mainP18captured_main_args
gdb/main.c:1364
0x41a411 main
gdb/gdb.c:38
...
This reproduces with gcc 7, not with gcc 8 or later.
Fix this by throwing an error instead of asserting, getting us instead:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2.2, A::func (this=$hex) at condbreak-multi-context.cc:31^M
31 void func () {}^M
(gdb) PASS: $exp: start_before=true: scenario_1: run until A::func
...
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
PR gdb/32012
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32012
|
|
The convenience function get_frame_pc_if_available would take a pointer
to a variable that should be set if available, and would return a
boolean indicating whether that action was successful or not.
Now that GDB supports C++17 features, this indirection of a pointer and
returning boolean is unnecessary, since the function can return an
optional, and code that calls it can check if the optional contains a
value.
This commit makes that modernization. It should have no visible
effects.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In lib/tuiterm.exp we have:
...
namespace eval Term {
variable ...
...
}
...
with everything within the namespace (which is basically the entire file)
indented, which wastes screen space and makes editing more involved.
We could maybe fix this by moving the "namespace eval Term" to tuiterm_env,
but I don't think it's a good idea to move it out of the file.
Another idea is to have the file include itself, wrapped in the namespace:
...
if { ![info exists Term::_in_namespace] } {
namespace eval Term {
# Read the rest of this file, wrapped in this namespace.
variable _in_namespace
set _in_namespace 1
source $::srcdir/lib/tuiterm.exp
unset _in_namespace
return
}
}
variable ...
...
but this was considered unnecessarily complex.
Fix this in the style of lib/ton.tcl and lib/completion-support.exp:
- only declare the variables in the namespace, and
- define the procs using a Term:: prefix.
As a side-effect, this works around an emacs bug that makes editing
lib/tuiterm.exp in its current form problematic because the auto-indentation
keeps removing required indentation of all but the first proc [1].
Tested on x86_64-linux.
[1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-11/msg01674.html
|
|
GDB has support for many binary file formats, some which might be very
unlikely to be found in some situations (such as the XCOFF format in
an x86 system). This commit introduces the option for a user to choose
which formats GDB will support at build configuration time.
This is especially useful to avoid possible security concerns with
readers that aren't expected to be used at all, as they are one of
the simplest vectors for an attacker to try and hit GDB with. This
change can also reduce the size of the final binary, if that is a
concern.
This commit adds a switch to the configure script allowing a user to
only enable selected file formats, called --enable-binary-file-formats.
The default behavior when the switch is omitted is to compile all file
formats, keeping the original behavior of the script. At the time of
this commit, the valid options for this option are: dbx, coff (which
includes coff-pe), xcoff, mips, elf, macho and all. All is treated
especially, activating all supported readers.
A few targets may require specific binary file format support, as they
directly call functions defined by the file reader. Specifically,
windows targets require coff support, and rs6000 aix and lynx178 targets
require xcoff support. Considering that those formats are the main - or
only - one available in those targets, I believe it makes sense to
re-enable those readers. If that happens, the script will emit the
following warning:
FOO is required to support one or more requested targets. Adding it
Users aren't able to force the disabling of those formats, since GDB
will not compile without those readers. Ideally we'd like to be able
to disable even those formats, in case a user wants to build GDB only
to examine remote files for example, but the current infrastructure
for the file format readers doesn't allow us to do it.
Mach-O and elf support are also dependent on BFD support being compiled
in. In case one of those was requested and BFD does not support them,
the following error is emitted:
FOO was requested, but BFD does not support it.
Finally, this configure switch is also printed by the "show
configuration" command in GDB.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Fix PR ld/33199 SEGV in _bfd_x86_elf_create_sframe_plt
Currently, the selection for sframe_plt was not being done (and simply
set to NULL) for the case when !normal_target, causing SEGV on Solaris.
Initialize sframe_plt to init_table->sframe_lazy_plt when lazy_plt is
true, and NULL otherwise. This is in line with htab->non_lazy_plt being
set to NULL for !normal_target.
bfd/
PR ld/33199
* elfxx-x86.c (_bfd_x86_elf_link_setup_gnu_properties):
Setup sframe_plt for !normal_target.
|
|
In a later commit I'd like to add support to GDB for including the
NT_386_TLS note in the core files that GDB creates (using 'gcore'
command).
To achieve this we need some standard boilerplate code added to bfd.
The only part of this patch which I think needs consideration is the
name I selected for the pseudo section to hold the note contents when
a core file is loaded. I chose '.reg-i386-tls'. The '.reg' prefix is
the standard used by most other pseudo sections, and the '-i386-tls'
suffix seemed to match the note name, though I added the 'i' to
'i386', instead of just using '.reg-386-tls'. I thought 'i386' seemed
clearer.
There's no test included here, but when I merge the NT_386_TLS
creation to GDB it will depend on this and act as a test. I plan to
post that work to the GDB list once this patch is merged.
|
|
Use stat, instead of strcmp, to check if the same linker script file
appears multiple times for
$ ld -L... -T ././/script.t -T script.t ...
Although ././/script.t and script.t access the same file, but their
filenames are different. strcmp won't work here.
Copy gnulib/import/same-inode.h to include since the gnulib directory
isn't included in the binutils tarball.
include/
PR ld/24576
* same-inode.h: New file. Copied from gnulib/import/same-inode.h.
ld/
PR ld/24576
* ldfile.c: Include "same-inode.h".
(ldfile_find_command_file): Change the second argument from bool
to enum script_open_style. Check if the same linker script file
appears multiple times by using stat, instead using strcmp.
(ldfile_open_command_file_1): Don't check if the same linker
script file appears multiple times here.
* testsuite/ld-scripts/pr24576-1.d: Adjusted.
* testsuite/ld-scripts/pr24576-2.d: New.
* testsuite/ld-scripts/script.exp: Run pr24576-2.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
On x86_64-freebsd, with test-case gdb.tui/main.exp, I ran into a failure to
match the output of the file command, for which I submitted a patch [1].
However, after switching to TERM=ansiw for bsd, I could no longer reproduce
the problem.
Investigation showed that the difference was caused by CLI styling.
A command:
...
(gdb) file <filename>
...
gives an output:
...
Reading symbols from <filename>...
(gdb)
...
On x86_64-linux, with CLI styling I get:
...
Reading symbols from ^[[32m/data/vries/gdb/leap-15-6/build/gdb/testsuite/outputs/gdb.tui/main/main^[[39m^[[0;10m...
...
After disabling CLI styling using "set style enabled off", I simply get:
...
Reading symbols from /data/vries/gdb/leap-15-6/build/gdb/testsuite/outputs/gdb.tui/main/main...
...
and run into the same failure as on x86_64-freebsd.
The extra csi sequence "^[[32m" causes an additional matching attempt in
Term::wait_for, and the way we're currently matching relies on this:
...
send_gdb "file [standard_output_file $testfile]\n"
gdb_assert { [Term::wait_for "Reading symbols from"] } "file command"
...
Make the TUI testsuite more stable and matching more simple by disabling CLI
styling by default, and:
- fix the resulting fallout in test-cases gdb.tui/main.exp and
gdb.tui/new-layout.exp, and
- re-enable CLI styling in the one test-case that needs it:
gdb.tui/tui-disasm-styling.exp.
Tested on x86_64-linux.
[1] https://sourceware.org/pipermail/gdb-patches/2025-June/218942.html
|
|
Recognise ECOFF archives and reject them so that the ecoff archive
support has a chance to handle the archive. Also use memcmp rather
than startswith (strncmp) as we know the string length.
* archive.c (bfd_slurp_armap): Recognize ECOFF armap. Use memcmp
to match names, and tidy buffer sizes.
|
|
This tidies objcopy/strip handling of IR objects, in the process of
removing the unnecessary is_strip_input flag.
The first thing I noticed when looking at is_strip_input code was that
the abfd->my_archive test in bfd_check_format_matches meant that
plugins were disabled when reading archive elements. We can instead
disable plugins by setting bfd_no_plugin, so there doesn't seem to be
a need for is_strip_input in objcopy.c:copy_archive. This isn't
exactly the same, because bfd_no_plugin prevents the plugin target
recognising archive elements in the bfd_check_format_matches loop over
all targets as well as just the first !target_defaulted test. But
that turns out to be fine. IR code is handled in copy_archive as for
other unknown format files. In fact, the only need for the plugin
target when copying archives is when reading symbols for the archive
map. I've made that plain by moving the plugin target override and
commenting on why it is really needed.
So on to plain object files. Here, IR code is also copied unchanged,
so there doesn't seem a need for the plugin target there either. It
isn't quite so simple though, because the objcopy/strip code handling
object files wants to verify the format of the object file. Allowing
objcopy/strip to copy unknown format files would be a change in
behaviour (and results in mmix testsuite fails, ld-mmix/b-badfil1 and
others). However, always excluding the plugin target results in a
fail of tests added in commit c2729c37f10a. So I've enabled a plugin
format check only for files that are otherwise unrecognised, and
commented why this is done. I question the need to objcopy LLVM
bytecode files.
bfd/
* bfd.c (struct bfd<is_strip_input>): Delete.
* format.c (bfd_check_format_matches): Delete is_strip_input
special case code.
* bfd-in2.h: Regenerate.
binutils/
* objcopy.c (copy_archive): Don't set is_strip_input. Always
set bfd_plugin_no when reading elements. Enable plugins when
opening copied elements.
(check_format_object): Delete.
(copy_file): Don't enable plugin target here. Don't set
is_strip_input. Set bfd_plugin_no. Move bfd_core handling
code earlier to remove goto. Enable plugin for llvm bytecode.
Copy slim IR files as unknown objects.
|
|
If we have an existing archive, the test may fail due to it being the
wrong format. Also, downloading bintest.thin.a from a remote host
(before creating it!) is wrong.
* testsuite/binutils-all/readelf.exp (readelf_thin_archive_test):
Don't remote_download bintest.thin.a. Delete lib before
creating.
|
|
On x86_64-freebsd, I run into:
...
Box Dump (80 x 24) @ (0, 0):
0 (gdb) maint info screen
1 Number of characters gdb thinks are in a line is 90.
2 Number of characters readline reports are in a line is 89.
3 Number of characters curses thinks are in a line is 90.
4 Number of characters environment thinks are in a line is 90 (COLUMNS).
5 Number of lines gdb thinks are in a page is 40.
6 Number of lines readline reports are in a page is 40.
7 Number of lines curses thinks are in a page is 40.
8 Number of lines environment thinks are in a page is 40 (LINES).
9 Readline wrapping mode: readline (terminal is not auto wrap capable, last column
10 .
11 (gdb) tui disable
12 (gdb) tui disable
13 (gdb) maint info screen
14
15
16
17
18
19
20
21
22
23
FAIL: gdb.tui/resize-2.exp: again: curses width 80
...
The problem is that the prompt matching in Term::wait for is not strict enough.
It will accept a line:
...
(gdb) foo
...
as long as the cursor is pointing just after the prompt, like so:
...
(gdb) foo
^
...
Fix this by also checking that the line is empty.
Tested on x86_64-linux.
|
|
With a gdb build with gcc 15.1.1 and "-O2 -flto=auto -g", I run into:
...
UNTESTED: gdb.gdb/selftest.exp: \
Cannot set breakpoint at captured_main, skipping testcase.
UNTESTED: gdb.gdb/python-helper.exp: \
Cannot set breakpoint at captured_main, skipping testcase.
...
I don't know why we're trying to stop in captured_main.
Stopping in main also works, and main is more likely to be present in an lto
build.
Fix this by using main instead.
This requires us to update the expected file name from main.c to gdb.c in
selftest_setup.
After doing so, we get:
...
XFAIL: gdb.gdb/selftest.exp: \
run until breakpoint at main (line numbers scrambled?)
XFAIL: gdb.gdb/python-helper.exp: \
run until breakpoint at main (line numbers scrambled?)
...
because main is reported to be in run-on-main-thread.c instead of gdb.c:
.
Breakpoint 1, main (...) at gdb/run-on-main-thread.c:120^M
...
This is due to picking the last line entry for pc == 0x455e40 that has
is_stmt == true:
...
File name Line number Starting address View Stmt
gdb/gdb.c:
gdb.c 25 0x455e40 x
gdb.c 30 0x455e40 1 x
gdb/run-on-main-thread.c:
run-on-main-thread.c 116 0x455e40 2 x
run-on-main-thread.c 120 0x455e40 3 x
gdb/gdb.c:
gdb.c 25 0x455e40 4
/usr/include/c++/15/bits/std_thread.h:
std_thread.h 366 0x455e4b
...
While we're at it, update the corresponding gdb_test_multiple in
selftest_setup using multi_line and -wrap.
Tested on x86_64-linux.
|
|
PR cli/21690 reports the following: say we start gdb:
...
$ gdb -q
(gdb)
...
and press ^R for reverse-i-search:
...
(reverse-i-search)`':
...
Pressing the p key has the effect of showing both the pressed key and a
matching entry, which happens to be up:
...
(reverse-i-search)`p': up
...
Now we press ^C to cancel the search:
...
(reverse-i-search)`p': u❌️ Quit
(gdb)
...
and type "down".
We expected to get:
...
(gdb) down
...
but instead we get:
...
(failed reverse-i-search)`pdown':
...
So we're stuck in reverse-i-search, until we use the workaround of ^G.
The same problem happened with python [1], was reported upstream [2], and
fixed in cpython commit d6990d221b0 ("Issue #24266: Cancel history search mode
with Ctrl+C in Readline 7") using rl_callback_sigcleanup.
Fix this likewise in quit using rl_callback_sigcleanup, a new callback
function in readline 7.0:
...
i. rl_callback_sigcleanup: a new application function that can clean up and
unset any state set by readline's callback mode. Intended to be used
after a signal.
...
giving us instead:
...
$ gdb
(gdb) u❌️ Quit
(gdb) down
...
Remove the corresponding kfail in gdb.tui/pr30056.exp.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21690
[1] https://bugs.python.org/issue24266
[2] https://lists.gnu.org/archive/html/bug-readline/2015-05/msg00014.html
|
|
The original patch,
e6f372ba661bb0d8eec1e22a6dc1ad9937336e4d
Since recently c.slli64, c.srai64, and c.srli64 have been removed from the
riscv-isa-manual, c.slli, c.srli, and c.srai with 0 immediate are now listed
as hints,
https://github.com/riscv/riscv-isa-manual/pull/1942 and https://github.com/riscv/riscv-isa-manual/pull/2093
So allow c.slli, c.srli, and c.srai with 0 immediate as a hint. Also allow to
assemble slli, srli and srai with 0 immediate to hint c.slli, c.srli and c.srai
when rvc is enabled. The c.slli64, c.srai64, and c.srli64 should be kept as
aliases, so dis-assembler should disassemble to c.slli, c.srli, and c.srai with
0 immediate.
Passed rv32/64-elf/linux binutils testcases.
gas/
PR 33216
* testsuite/gas/riscv/c-zero-imm.d: Updated since allow c.slli64,
c.srai64, and c.srli64 with 0 immediate as a hint.
* testsuite/gas/riscv/c-zero-imm.s: Likewise.
* testsuite/gas/riscv/zca.d: Likewise.
opcodes/
PR 33216
* riscv-opc.c (riscv_opcodes): Updated since allow c.slli64, c.srai64,
and c.srli64 with 0 immediate as a hint.
|
|
|
|
PR symtab/33247 points out that this check in
create_addrmap_from_gdb_index:
if (lo > hi)
{
complaint (_(".gdb_index address table has invalid range (%s - %s)"),
hex_string (lo), hex_string (hi));
... should probably use ">=" instead. Reading a bit further the
reason seems obvious:
mutable_map.set_empty (lo, hi - 1, index->units[cu_index]);
Here if lo==hi, then this will insert a "reversed" range into the
addrmap.
Apparently some LLVM tool can erroneously create a .gdb_index like
this.
No test because it seems like more trouble to write than it's worth.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33247
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
captured_main takes a 'void *', but then immediately casts it to the
correct type. There's no reason for this any more, the caller passes
in the correct type. This patch cleans this up. Tested by
rebuilding.
|
|
Remove AM_PROG_CC_STDC, the correct macro AC_PROG_CC is already being
used.
Update AC_OUTPUT (file list, [cmd list]) by adding the file list to
the previous AC_CONFIG_FILES and using AC_CONFIG_COMMANDS to output
the command list.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
|
|
Function tui_disassemble (with addr_size parameter) has two modes of
operation:
- addr_size != nullptr, and
- addr_size == nullptr.
I noticed that for the addr_size == nullptr case, more than necessary is done.
Fix this by using continue and null_stream.
While we're at it, eliminate the unnecessary variables new_size and orig_pc.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
