oss-fuzz found that I missed some error paths in commit 9e68cae4fd.
This fix prevents reads of a NULL pointer in sort_resources.
* rescoff.c (read_coff_res_dir): Check return of recursive calls
and read_coff_data_entry calls. Pass failures up the call chain.
Some tests need to be compiled with additional flags. When binutils is
built and compiled with
CC="gcc -fsanitize=address,undefined" CXX="g++ -fsanitize=address,undefined"
some linker tests fail to disable address sanitizer options since
proc default_ld_compile has
set ccexe $cc
set ccparm [string first " " $cc]
set ccflags ""
if { $ccparm > 0 } then {
set ccflags [string range $cc $ccparm end]
set ccexe [string range $cc 0 $ccparm]
set cc $ccexe
}
...
set cmd "$cc $flags $ccflags -c $source -o $object"
Compiler flags in $CC and $CXX will be the last ones. Add
CFLAGS_FOR_TARGET_TEST and CXXFLAGS_FOR_TARGET_TEST to use them in
proc default_ld_compile
set cflag_test ""
set cxxflag_test ""
if {[string match "*++*" $ccexe]} {
append flags " $CXXFLAGS_FOR_TARGET"
set cflag_test "$CXXFLAGS_FOR_TARGET_TEST"
} else {
append flags " $CFLAGS_FOR_TARGET"
set cflag_test "$CFLAGS_FOR_TARGET_TEST"
}
...
set cmd "$cc $flags $ccflags $cflag_test -c $source -o $object"
so that they will be the last flags passed to compiler. Also update
run_ld_link_exec_tests and run_cc_link_tests to make
CFLAGS_FOR_TARGET_TEST and CXXFLAGS_FOR_TARGET_TEST the last flags
passed to compiler.
* testsuite/config/default.exp (CFLAGS_FOR_TARGET_TEST): New.
(CXXFLAGS_FOR_TARGET_TEST): Likewise.
* testsuite/ld-elf/dwarf.exp (CFLAGS_FOR_TARGET): Renamed to ...
(CFLAGS_FOR_TARGET_TEST): This.
* testsuite/ld-elf/shared.exp: Save, append and restore
CFLAGS_FOR_TARGET_TEST and CXXFLAGS_FOR_TARGET_TEST for
$build_tests. Save, append and restore CFLAGS_FOR_TARGET_TEST,
instead of CFLAGS_FOR_TARGET, for $dlopen_run_tests.
* testsuite/ld-plugin/plugin.exp (CFLAGS_FOR_TARGET): Renamed to
...
(CFLAGS_FOR_TARGET_TEST): This.
* testsuite/ld-shared/shared.exp (CFLAGS_FOR_TARGET): Renamed to
...
(CFLAGS_FOR_TARGET_TEST): This.
* testsuite/ld-srec/srec.exp (CFLAGS_FOR_TARGET): Renamed to ...
(CFLAGS_FOR_TARGET_TEST): This.
(CXXFLAGS_FOR_TARGET): Renamed to ...
(CXXFLAGS_FOR_TARGET_TEST): This.
* testsuite/lib/ld-lib.exp (default_ld_compile): Append
CFLAGS_FOR_TARGET_TEST/CXXFLAGS_FOR_TARGET_TEST to compiler flags.
(run_ld_link_exec_tests): Append CFLAGS_FOR_TARGET_TEST and
CXXFLAGS_FOR_TARGET_TEST to compiler.
(run_cc_link_tests): Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
On aarch64-linux, occasionally I run into these warnings:
...
PASS: gdb.tui/tui-mode-switch.exp: set style enabled off
WARNING: timeout in accept_gdb_output
PASS: gdb.tui/tui-mode-switch.exp: no boo
WARNING: timeout in accept_gdb_output
...
The first in more detail:
...
Box Dump (40 x 1) @ (0, 11):
11 b(gdb) b
WARNING: timeout in accept_gdb_output
...
Fix this by waiting for a prompt after leaving TUI before sending "b".
Also, while we're at it generate a few more passes.
Tested on aarch64-linux.
Set the is_linker_input field when adding object only section.
* ldlang.c (cmdline_add_object_only_section): Set the
is_linker_input field.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Several no-plt tests FAIL on 32-bit Solaris/x86:
FAIL: Build libno-plt-1b.so
FAIL: No PLT (dynamic 1a)
FAIL: No PLT (dynamic 1b)
FAIL: No PLT (dynamic 1c)
FAIL: No PLT (PIE 1e)
FAIL: No PLT (PIE 1f)
FAIL: No PLT (PIE 1g)
The failure mode is always similar, e.g.
../binutils/objdump -dwrj.text tmpdir/libno-plt-1b.so > dump.out
regexp_diff match failure
regexp "^ +[a-f0-9]+: 8b 80 ([0-9a-f]{2} ){4}[ ]+mov +-0x[a-f0-9]+\(%eax\),%eax$"
line " 4aa: 8b 80 14 00 00 00 mov 0x14(%eax),%eax"
regexp_diff match failure
regexp "^ +[a-f0-9]+: ff a0 ([0-9a-f]{2} ){4}[ ]+jmp +\*-0x[0-9a-f]+\(%eax\)$"
line " 4ca: ff a0 14 00 00 00 jmp *0x14(%eax)"
i.e. there's a positive offset from the GOT instead of the expected
negative one. AFAICS that's because there are additional GOT entries on
the Solaris side (printed with elfdump -G since there seems to be no
support for that in either readelf or objdump):
* Solaris/i386:
Global Offset Table Section: .got
index addr value pending relocation
[0] 0x15f4 0x1514
[1] 0x15f8 0
[2] 0x15fc 0
[3] 0x1600 0x3a6 R_386_JMP_SLOT __cxa_finalize
[4] 0x1604 0 R_386_GLOB_DAT _ITM_deregisterTMCloneTable
[5] 0x1608 0 R_386_GLOB_DAT func
* Linux/i686:
Global Offset Table Section: .got
index addr value pending relocation
[0] 0x3fe0 0 R_386_GLOB_DAT _ITM_deregisterTMCloneTable
[1] 0x3fe4 0 R_386_GLOB_DAT __cxa_finalize
[2] 0x3fe8 0 R_386_GLOB_DAT __gmon_start__
[3] 0x3fec 0 R_386_GLOB_DAT func
This patch fixes this by making the sign optional in affected cases.
Tested on i386-pc-solaris2.11 and i686-pc-linux-gnu.
2025-07-25 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
ld:
* testsuite/ld-i386/libno-plt-1b.dd: Allow for positive GOT
offsets.
* testsuite/ld-i386/no-plt-1a.dd: Likewise.
* testsuite/ld-i386/no-plt-1b.dd: Likewise.
* testsuite/ld-i386/no-plt-1c.dd: Likewise.
* testsuite/ld-i386/no-plt-1e.dd: Likewise.
* testsuite/ld-i386/no-plt-1f.dd: Likewise.
* testsuite/ld-i386/no-plt-1g.dd: Likewise.
This allows the correct file name to be used when emitting messages for
lines within a macro. The line numbers were already set and displayed
correctly, which resulted in mismatched file names and line numbers.
PR 32738
Message output from gas is prefixed with a line of the form:
path/file.s: Assembler messages:
Don't use the file name from the first message for this header.
Instead, use the source file name specified in the command line.
Instead make bfd_check_format try the plugin target first when the
user hasn't supplied a target.
bfd/
* format.c (bfd_check_format_matches): Try for a plugin target
match first.
* targets.c (bfd_find_target): Don't specially treat "plugin".
binutils/
* ar.c (plugin_target): Delete.
(open_inarch): Don't set target of archive elements.
(replace_members): Use target rather than plugin_target when
opening replacement or additional files.
* arsup.c (plugin_target): Delete. Replace all uses with NULL.
(ar_open): Don't set element target.
* bucomm.h (set_plugin_target): Delete.
* nm.c (plugin_target): Delete.
(display_archive): Don't set element target.
(display_file): Alway use target when opening file.
* objcopy.c (copy_archive): Don't use plugin target for output
elements.
* NEWS: Mention stricter target checking.
If a linker script has a group nested too deeply by mistake, issue an
error instead of hanging forever without outputting any error message.
PR ld/33265
* ldlang.c (MAX_NESTED_GROUP_DEPTH): New.
(open_input_bfds): Add a pointer argument for the nested group
count. Increment the count before the while loop and decrement
it after the loop. Issue an error if the nested group count >=
MAX_NESTED_GROUP_DEPTH when processing input statement.
(lang_process): Update open_input_bfds calls.
(cmdline_emit_object_only_section): Likewise.
* testsuite/ld-scripts/libpr33265-1.a: New file.
* testsuite/ld-scripts/libpr33265-2.a: Likewise.
* testsuite/ld-scripts/libpr33265-3a.a: Likewise.
* testsuite/ld-scripts/libpr33265-3b.a: Likewise.
* testsuite/ld-scripts/libpr33265-3c.a: Likewise.
* testsuite/ld-scripts/pr33265-1.d: Likewise.
* testsuite/ld-scripts/pr33265-2.d: Likewise.
* testsuite/ld-scripts/pr33265-3.d: Likewise.
* testsuite/ld-scripts/script.exp: Run PR ld/33265 tests.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Use sframe_encoder_add_funcdesc_v2 instead of sframe_encoder_add_funcdesc.
Similarly, use sframe_decoder_get_funcdesc_v2 instead of
sframe_decoder_get_funcdesc.
sframe_encoder_add_funcdesc, and sframe_decoder_get_funcdesc were first
added for SFrame V1. For the purpose of these testcases, the two V2
APIs are (almost) functionally equivalent. In future, we may want to
make sframe_encoder_add_funcdesc and sframe_decoder_get_funcdesc
internal to libsframe only. Using the V2 named APIs is better for
clarity as well.
libsframe/testsuite/
* libsframe.encode/encode-1.c: Use V2 named APIs instead.
* libsframe.find/findfre-1.c: Likewise.
* libsframe.find/findfunc-1.c: Likewise.
* libsframe.decode/be-flipping.c: Likewise.
* libsframe.decode/frecnt-1.c: Likewise.
* libsframe.decode/frecnt-2.c: Likewise.
Previously, some of the libsframe tests were updated to reduce the usage
of magic numbers. This patch makes encode-1.c follow similar coding
style as other tests, reducing the number of magic constants.
libsframe/testsuite/
* libsframe.encode/encode-1.c: Avoid magic numbers.
oss-fuzz generated a total length field of 32, when the header was 40
bytes. Subtracting gave -8ul for the remaining length..
I think we should be sanity checking the total length given in the
header against the remaining buffer length and the size of the header
each time get_version_header is called.
Possibly vallen should be sanity checked inside get_version_header
too, but I'll leave that to someone else.
PR 27686
* resbin.c (bin_to_res_version): Correct error message arg.
Move len vs. buffer length sanity check..
(get_version_header): ..to here. Also sanity check len
against off.
Several ld CTF tests FAIL on 32-bit SPARC, e.g.
FAIL: Arrays (conflicted)
The failure mode is always the same:
./tmpdir/array-char-conflicting-1.s: Assembler messages:
./tmpdir/array-char-conflicting-1.s:89: Error: Architecture mismatch on "return %i7+8".
./tmpdir/array-char-conflicting-1.s:89: (Requires v9|v9a|v9b|v9c|v9d|v9e|v9v|v9m|m8; requested architecture is sparclite.)
The problem is that gcc emits v8plus code by default, and thus invokes
as with -xarch=v8plus (equivalent to -Av8plus), while the testcase lacks
the latter.
Fixed by setting ASFLAGS to match.
Tested on sparc-sun-solaris2.11, sparc-unknown-linux-gnu,
sparcv9-sun-solaris2.11, and sparc64-unknown-linux-gnu.
2025-07-25 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
ld:
* testsuite/ld-ctf/ctf.exp (ASFLAGS): Append -Av8plus on
sparc-*-*.
Every time we update the gdb version number, test-case gdb.base/default.exp
needs updating because it matches the values of convenience variables
$_gdb_{major,minor} using hardcoded expected values:
...
{$_gdb_major = 17} \
{$_gdb_minor = 1} \
...
I'm assuming the values were hardcoded because gdb_test_list_exact was used.
Since the previous patch, that's not longer the case, so use regexps instead,
getting rid of this annoyance [1].
Tested on x86_64-linux.
[1] https://sourceware.org/pipermail/gdb-patches/2019-October/160935.html
An oss-fuzz testcase with a SHT_GROUP section named .debug managed to
break objcopy --compress-debug-sections. The underlying problem is
that SEC_DEBUGGING is set by section name tests, thus the SHT_GROUP
section gets compressed. The compressed section data is smaller than
the original section sh_size, and process_sht_group_entries tries to
look at sh_size worth of entries. The patch fixes this mess by simply
not setting SEC_DEBUGGING on SHT_GROUP sections.
Note that it isn't correct to restrict SEC_DEBUGGING to SHT_PROGBITS
sections, as that will break processor/os special sections for debug.
eg. SHT_MIPS_DEBUG.
* elf.c (_bfd_elf_make_section_from_shdr): Don't set
SEC_DEBUGGING on SEC_GROUP sections no matter their name.
I ran test-case gdb.base/default.exp with make-check-all.sh, and noticed a
FAIL with host/target board local-remote-host-native:
...
FAIL: $exp: show convenience ($_colorsupport = "monochrome" not found)
...
The problem is that part of the test-case relies on "setenv TERM dumb", and
setenv, which is a tcl command (which runs on build), only has effect in gdb
(which runs on host), if build == host, in other words, local host.
I grepped for test-cases using setenv, and ran them with the host/target
board, and fixed the FAILs I saw.
All FAILs have the same cause as I described above, except for
proc test_data_directory in gdb.python/py-parameter.exp, which handles files
assuming local host. I chose to leave it that way, and bail out but add a
comment.
Implementationwise, the change to test-case gdb.base/default.exp is the most
intrusive: it replaces a use of proc gdb_test_list_exact with a use of proc
gdb_get_lines_no_pass, because it allows specifying a regexp match.
In the process, I found out gdb_test_list_exact has a bug, filed as PR33038.
Because of this bug, I had to add matching of convenience variable $_tbl.
Tested on x86_64-linux.
While re-testing the TUI tests on x86_64-freebsd, I found that commit
06a53717f7 ("[gdb/testsuite] Handle unrecognized escape sequences better in
tuiterm") broke most test-cases.
Fix this by rewriting this gdb_test_multiple clause:
...
-re "^($re_csi_prefix?)($re_csi_args*)($re_csi_cmd)" {
...
into:
...
-re "^($re_csi_cmd)" {
...
-re "^($re_csi_args*)($re_csi_cmd)" {
...
-re "^($re_csi_prefix?)($re_csi_args*)($re_csi_cmd)" {
...
Tested on x86_64-linux and x86_64-freebsd.
When encountering an unrecognized escape sequence in Term::accept_gdb_output,
a warning is issued:
...
WARNING: timeout in accept_gdb_output
...
and 0 is returned.
Subsequent calls run into the same problem, so matching doesn't progress.
Consequently, figuring out what the unrecognized escape sequence actually is
depends on analyzing gdb's output as echoed into gdb.log.
In the test added in this commit, gdb (well, a script gdb.tcl emulating gdb)
outputs escape sequence "ESC ( B", which doesn't show up in recognizable form
in gdb.log:
...
foo^M^M
...
and as mentioned the tuiterm screen only show:
...
foo
...
because matching doesn't progress beyond the unrecognized sequence.
Fix this by rewriting accept_gdb_output to match gdb output using a phased
approach that echoes unmatched escape sequences, giving us instead on the
tuiterm screen:
...
foo^[(B
...
[ Since "ESC ( B" is now supported, the test-case has been updated to use
"ESC ( % 5" instead. ]
Tested on x86_64-linux.
PR testsuite/33218
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33218
The variable Term::_last_char is meant to represent the last char inserted by
Term::_insert, but setting it is done alongside the only call to _insert in
lib/tuiterm.exp:
...
_insert $expect_out(0,string)
variable _last_char
set _last_char [string index $expect_out(0,string) end]
...
Fix this by moving the setting of _last_char to inside _insert.
Tested on x86_64-linux.
bfd_check_format currently does not take much notice of the target
set in its abfd arg, merely checking that target first if
target_defaulted is false. As the comment says this was due to
complications with archive handling which I think was fixed in
commit f832531609. It should now be possible to just check the
given target, except for linker input files. This will speed checking
the target of the first file in archives, which is done in the process
of matching archive targets.
This will no doubt expose some misuse of target options, as found in
the binutils "efi app" tests.
The stricter checking also exposed some errors. Cris targets gave
"FAIL: objcopy decompress debug sections in archive (reason: unexpected output)"
"FAIL: objcopy decompress debug sections in archive with zlib-gabi (reason: unexpected output)"
without the bfd_generic_archive_p fix. cris has a default target of
cris-aout which doesn't match objects for any of the cris-elf or
cris-linux targets. The problem here was that checking the first
object file in archives didn't match but a logic error there meant
bfd_error_wrong_object_format wasn't returned as it should be. There
was also a possibility of bfd_error_wrong_object_format persisting
from one target check to the next.
bfd/
* archive.c (bfd_generic_archive_p): Correct object in archive
target test.
* format.c (bfd_check_format_matches_lto): Try to match given
target first even when target_defaulted is set. Don't try
other targets if !target_defaulted except for linker input.
Clear bfd_error before attempted target matches.
* targets.c (bfd_find_target): Set target_defaulted for
plugin target.
binutils/
* bucomm.h (set_plugin_target): Set target_defaulted.
* testsuite/binutils-all/aarch64/pei-aarch64-little.d: Don't
wrongly specify both input and output target, just specify
output.
* testsuite/binutils-all/loongarch64/pei-loongarch64.d: Likewise.
* testsuite/binutils-all/riscv/pei-riscv64.d: Likewise.
Automatically choosing "plugin" for the archive target when plugins
are enabled can result in making archives as specified by the plugin
target vec, ie. COFF style archives (also used by most ELF
binutils targets). This is wrong for aix, hpux, vms, aout, macho
and possibly other targets, if compatibility with target system
archives matters.
This patch removes archive support entirely from the plugin target.
That means an archive will never get past bfd_check_format with a
target of plugin_vec, even if it is opened using "plugin". Instead,
archives will have their elements opened using the plugin target
selected is such a way that the plugin target will be tried first in
bfd_check_format and then continue to try other targets if that fails.
The patch tries to avoid opening archives using "plugin" because that
is guaranteed to fail the first target check in bfd_check_format, but
mm.c still does so, and nested archives will also be opened using
"plugin".
The patch also fixes poor arsup.c plugin support.
bfd/
* plugin.c (plugin_vec): Remove archive support.
* configure.ac: Remove plugin archive warning, and don't disable
plugins by default on anything but aout targets.
* configure: Regenerate.
binutils/
* bucomm.h (set_plugin_target): New inline function.
* ar.c: Remove unneeded forward declarations.
(open_inarch): Don't use "plugin" if defaulting target when
opening an archive, use "plugin" when opening elements.
(replace_members): Use "plugin" when opening replacement or
additional elements.
* arsup.c: Remove unneeded forward declarations.
(plugin_target): New.
(ar_open): Don't open archives using "plugin", use it when
opening elements.
(ar_addmod): Use plugin_target.
(ar_replace): Use plugin_target when opening replacement or
additional elements.
(ar_extract): Don't bfd_openr.
* nm.c (display_archive): Open archive elements using the
"plugin" target.
Re-indent slim LTO IR comment in
commit 9b383903e7
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Tue Aug 12 12:02:08 2025 -0700
strip: Treat slim GCC/LLVM IR objects the same
PR binutils/33271
* objcopy.c (copy_file): Re-indent slim LTO IR comment.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
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.
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 8b7fcda274
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 8b7fcda274.
Approved-By: Tom Tromey <tom@tromey.com>
The forward-search and reverse-search commands were broken by this
commit:
commit a75cd9a2c1
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 1dd5885077
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 1dd5885077, 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 1dd5885077, 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 a75cd9a2c1, 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 3fa785190a ("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.
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'.
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>
