| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When using a compiler defaulting to -std=gnu90, we run into:
...
Running gdb.server/attach-flag.exp ...
gdb compile failed, attach-flag.c: In function 'main':
attach-flag.c:22:3: error: 'for' loop initial declarations are only allowed \
in C99 or C11 mode
for (int i = 0; i < NTHREADS; i++)
^~~
attach-flag.c:22:3: note: use option -std=c99, -std=gnu99, -std=c11 or \
-std=gnu11 to compile your code
...
Fix this by using -std=gnu99.
Tested on x86_64-linux.
|
|
Test-case gdb.base/utf8-identifiers.exp compiles starting with GCC 5, so
require this.
Tested on x86_64-linux.
|
|
When running test-case gdb.multi/multi-arch.exp on powerpc64le-linux, I run into:
...
Running gdb/testsuite/gdb.multi/multi-arch.exp ...
gdb compile failed, In file included from /usr/include/features.h:399:0,
from /usr/include/stdio.h:27,
from gdb/testsuite/gdb.multi/hangout.c:18:
/usr/include/gnu/stubs.h:8:27: fatal error: gnu/stubs-32.h: \
No such file or directory
# include <gnu/stubs-32.h>
^
compilation terminated.
...
The problem is that the test-case attempts to use gcc -m32 to produce an
executable while that's not available.
Fix this by:
- introduce a new caching proc have_compile_and_link_flag, and
- using have_compile_and_link_flag in test-case gdb.multi/multi-arch.exp.
Tested on:
- x86_64-linux (openSUSE Leap 15.4), and
- powerpc64le-linux (CentOS-7).
|
|
With test-case gdb.dwarf2/dw2-abs-hi-pc.exp and tcl 8.5, I run into:
...
ERROR: tcl error sourcing gdb/testsuite/gdb.dwarf2/dw2-abs-hi-pc.exp.
ERROR: invalid command name "lmap"
while executing
"::gdb_tcl_unknown lmap i {dw2-abs-hi-pc.c dw2-abs-hi-pc-hello.c \
dw2-abs-hi-pc-world.c} { expr { "$srcdir/$subdir/$i" } }"
...
Fix this by adding basic lmap support for tcl version < 8.6.
Tested on x86_64-linux.
|
|
Test-case gdb.dwarf2/dw2-abs-hi-pc.exp uses string cat:
...
set sources [lmap i $sources { string cat "${srcdir}/${subdir}/" $i }]
...
but that's only supported starting tcl 8.6.
Fix this by using "expr" instead:
...
set sources [lmap i $sources { expr { "$srcdir/$subdir/$i" } }]
...
Tested on x86_64-linux.
|
|
|
|
This reverts commit 983db9932a302f9e2ae1f1d4fd7c3149560bc269.
|
|
opcodes/i386-dis.c: In function ‘print_insn’:
opcodes/i386-dis.c:9865:22: error: storing the address of local
variable ‘priv’ in ‘*info.private_data’ [-Werror=dangling-pointer=]
* i386-dis.c (print_insn): Clear info->private_data before
returning.
|
|
The testcase managed to trigger creation of a wild pointer in
coff_slurp_symbol_table. Stop that happening, and fix an unrelated
problem I happened to see in bfd_coff_get_syment.
* coff-bfd.c (bfd_coff_get_syment): Clear fix_value after
converting n_value from a pointer to an index.
* coffcode.h (coff_slurp_symbol_table <C_BSTAT>): Sanity check
symbol value before converting to a pointer.
|
|
This makes sure the input element bfd is closed before exiting the
loop copying elements.
* objcopy.c (copy_archive): Rename output_bfd to output_element.
Localise last_element. Close this_element in more error cases.
|
|
When running the dap tests on a system with tcl 8.5, we run into:
...
ERROR: tcl error sourcing gdb/testsuite/gdb.dap/memory.exp.
ERROR: bad class "entier": must be alnum, alpha, ascii, control, boolean, \
digit, double, false, graph, integer, list, lower, print, punct, space, \
true, upper, wideinteger, wordchar, or xdigit
while executing
"string is entier $num"
(procedure "num" line 16)
invoked from within
...
Fix this by:
- requiring tcl 8.6 in allow_dap_tests, and
- adding the missing require allow_dap_tests in gdb.dap/memory.exp.
Tested on x86_64-linux.
|
|
For quite come time print_insn() has been storing the address of a local
variable into info->private_data. Since the compiler can't know that the
field won't be accessed again after print_insn() returns, it may kind of
legitimately diagnose this. And recent enough gcc does as of the
introduction of the fetch_error() return paths (replacing setjmp()-based
error handling).
Utilizing that neither prefix_name() nor i386_dis_printf() actually use
info->private_data, zap the pointer in fetch_error(), after having
retrieved it for local use.
|
|
|
|
-mfix-looongson3-llsc may add sync instructions not needed on some
asm code with lots of debug info.
PR: 30153
* gas/config/tc-mips.c(fix_loongson3_llsc): clear logistic.
|
|
If the triple is mipsisa32r6* or mipsisa64r6*, ld/as should output
r6 objects by default.
The triples with vendor `img` should do same.
The examples include:
as xx.s -o xx.o
ld -r -b binary xx.dat -o xx.o
|
|
For MIPS64r6 ports, Debian as an example, `mipsisa64r6el` is
used as the cpu name in triple.
Let's recognize them by `mips*64*(el)`.
For 64bit Ports, like Debian's mips64el and mips64r6el ports,
`gnuabi64` is used as the abi section.
Let's use N64 abi by default for the triple with gnuabi64.
|
|
Regenerated macro_op_32.d and add skip loongarch64-*-*.
gas/ChangeLog:
* testsuite/gas/loongarch/macro_op_32.d: Regenerated.
ld/ChangeLog:
* testsuite/ld-loongarch-elf/macro_op_32.d: Regenerated.
|
|
|
|
When running the gdb.dlang test-cases, and forcing gdb_find_gdc to be used
rather than dejagnu's copy (mimicing what happens with an older dejagnu
without find_gdc), I run into these debug prints:
...
Tool Root: /data/vries/gdb/leap-15-4/build
CC: gdc
...
Remove these.
Tested on x86_64-linux.
|
|
[ Changes in v2:
- rebase on trunk
Changes in v3:
- add test-case ]
We should exclude matches to the ending PC to prevent false matches with the
next function, as prologue_end is located at the end PC.
<fun1>:
0x00: ... <-- start_pc
0x04: ...
0x08: ... <-- breakpoint
0x0c: ret
<fun2>:
0x10: ret <-- end_pc | prologue_end of fun2
Tested on x86_64-linux.
Co-Authored-By: WANG Rui <r@hev.cc> (fix, tiny change [1])
Co-Authored-By: Tom de Vries <tdevries@suse.de> (test-case)
Approved-by: Kevin Buettner <kevinb@redhat.com>
[1] https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html
PR symtab/30369
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30369
|
|
|
|
I think that the language_auto enumerator and the auto_language class
can be removed. There isn't really an "auto" language, it's only a
construct of the "set language" command to say "pick the appropriate
language automatically". But "auto" is never the current language. The
`current_language` points to the current effective language, and the
fact that we're in "auto language" mode is noted by the language_mode
global.
- Change set_language to handle the "auto" (and "local", which is a
synonym) early, instead of in the for loop. I think it makes the two
cases (auto vs explicit language) more clearly separated anyway.
- Adjust add_set_language_command to hard-code the "auto" string,
instead of using the "auto" language definition.
- Remove auto_language, rename auto_or_unknown_language to
unknown_language and move the bits of the existing unknown_language
in there.
- Remove the set_language at the end of _initialize_language. I think
it's not needed, because we call set_language in gdb_init, after all
_initialize functions are called. There is some chance that an
_initialize function that runs after _initialize_language implicitly
depends on current_language being set, but my testsuite runs haven't
found anything like that.
- Use language_unknown instead of language_auto when creating a minimal
symbol (minimal_symbol_reader::record_full). I think that this value
is used to indicate that we don't know the symbol of the minimal
symbol (yet), so language_unknown makes sense to me. Update a
condition accordingly in ada-lang.c. symbol_find_demangled_name also
appears to "normalize" this value from "unknown" to "auto", remove
that part and update the condition to just check for
language_unknown.
Change-Id: I47bcd6c15f607d9818f2e6e413053c2dc8ec5034
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
The `language` global variable is mostly a scratch variable used for the
setting. The source of truth is really current_language and
language_mode (auto vs manual), which are set by the
set_language_command callback.
Switch the setting to use the add_setshow_enum_cmd overload that takes a
value getter and setter.
Change-Id: Ief5b2f93fd7337eed7ec96023639ae3dfe62250b
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
set_language returns the previous language, but nothing uses it. Remove
the return value. This lets us remove the assignment to
current_language, in _initialize_language.
Change-Id: Ifccf9b488434c1addf4626130a74e159a37d8c17
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
Directory gdb/testsuite/boards contains a number of host/target boards, which
run a test-case (or test-cases) in a different way.
The benefits of using these boards are:
- improving test coverage of gdb,
- making the testsuite more robust, and
- making sure the test-cases work for non-native and remote setups, if
possible.
Each board is slightly different, and developers need to learn how to use each
one, what parameters to pass and how, and which ones can be used in
combination with each other. This is a threshold to start using them.
And then there quite a few, so I suppose typically only a few will be used by
each developer.
Add script gdb/testsuite/make-check-all.sh, that's intended to function as a
drop-in replacement of make check, while excercising all host/target boards in
gdb/testsuite/boards.
An example of make-check-all.sh for one test-case is:
...
$ ~/gdb/src/gdb/testsuite/make-check-all.sh gdb.base/advance.exp
LOCAL:
# of expected passes 8
TARGET BOARD: cc-with-gdb-index
# of expected passes 8
...
HOST BOARD: local-remote-host-notty, TARGET BOARD: remote-stdio-gdbserver
# of expected passes 8
HOST/TARGET BOARD: local-remote-host-native
# of expected passes 8
...
Shell-checked and tested on x86_64-linux.
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
|
|
While working on PRs tui/30337 and cli/30346 I came across various notions of
width in gdb, as reported by gdb, readline, curses and the environment
variables.
As for gdb, readline and the environment variables, the way things work
is:
- Gdb asks readline to detect screen size,
- readline sets the actual screen size in the environment variables
COLUMNS and LINES,
- readline reports back a screen size to gdb, which may have one column
less than the actual screen size, to deal with lack of auto-wrap.
This becomes gdb's notion of screen size (in other words the point where
we can expect the gdb command line to wrap),
- Gdb then explicitly sets readline's screen size, which readline itself may
adjust to deal with lack of auto-wrap. This becomes readlines notion
of screen size (well, internally the unadjusted one, but it'll report back
the adjusted one).
Add a command "maint info screen" that prints these notions, both for width
and height.
For TERM=xterm we have:
...
$ TERM=xterm gdb -ex "maint info screen"
Number of characters gdb thinks are in a line is 118.
Number of characters readline reports are in a line is 118.
Number of characters curses thinks are in a line is 118.
Number of characters environment thinks are in a line is 118 (COLUMNS).
Number of lines gdb thinks are in a page is 27.
Number of lines readline reports are in a page is 27.
Number of lines curses thinks are in a page is 27.
Number of lines environment thinks are in a page is 27 (LINES).
...
And for TERM=ansi:
...
$ TERM=ansi gdb -ex "maint info screen"
Number of characters gdb thinks are in a line is 117.
Number of characters readline reports are in a line is 116.
Number of characters curses thinks are in a line is 118.
Number of characters environment thinks are in a line is 118 (COLUMNS).
Number of lines gdb thinks are in a page is 27.
Number of lines readline reports are in a page is 27.
Number of lines curses thinks are in a page is 27.
Number of lines environment thinks are in a page is 27 (LINES).
...
[ The fact that we have "characters readline reports are in a line is 116" is
is due to gdb making readline adjust twice for the lack of auto-wrap, this is
PR cli/30346.
Likewise we can detect tui/30337 by doing a resize in TUI mode and doing
"maint info screen":
...
Number of characters characters curses thinks are in a line is 110.
Number of characters environment thinks are in a line is 111 (COLUMNS). ]
And for TERM=ansi, with width and heigth set to 0:
...
Number of characters gdb thinks are in a line is 4294967295 (unlimited).
Number of characters readline reports are in a line is 32766 (unlimited - 1).
Number of characters curses thinks are in a line is 118.
Number of characters environment thinks are in a line is 118 (COLUMNS).
Number of lines gdb thinks are in a page is 4294967295 (unlimited).
Number of lines readline reports are in a page is 32767 (unlimited).
Number of lines curses thinks are in a page is 27.
Number of lines environment thinks are in a page is 27 (LINES).
...
[ Note that when doing a resize by say maximizing or de-maximizing a terminal,
all reported values are updated, except for curses when not in TUI mode.
Maybe that means there's a bug. If not, then maybe we should not print
the curses lines unless in TUI mode, or annotate those lines such that it's
clear that the values may be not up-to-date. ]
I'd like to use this command in the regression test for PR cli/30346.
Tested on x86_64-linux.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
A recent change in opcodes/i386-dis.c caused a build failure on my
x86-64 Fedora 36 system, which uses:
$ gcc --version
gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
[...]
The error is:
../../binutils-gdb/opcodes/i386-dis.c: In function ‘OP_J’:
../../binutils-gdb/opcodes/i386-dis.c:12705:22: error: ‘val’ may be used uninitialized [-Werror=maybe-uninitialized]
12705 | disp = val & 0x8000 ? val - 0x10000 : val;
| ~~~~^~~~~~~~
This patch fixes the warning.
opcodes/ChangeLog
2023-04-21 Tom Tromey <tromey@adacore.com>
* i386-dis.c (OP_J): Check result of get16.
|
|
AdaCore has a local patch for PPC "finish", but last year, Ulrich
Weigand pointed out that this patch was incorrect. It may work for
simple functions like the one in the internal test, but nothing
guarantees that r3 will be preserved by the callee, so checking r3 on
exit is not always correct.
This patch fixes the problem using the same approach as PPC64: use the
entry value of r3, if available. Ulrich confirmed this matches the
PPC32 ABI.
|
|
On PPC64, with the test case included in an earlier patch, we found
that "finish" would still not correctly find the return value via
entry values.
The issue is simple. The compiler emits:
0x00000000100032b8 <+28>: bl 0x1000320c <pck__create_large>
0x00000000100032bc <+32>: nop
0x00000000100032c0 <+36>: li r9,42
... but the DWARF says:
<162a> DW_AT_call_return_pc: 0x100032c0
That is, the declared return PC is one instruction past the actual
return PC.
This patch adds a new arch hook to handle this scenario, and
implements it for PPC64. Some care is taken so that GDB will continue
to work if this compiler bug is fixed. A GCC patch is here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613336.html
No check for 'nop' is done, as subsequent discussion revealed that the
linker might replace this with another instruction.
|
|
call_site_target::iterate_over_addresses may look up a minimal symbol.
On platforms like PPC64 that use function descriptors, this may find
an unexpected address. The fix is to use gdbarch_convert_from_func_ptr_addr
to convert from a function descriptor to the address recorded at the
call site.
I've added a new test case that is based on the internal AdaCore test
that provoked this bug. However, I'm unable to test it as-is on
PPC64.
|
|
get64() is unreachable when !BFD64 (due to a check relatively early in
print_insn()). Let's avoid the associated #ifdef-ary (or else we should
extend it to remove more dead code).
|
|
With the longjmp() uses all gone, the setjmp() isn't necessary anymore
either.
|
|
Make them return boolean and convert FETCH_DATA() uses to fetch_code().
With this no further users of FETCH_DATA() remain, so the macro and its
backing function are dropped as well.
Leave value types as they were for the helper functions, even if I don't
think that beyond get64() use of bfd_{,signed_}vma is really necessary.
With type change of "disp" in OP_E_memory(), change the 2nd parameter of
print_displacement() to a signed type as well, though (eliminating the
need for a local variable of signed type). This also eliminates the need
for custom printing of '-' in Intel syntax displacement expressions.
While there drop forward declarations which aren't really needed.
|
|
Make the handler functions all return boolean and convert FETCH_DATA()
uses to fetch_code().
|
|
Introduce a special error indicator node, for the sole (real) caller
to recognize and act upon.
|
|
Use a tristate (enum) return value type to be able to express all three
cases which are of interest to the (sole) caller. This also allows doing
away with the abuse of "rex_used".
|
|
... and its direct helper get_sib(). Using setjmp()/longjmp() for fetch
error handling is problematic, as per
https://sourceware.org/pipermail/binutils/2023-March/126687.html. Start
using more conventional error handling instead.
Also introduce a fetch_modrm() helper, for subsequent re-use.
|
|
... such that it can be used from other than the setjmp() error handling
path.
Since I'd like the function's parameter to be pointer-to-const, two
other functions need respective constification then, too (along with
needing to be forward-declared).
|
|
A semicolon was missing and "name" needs to be pointer-to-const. While
adding "const" there, also add it for "sec".
|
|
This should be the first related issue, which posted in riscv-gnu-toolchain,
https://github.com/riscv-collab/riscv-gnu-toolchain/issues/497
If the output sections are not between gp and the symbol, then their alignments
shouldn't affect the gp relaxation. However, this patch improves this idea
even more, it limits the range to the gp+-2k, which means only the output
section which are in the [gp-2K, gp+2K) range need to be considered.
Even if the output section candidates may be different for each relax passes,
the symbol that can be relaxed ar this round will not be truncated at next
round. That is because this round you can do relaxation which means that the
section where the symbol is located is within the [gp-2K, gp+2K) range, so all
the output section alignments between them should be considered. In other
words, if the alignments between them may cause truncated, then we should
already preserve the size and won't do the gp relaxation this time.
This patch can resolve the github issue which mentioned above, and also passed
all gcc/binutils regressions of riscv-gnu-toolchain, so should be worth and
safe enough to commit.
Originally, this patch also do the same optimization for the call relaxations,
https://sourceware.org/pipermail/binutils/2022-October/123918.html
But just in case there is something that has not been considered, we only
deal with the gp relaxation at this time.
bfd/
* elfnn-riscv.c (riscv_elf_link_hash_table): Added new bfd_vma,
max_alignment_for_gp. It is used to record the maximum alignment of
the output sections, which are in the [gp-2K, gp+2k) range.
(riscv_elf_link_hash_table_create): Init max_alignment_for_gp to -1.
(_bfd_riscv_get_max_alignment): Added new parameter, gp. If gp is
zero, then all the output section alignments are possible candidates;
Otherwise, only the output sections which are in the [gp-2K, gp+2K)
range need to be considered.
(_bfd_riscv_relax_lui): Called _bfd_riscv_get_max_alignment with the
non-zero gp if the max_alignment_for_gp is -1.
(_bfd_riscv_relax_pc): Likewise.
(_bfd_riscv_relax_section): Record the first input section, so that
we can reset the max_alignment_for_gp for each repeated relax passes.
ld/
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
* testsuite/ld-riscv-elf/relax-max-align-gp.*: New testcase. It fails
without this patch.
|
|
At least older versions of one of the doc generation tools complain
(warn) about it missing.
|
|
rs6000-coff archives use a linked list of file offsets, where each
element points to the next element. The idea is to allow updating of
large archives quickly without rewriting the whole archive. (binutils
ar does not do this.) Unfortunately this is an easy target for
fuzzers to create an archive that will cause ar or any other tool
processing archives to hang. I'd implemented guards against pointing
back to the previous element, but of course that didn't last long.
So this patch implements a scheme to keep track of file offset ranges
used by elements as _bfd_read_ar_hdr is called for each element. See
the add_range function comment. I needed a place to stash the list,
so chose the obvious artdata.tdata backend extension to archive's
tdata, already used by xcoff. That involved a little cleanup, because
while it would be possible to continue using different artdata.tdata
for the big and small archives, it's nicer to use a union.
If anyone is concerned this list of element ranges might grow large
and thus significantly slow down the tools, adjacent ranges are
merged. In fact something like "ar t" will only ever have one range
on xcoff archives generated by binutils/ar. I agree there might still
be a problem with ld random element access via the armap.
include/
* coff/xcoff.h (SIZEOF_AR_FILE_HDR): Use sizeof.
(SIZEOF_AR_FILE_HDR_BIG, SIZEOF_AR_HDR, SIZEOF_AR_HDR_BIG): Likewise.
(struct ar_ranges, struct xcoff_artdata): New.
(x_artdata): Define.
(xcoff_big_format_p): Rewrite.
(xcoff_ardata, xcoff_ardata_big): Delete.
bfd/
* coff-rs6000.c: Replace uses of xcoff_ardata and
xcoff_ardata_big throughout file.
(_bfd_xcoff_archive_p): Adjust artdata.tdata allocation.
(add_range): New function.
(_bfd_xcoff_read_ar_hdr): Use it here. Fix memory leak.
(_bfd_xcoff_openr_next_archived_file): Remove old sanity
checks. Set up range for header.
(xcoff_write_archive_contents_old): Make the temporary
artdata.tdata used here to pass info down to
_bfd_compute_and_write_armap a struct xcoff_artdata.
(xcoff_write_archive_contents_big): Likewise.
* coff64-rs6000.c: Replace uses of xcoff_ardata and
xcoff_ardata_big throughout file.
(xcoff64_archive_p): Adjust artdata.tdata allocation.
|
|
This element is unused. Ideally we'd be moving archive_head and
other archive specific fields from struct bfd to here, but that's a
much larger change than this little bit of cleanup.
* libbfd-in.h (struct artdata): Delete archive_head.
* libbfd.h: Regenerate.
* archive.c,
* coff-rs6000.c,
* coff64-rs6000.c: Delete comments mentioning artdata archive_head.
|
|
|
|
security related bugs.
|
|
In commit 6967633c8b49 ("x86: convert testcases to use .insn") an ILP32
clone of a testcase was missed in the set of tests needing --divide
added.
Reported-by: Clément Chigot <chigot@adacore.com>
|
|
|
|
Segmentation fault
FAIL: pr22269-1 (static pie undefined weak)
and others running "visibility (hidden undef)" tests
No code has any right to access bfd_link_hash_entry u.def without
first checking the type, and SYMBOL_REFERENCES_LOCAL isn't sufficient.
* elf32-sh.c (sh_elf_finish_dynamic_symbol): Don't use relative
relocs in GOT unless symbol is defined.
|
|
Make ldemul_before_plugin_all_symbols_read more useful.
* ldlang.c (lang_process): Move call to
ldemul_before_plugin_all_symbols_read outside BFD_SUPPORTS_PLUGINS.
Allow backends to add to gc_sym_list before handling entry sym.
* ldelf.c (ldelf_before_plugin_all_symbols_read): Test
lto_plugin_active.
|
|
This one was caused by me unnecessarily promoting an "int adv" to
"int64_t adv". The expression overflowing was 4259 + 9223372036854775807
with the left number being unsigned int.
* dwarf.h (DWARF2_Internal_LineInfo): Replace unsigned short
with uint16_t and unsigned char with uint8_t. Make li_line_base
an int8_t.
* dwarf.c (display_debug_lines_raw): Revert "adv" back to an int.
|
