| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
There are a few spots where an mmap system call is mapped onto enum
gdb_syscall value gdb_sys_mmap2.
Strictly speaking, this is incorrect.
Fix this by mapping to enum gdb_syscall value gdb_old_mmap instead.
No functional changes: both gdb_old_mmap and gdb_sys_mmap2 are handled the
same in record_linux_system_call.
Tested by rebuilding on x86_64-linux.
|
|
With the selftest register_name, we run into a few warning:
...
$ gdb -q -batch -ex "maint selftest register_name" 2>&1 \
| grep -B1 warning:
Running selftest register_name::m68hc11.
warning: No frame soft register found in the symbol table.
--
Running selftest register_name::m68hc12.
warning: No frame soft register found in the symbol table.
--
Running selftest register_name::m68hc12:HCS12.
warning: No frame soft register found in the symbol table.
...
We already filter out these architectures in other selftests because of the
same warning.
Do the same in this selftest.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
|
|
I think there is a problem with the disable_breakpoints_in_shlibs
function: it can disable breakpoint locations without calling
notify_breakpoint_modified. This means that the Python API's
breakpoint_modified event will not trigger, nor will the MI send a
breakpoint modified event.
I started looking at disable_breakpoints_in_shlibs because of an
earlier commit:
commit 8c48ec7a6160aed0d1126c623443935e4435cd41
Date: Thu Aug 29 12:34:15 2024 +0100
gdb: handle dprintf breakpoints when unloading a shared library
Currently disable_breakpoints_in_shlibs is only called from one
location, clear_solib in solib.c. clear_solib also calls
notify_solib_unloaded for every solib in the program_space of
interest, and notify_solib_unloaded will call
disable_breakpoints_in_unloaded_shlib via the solib_unloaded
observer. These two function, disable_breakpoints_in_shlibs and
disable_breakpoints_in_unloaded_shlib are very similar in what they
do.
I think that we can remove the disable_breakpoints_in_shlibs call, and
instead, tweak how we call disable_breakpoints_in_unloaded_shlib in
order to get the same end result, except that, after this change, we
will call notify_breakpoint_modified, which means the Python API event
will trigger, and the MI events will be emitted.
All that disable_breakpoints_in_shlibs does is disable some
breakpoints.
Meanwhile, disable_breakpoints_in_unloaded_shlib, will disable the
same set of breakpoints, call notify_breakpoint_modified, and
then (for some breakpoint types) print a message telling the user that
the breakpoint has been disabled. However, this function will ignore
any breakpoints that are already disabled.
As disable_breakpoints_in_shlibs disables the same set of breakpoints,
the result of the current code is that disable_breakpoints_in_shlibs
serves only to prevent the notify_breakpoint_modified call, which I
think is wrong, and to prevent the user message being printed, which I
think is reasonable.
If we remove the disable_breakpoints_in_shlibs call without making any
additional changes, then we start to see some message printed in cases
like this:
(gdb) start
The program being debugged has been started already.
Start it from the beginning? (y or n) y
warning: Temporarily disabling breakpoints for unloaded shared library "/tmp/shared-lib-test/libfoo.so"
Temporary breakpoint 3 at 0x40113e: file test.c, line 9.
Starting program: /tmp/shared-lib-test/test.x
Notice the 'warning:' line, which is new. I think this is confusing
because, in most cases the breakpoint will be enabled again by the
time the inferior reaches `main` and stops.
In the future I'm interested in exploring if GDB could be smarter
about when to print these 'Temporarily disabling breakpoints ...'
messages so that if the 'start' command does mean a breakpoint is left
disabled, then the user would be informed. However, I don't propose
doing that work immediately, and certainly not in this commit. For
now, my intention is to leave things as they are right now, GDB
doesn't warn about disabling breakpoints during an inferior re-start.
To achieve this I think we need to pass a new argument to
disable_breakpoints_in_unloaded_shlib which controls whether we should
print a message about the breakpoint being disabled or not. With this
added we can now silence the warning when the inferior is
restarted (i.e. when disable_breakpoints_in_unloaded_shlib is called
from clear_solib), but keep the warning for cases like stepping over a
dlclose() call in the inferior.
After this commit, GDB now emits breakpoint modified events (in Python
and/or MI) when a breakpoint is disabled as a result of all shared
libraries being unloaded. This will be visible in two places that I
can thing of, the 'nosharedlibrary' command, and when an inferior is
restarted.
|
|
Instruction templates with only sign-extended 8-bit immediate operand
also have a second template with full-operand-size immediate operand
under a different opcode. Add {noimm8s} pseudo prefix to exclude
templates with only sign-extended 8-bit immediate operand.
gas/
PR gas/32811
* config/tc-i386.c (pseudo_prefixes): Add no_imm8s.
(operand_size_match): Return false for templates with only sign-
extended 8-bit immediate operand if {noimm8s} is used.
(parse_insn): Handle Prefix_NoImm8s.
* doc/c-i386.texi: Document {noimm8s}.
* testsuite/gas/i386/pseudos.s: Add tests for {noimm8s}.
* testsuite/gas/i386/x86-64-pseudos.s: Likewise.
* testsuite/gas/i386/pseudos.d: Updated.
* testsuite/gas/i386/x86-64-pseudos.d: Likewise.
opcodes/
PR gas/32811
* opcodes/i386-opc.h (Prefix_NoImm8s): New.
* i386-opc.tbl: Add {noimm8s} pseudo prefix.
* i386-mnem.h: Regenerated.
* i386-tbl.h: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
Always compile gprof testsuite with -g for line number info checked by
tst-gmon-gprof-l.sh.
PR gprof/32779
* testsuite/Makefile.am (GPROF_FLAGS): Add -g.
(COMPILE): Set to "$(CC) $(AM_CFLAGS) $(GPROF_FLAGS)".
(LINK) Set to "$(CC) $(AM_CFLAGS) $(GPROF_FLAGS) $(AM_LDFLAGS)
$(LDFLAGS) -o $@".
* testsuite/Makefile.in: Regenerated.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
|
|
Consider this backtrace within GDB:
#0 notify_breakpoint_modified (b=0x57d31d0) at ../../src/gdb/breakpoint.c:1083
#1 0x00000000005b6406 in breakpoint_set_commands (b=0x57d31d0, commands=...) at ../../src/gdb/breakpoint.c:1523
#2 0x00000000005c8c63 in update_dprintf_command_list (b=0x57d31d0) at ../../src/gdb/breakpoint.c:8641
#3 0x00000000005d3c4e in dprintf_breakpoint::re_set (this=0x57d31d0) at ../../src/gdb/breakpoint.c:12476
#4 0x00000000005d6347 in breakpoint_re_set () at ../../src/gdb/breakpoint.c:13298
Whenever breakpoint_re_set is called we re-build the commands that the
dprintf b/p will execute and store these into the breakpoint. The
commands are re-built in update_dprintf_command_list and stored into
the breakpoint object in breakpoint_set_commands.
Now sometimes these commands can change, dprintf_breakpoint::re_set
explains one case where this can occur, and I'm sure there must be
others. But in most cases the commands we recalculate will not
change. This means that the breakpoint modified event which is
emitted from breakpoint_set_commands is redundant.
This commit aims to eliminate the redundant breakpoint modified events
for dprintf breakpoints. This is done by adding a commands_equal call
to the start of breakpoint_set_commands.
The commands_equal function is a new function which compares two
command_line objects and returns true if they are identical. Using
this function we can check if the new commands passed to
breakpoint_set_commands are identical to the breakpoint's existing
commands. If the new commands are equal then we don't need to change
anything on the new breakpoint, and the breakpoint modified event can
be skipped.
The test for this commit stops at a dlopen() call in the inferior,
sets up a dprintf breakpoint, then uses 'next' to step over the
dlopen() call. When the library loads GDB call breakpoint_re_set,
which calls dprintf_breakpoint::re_set. But in this case we don't
expect the calculated command string to change, so we don't expect to
see the breakpoint modified event.
|
|
With commit fb2ded33c1e519659743047ed7817166545b6d91, I added
Fedora's gstack script to gdb. Some issues have arisen since
then, and this patch addresses those issues:
. As Sam James recently noted[1], PKGVERSION and VERSION
need to be quoted.
. A Fedora user reported the misuse of --readnever, which
causes gstack to omit filename and line number information in the
backtrace[Red Hat BZ 2354997].
[1] https://inbox.sourceware.org/gdb-patches/d19d6bc17e0a160ce27fc572079f11a587c0e168.1742424869.git.sam@gentoo.org/
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2354997
|
|
Some distributions configure GCC with --enable-default-pie, so that it
defaults to compile with -fPIE and link with -pie, which is unexpected
by some of the tests. Therefore link the PDE test programs with
$NOPIE_LDFLAGS to disable PIE.
This complements commit a7eaf017f959 ("Use NOPIE_CFLAGS and
NOPIE_LDFLAGS to disable PIE").
ld/testsuite/
PR ld/21090
* ld-x86-64/x86-64.exp (undefined_weak): Use NOPIE_LDFLAGS to
disable PIE for the non-PIE versions of the test.
Bug: https://sourceware.org/PR21090
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
|
|
Some distributions configure GCC with --enable-default-pie, so that it
defaults to compile with -fPIE and link with -pie, which is unexpected
by the test. Therefore compile the non-PIC sources with $NOPIE_CFLAGS
and link the test programs with $NOPIE_LDFLAGS.
Commit 922109c71828 ("Pass $NOPIE_CFLAGS to ELF visibility tests") added
$NOPIE_CFLAGS when compiling sh1np.o and sh2np.o. It missed to add it
to mainnp.o.
ld/testsuite/
PR ld/21090
* ld-vsb/vsb.exp (visibility_test): Add support for optional
ldflags argument and use it when linking the test program.
(mainnp.o): Compile with $NOPIE_CFLAGS.
(vnp, vp, vmpnp, vmpp): Link with $NOPIE_LDFLAGS.
Fixes: 922109c71828 ("Pass $NOPIE_CFLAGS to ELF visibility tests")
Bug: https://sourceware.org/PR21090
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
|
|
Some distributions configure GCC with --enable-default-pie, so that it
defaults to compile with -fPIE and link with -pie, which is unexpected
by the test. Therefore compile the non-PIC sources with $NOPIE_CFLAGS
and link the test programs with $NOPIE_LDFLAGS.
Commit 9d1c54ed7f3a ("Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to more ELF
tests") added $NOPIE_CFLAGS when compiling sh1np.o. It missed to add it
to sh2np.o and mainnp.o.
ld/testsuite/
PR ld/21090
* ld-shared/shared.exp (shared_test): Add support for optional
ldflags argument and use it when linking the test program.
(sh2np.o, mainnp.o): Compile with $NOPIE_CFLAGS.
(shnp, shp, shmpnp, shmpp): Link with $NOPIE_LDFLAGS.
Fixes: 9d1c54ed7f3a ("Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to more ELF tests")
Bug: https://sourceware.org/PR21090
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
|
|
Linker test "pr21964-4" fails on s390x on Ubuntu 24.10 but not on
Fedora 41. The reason is that GCC on Ubuntu is configured with
--enable-default-pie, so that it defaults to compile with -fPIE
and link with -pie, which causes the test to erroneously fail.
ld/testsuite/
PR ld/21090
* ld-elf/shared.exp: Compile pr21964-4 with $NOPIE_CFLAGS and
link with $NOPIE_LDFLAGS.
Bug: https://sourceware.org/PR21090
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
|
|
Linker test "pr19719 fun defined" (non PIE) fails on s390x on Fedora 41
but not on Ubuntu 24.10. The reason is that GCC on Ubuntu is configured
with --enable-default-pie, so that it defaults to compile with -fPIE
and link with -pie, which hides the test fail.
ld/testsuite/
PR ld/21090
* ld-elf/shared.exp: Compile pr19719 (non-PIE) with
$NOPIE_CFLAGS and link with $NOPIE_LDFLAGS.
Bug: https://sourceware.org/PR21090
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
|
|
The privileged spec 1.9.1 support was removed since binutils 2.43. The
linker only recognizes it and then reports a warning that it may
conflict with other spec versions.
While the support is removed, binutils should still recognize it, but it
shouldn't be exposed to the user in `disassember-options` help.
Signed-off-by: Marek Pikuła <m.pikula@partner.samsung.com>
|
|
Up to this point, no mention of RISC-V-specific disassembler options was
mentioned in binutils documentation. This patch includes description for
all of the currently supported options.
Signed-off-by: Marek Pikuła <m.pikula@partner.samsung.com>
|
|
|
|
Modifying inline-frame-cycle-unwind.exp to use `bt -no-filters` produces
the following incorrect backtrace:
#0 inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:49
#1 normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32
#2 0x000055555555517f in inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:50
#3 normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1
The expected output, which we get with `bt`, is:
#0 inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:49
#1 normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) PASS: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1
The cycle checking in `get_prev_frame_maybe_check_cycle` relies on newer
frame ids having already been computed and stashed. Unlike other
frames, frame #0's id does not get computed immediately.
The test passes with `bt` because when applying python frame filters,
the call to `bootstrap_python_frame_filters` happens to compute the id
of frame #0. When `get_prev_frame_maybe_check_cycle` later tries to
stash frame #2's id, the cycle is detected.
The test fails with `bt -no-filters` because frame #0's id has not been
stashed by the time `get_prev_frame_maybe_check_cycle` tries to stash
frame #2's id which succeeds and the cycle is only detected later when
trying to stash frame #4's id. Doing `stepi` after the incorrect
backtrace would then trigger an assertion failure when trying to stash
frame #0's id because it is a duplicate of #2's already stashed id.
In `get_prev_frame_always_1`, if this_frame is inline frame 0, then
compute and stash its frame id before returning the previous frame.
This ensures that the id of inline frame 0 has been stashed before
`get_prev_frame_maybe_check_cycle` is called on older frames.
The test case has been updated to run both `bt` and `bt -no-filters`.
Co-authored-by: Andrew Burgess <aburgess@redhat.com>
|
|
Tom Tromey mentioned [1] that the words "invokable" and "useable"
present in codespell-ignore-words.txt should be dropped.
Do so and fix the following typos:
...
$ codespell --config gdbsupport/setup.cfg gdbsupport
gdbsupport/common-debug.h:218: invokable ==> invocable
gdbsupport/event-loop.cc:84: useable ==> usable
...
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://sourceware.org/pipermail/gdb-patches/2025-March/216584.html
|
|
Ignore the following codespell detection:
...
$ codespell --config gdbserver/setup.cfg gdbserver
gdbserver/linux-aarch64-low.cc:827: SME ==> SAME, SEME, SOME, SMS
...
by adding SME to codespell-ignore-words.txt.
|
|
Fix a typo:
...
$ codespell --config gdbserver/setup.cfg gdbserver/tracepoint.cc
gdbserver/tracepoint.cc:951: mistakingly ==> mistakenly
...
|
|
Ignore the following codespell detections:
...
$ codespell --config gdbsupport/setup.cfg gdbsupport
gdbsupport/gdb_tilde_expand.cc:54: pathc ==> patch
gdbsupport/gdb_tilde_expand.cc:99: pathc ==> patch
...
by adding codespell:ignore comments.
|
|
Fix a typo:
...
$ codespell --config gdbsupport/setup.cfg gdbsupport/common-debug.h
gdbsupport/common-debug.h:109: re-used ==> reused
...
|
|
Use GDB/MI command "-complete" to implement.
Co-authored-by: Simon Farre <simon.farre.cx@gmail.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31140
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
In OBS (Open Build Service), with a 15.2 based gdb package, occasionally I run
into:
...
(gdb) inferior 2
[Switching to inferior 2 [process 31372] (access-mem-running-thread-exit)]
[Switching to thread 2.1 (Thread 0xf7db9700 (LWP 31372))](running)
(gdb) print global_var = 555
$1 = 555
(gdb) print global_var
$2 = 556
(gdb) FAIL: $exp: all-stop: access mem \
(print global_var after writing, inf=2, iter=1)
...
I managed to reproduce this on current trunk using a reproducer patch (posted
in the PR).
The problem is due to commit 31c21e2c13d ("[gdb/testsuite] Fix
gdb.threads/access-mem-running-thread-exit.exp with clang"), which introduced
an increment of global_var at the start of main.
This created a race between:
- gdb modifying global_var, and
- the inferior modifying global_var.
Fix this by:
- adding a new empty function setup_done,
- adding a call to setup_done after the increment of global_var, and
- rather than running to main, running to setup_done.
Tested on x86_64-linux.
PR testsuite/32822
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32822
|
|
Since we will support 512 bit on both P-core and E-core for AVX10, 256 bit
rounding is not that useful because we currently have rounding feature
directly on E-core now and no need to use 256-bit rounding as somehow
a workaround. This patch will remove all the support and backport to
Binutils 2.44.
gas/ChangeLog:
* NEWS: Mention support removal.
* config/tc-i386.c (build_evex_prefix): Remove U bit encode.
(check_VecOperands): Remove ymm check for rounding.
(s_insn): Revise .insn comment.
* testsuite/gas/i386/avx10_2-256-cvt-intel.d: Remove ymm
rounding related test.
* testsuite/gas/i386/avx10_2-256-cvt.d: Ditto.
* testsuite/gas/i386/avx10_2-256-cvt.s: Ditto.
* testsuite/gas/i386/avx10_2-256-miscs-intel.d: Ditto.
* testsuite/gas/i386/avx10_2-256-miscs.d: Ditto.
* testsuite/gas/i386/avx10_2-256-miscs.s: Ditto.
* testsuite/gas/i386/avx10_2-256-satcvt-intel.d: Ditto.
* testsuite/gas/i386/avx10_2-256-satcvt.d: Ditto.
* testsuite/gas/i386/avx10_2-256-satcvt.s: Ditto.
* testsuite/gas/i386/evex.d: Ditto.
* testsuite/gas/i386/evex.s: Ditto.
* testsuite/gas/i386/i386.exp: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-cvt-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-cvt.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-cvt.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-miscs-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-miscs.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-miscs.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-satcvt-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-satcvt.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-satcvt.s: Ditto.
* testsuite/gas/i386/x86-64-evex.d: Ditto.
* testsuite/gas/i386/x86-64.exp: Ditto.
* testsuite/gas/i386/avx10_2-rounding-intel.d: Removed.
* testsuite/gas/i386/avx10_2-rounding-inval.l: Removed.
* testsuite/gas/i386/avx10_2-rounding-inval.s: Removed.
* testsuite/gas/i386/avx10_2-rounding.d: Removed.
* testsuite/gas/i386/avx10_2-rounding.s: Removed.
* testsuite/gas/i386/x86-64-avx10_2-rounding-intel.d: Removed.
* testsuite/gas/i386/x86-64-avx10_2-rounding.d: Removed.
* testsuite/gas/i386/x86-64-avx10_2-rounding.s: Removed.
opcodes/ChangeLog:
* i386-dis.c (struct instr_info): Remove U bit.
(get_valid_dis386): Roll back to APX condition.
* i386-opc.tbl: Remove ymm rounding support.
* i386-tbl.h: Regenerated.
|
|
|
|
In the AIX systems available for testing in the gcc compile farm, the
default debug information format is stabs. This is a problem for many
reasons, mainly that stabs is not as complete as dwarf and stabs is
being deprecated in the next release. In the current state, we have:
PASS: 39798
FAIL: 7405
When running these tests, I unfortunately didn't have the foresight to
save the number of unsupported and untested cases.
To improve testing there, this patch changes the gdb_compile TCL proc, so
that if we're running tests in AIX, we requested debug info, and we
haven't explicitly asked for some debuginfo format, gdb_compile will add
-gdwarf to the compilation line, forcing DWARF to be used. After this
patch, we get:
PASS: 74548
FAIL: 5963
So not only do we have fewer failures, there are tens of thousands of
tests that are no longer skipped.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The suffix "defined/undefined" in the ld test pr19719 name specifies
whether weak fun() is defined or undefined is mixed up.
The test builds an executable and a shared library. The latter in two
flavors, one with weak fun() defined (libpr19719a.so, "defined") and
one without weak fun() defined (libpr19719b.so, "undefined").
The first "Run $exe fun [...]" invocation uses libpr19719b.so as
libpr19719.so, which is build from dummy.c, which does not define fun.
Thus fun is undefined during this test run.
The second "Run $exe fun [...]" invocation uses libpr19719a.so as
libpr19719.so, which is build from pr19719d.c, which does define fun.
Thus fun is defined during this test run.
Correct the test naming mix-up accordingly.
ld/testsuite/
* ld-elf/shared.exp (mix_pic_and_non_pic): Correct test naming
mix-up of when weak fun is un-/defined.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
|
|
GDB's compile subsystem is deeply tied to GDB's ability to understand
DWARF. A future patch will add the option to disable DWARF at configure
time, but for that to work, the compile subsystem will need to be
entirely disabled as well, so this patch adds that possibility.
I also think there is motive for a security conscious user to disable
compile for it's own sake. Considering that the code is quite
unmaintained, and depends on an equally unmaintained gcc plugin, there
is a case to be made that this is an unnecessary increase in the attack
surface if a user knows they won't use the subsystem. Additionally, this
can make compilation slightly faster and the final binary is around 3Mb
smaller. But these are all secondary to the main goal of being able to
disable dwarf at configure time.
To be able to achieve optional compilation, some of the code that
interfaces with compile had to be changed. All parts that directly
called compile things have been wrapped by ifdefs checking for compile
support. The file compile/compile.c has been setup in a similar way to
how python's and guile's main file has been setup, still being compiled
but only for with placeholder command.
Finally, to avoid several new errors, a new TCL proc was introduced to
gdb.exp, allow_compile_tests, which checks if the "compile" command is
recognized before the inferior is started and otherwise skips the compile
tests. All tests in the gdb.compile subfolder have been updated to use
that, and the test gdb.base/filename-completion also uses this. The proc
skip_compile_feature_tests to recognize when the subsystem has been
disabled at compile time.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The following patch will add a configure option to disable the compile
subsystem at compilation time. To do that, nearly all code that
interfaces with compile should be confined to the compile sub-folder.
This commit is the first step, removing the compile-related method from
the language struct and adding 2 new functions to compile.c that do the
same job in a slightly different way. Adding things to the language
struct is a more extendable way to add support for languages, but
considering compile is quite bit-rotted and questionably supported, I
don't think it will be extended any time soon, and using ifdefs to
handle disabling compile with configure felt like a messier solution.
There should be no visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Change some parameters to be references instead of pointers, when the
value must not be nullptr. I'd like to do this more of this kind of
change, but I have to limit the scope of the change, otherwise there's
just no end (and some local variables could also be turned into
references). So for now, just do it the cutu_reader constructors.
Change-Id: I9442c6043726981d58f9b141f516c590c0a71bcc
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The comment on this constructor is really outdated. Update it to better
reflect the reality today.
I'd eventually like to change this cutu_reader constructor not to use
dwarf2_per_cu, because it seems like an abuse of dwarf2_per_cu just to
pass 3 values. But for now, just document the existing behavior.
Change-Id: Id96db020c361e64d9b0d2f25d51950b206658aa2
Approved-By: Tom Tromey <tom@tromey.com>
|
|
lookup_dwo_unit receives the name of the DWO unit to look up, as read
from the DW_AT_dwo_name attribute of the skeleton DIE. But then, it
doesn't use it:
/* Yeah, we look dwo_name up again, but it simplifies the code. */
dwo_name = dwarf2_dwo_name (comp_unit_die, cu);
Perhaps this comment made sense at some point, but with the code we have
today, I don't understand it. It should be fine to use the name passed
as a parameter, which the caller also obtained by calling
dwarf2_dwo_name.
Change-Id: I84723e12726f77e4202d042428ee0eed9962ceb8
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Turns out the return value of parse_loongarch_dis_option acts as an
error code, and previously the function always signified failure with
a non-zero return value, making only the first disassembly option get
to take effect.
Fix by adding the missing `return 0`'s to the two success code paths.
Signed-off-by: WANG Xuerui <git@xen0n.name>
|
|
Other *-elf targets set COMMONPAGESIZE in emulparams/*.sh and so
enable `-z relro` and related features. Make aarch64-elf match.
There is no reason to think that a "generic ELF" target should
have any particular set of features disabled.
|
|
Add instruction `mnret' support
Ref:
https://github.com/riscv/riscv-isa-manual/blob/bb8b9127f81965eeff2d150c211d1c89376591c4/src/rnmi.adoc
https://github.com/riscv/riscv-opcodes/blob/946eb673874b3a0f2474d1424dc28bc7ee53c306/extensions/rv_smrnmi
bfd/ChangeLog:
* elfxx-riscv.c: Add new Smrnmi instruction class handling
gas/ChangeLog:
* testsuite/gas/riscv/smrnmi.s: New test for mnret
* testsuite/gas/riscv/rmrnmi.d: Likewise
include/ChangeLog:
* opcode/ricsv-opc.h: Add MATCH_MNRET, MASK_MNRET
* opcode/riscv.h: Add new instruction class
opcodes/ChangeLog:
* riscv-opc.c: Add `mnret' instruction
Signed-off-by: Jerry Zhang Jian <jerry.zhangjian@sifive.com>
|
|
|
|
Looking at `cooked_index_shard::find`, I thought that we could make a
small optimization: when finding the upper bound, we already know the
lower bound. And we know that the upper bound is >= the lower bound.
So we could pass `lower` as the first argument of the `std::upper_bound`
call to cut the part of the search space that is below `lower`.
It then occured to me that what we do is basically what
`std::equal_range` is for, so why not use it. Implementations of
`std::equal_range` are likely do to things as efficiently as possible.
Unfortunately, because `cooked_index_entry::compare` is sensitive to the
order of its parameters, we need to provide two different comparison
functions (just like we do know, to the lower_bound and upper_bound
calls). But I think that the use of equal_range makes it clear what the
intent of the code is.
Regression tested using the various DWARF target boards on Debian 12.
Change-Id: Idfad812fb9abae1b942d81ad9976aeed7c2cf762
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I believe that the `(mode == MATCH && a == munge ('<'))` part of the
condition is unnecesary. Or perhaps I don't understand the algorithm.
The use of "munge" above effectively makes it so that the template
portion of names is completely ignored for the sake of the comparison.
Then, in the condition, this:
a == munge ('<')
is functionally equivalent to
a == '\0'
If `a` is indeed '\0', and `b` is also '\0', then we would have taken
the earlier branch:
if (a == b)
return 0;
If `b` is not '\0', then we won't take this branch and we'll go into the
final comparison:
return a < b ? -1 : 1;
So, as far as I can see, there is no case where `mode == MATCH`, where
we're going to use this special `return 0`.
Regression tested using the various DWARF target boards on Debian 12.
Change-Id: I5ea0463c1fdbbc1b003de2f0a423fd0073cc9dec
Approved-By: Tom Tromey <tom@tromey.com>
|
|
|
|
|
|
We have this pattern of check in multiple places:
/* Skip dummy compilation units. */
if (m_info_ptr >= begin_info_ptr + this_cu->length ()
|| peek_abbrev_code (abfd, m_info_ptr) == 0)
m_dummy_p = true;
In all places except one (read_cutu_die_from_dwo), this is done after
reading the unit header but before potentially reading the first DIE.
The effect is that we consider dummy units that have no DIE at all.
Either the "data" portion of the unit (the portion after the header) has
a size of zero, or the first abbrev code is 0, i.e. "end of list".
According to this old commit I found [1], dummy CUs were used as filler
for incremental LTO linking. A comment reads:
WARNING: If THIS_CU is a "dummy CU" (used as filler by the incremental
linker) then DIE_READER_FUNC will not get called.
In read_cutu_die_from_dwo, however, this check is done after having read
the first DIE. So at the time of the check, m_info_ptr has already been
advanced just past the first DIE. As a result, compilations units with
a single DIE are considered (erroneously, IMO) as dummy.
In commit aab6de1613df ("gdb/dwarf: fix spurious error when encountering
dummy CU") [2], I mentioned a real world case where compilation units
with a single top-level DIE were being considered dummy. I believe that
those units should not actually have been treated as dummy. A CU with
just one DIE may not be very interesting, but I don't see any reason to
consider it dummy.
Move the dummy check above the read_toplevel_die call, and return early
if the CU is dummy.
I am 99% convinced that it's not even possible to encounter an empty
unit here, and considered turning it into an assert (it did pass the
testsuite). This function is passed a dwo_unit, and functions that
create a dwo_unit are:
- create_debug_type_hash_table (creates a dwo_unit for each type unit
found in a dwo file)
- create_cus_hash_table (creates a dwo_unit for each comp unit found in
a dwo file)
- create_dwo_unit_in_dwp_v1
- create_dwo_unit_in_dwp_v2
- create_dwo_unit_in_dwp_v5
In the first two, there are already dummy checks, so we wouldn't even
get to read_cutu_die_from_dwo for such an empty CU. However, in the
last three, there is no such checks, we just trust the dwp file's index
and create dwo_units out of that. So I guess it would be possible to
craft a broken dwp file with a CU that has no DIE. Out of caution, I
didn't switch that to an assert, but I also don't really know what would
be the mode of failure if that were to happen.
Regtested using the various DWARF target boards on Debian 12.
[1] https://gitlab.com/gnutools/binutils-gdb/-/commit/dee91e82ae87f379c90fddff8db7c4b54a116609#dd409f60ba6f9c066432dafbda7093ac5eec76d1_3434_3419
[2] https://gitlab.com/gnutools/binutils-gdb/-/commit/aab6de1613df693059a6a2b505cc8f20d479d109
Change-Id: I90e6fa205cb2d23ebebeae6ae7806461596f9ace
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This parameter is always used to set cutu_reader::m_dwo_abbrev_table.
Remove the parameter, and have read_cutu_die_from_dwo set the field
directly.
Change-Id: I6c0c7d23591fb2c3d28cdea1befa4e6b379fd0d3
Approved-By: Tom Tromey <tom@tromey.com>
|
|
FEAT_MEC support was introduced in [1]. However, the dc instruction was
missing these encodings:
- DC CIPAE
- DC CIGDPAE
Furthermore, the Arm ARM states that FEAT_MEC is an optional extension,
introduced for v9.2-a.
Therefore, these sysregs:
- MECIDR_EL2
- MECID_P0_EL2
- MECID_A0_EL2
- MECID_P1_EL2
- MECID_A1_EL2
- VMECID_P_EL2
- VMECID_A_EL2
- MECID_RL_A_EL3
which were introduced in that commit now require -march=armv9.2-a at the very
least to be enabled, as well as the dc encodings.
opcodes/ChangeLog:
* aarch64-opc.c (aarch64_sys_regs_dc): Add "cipae" and "cigdpae".
* aarch64-sys-regs.def: Add V8_7A as a requirement for the above system
registers.
gas/testsuite/gas/ChangeLog
* aarch64/mec-invalid.s: Add .arch directive.
* aarch64/mec.d: Add .arch directive and check for cipae, cigdpae.
* aarch64/mec.s: Add MEC data cache operations test.
* aarch64/mec-arch-bad.d: New test to check for bad arch version.
* aarch64/mec-arch-bad.l: Above.
[1]: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=31f2faf5cf112931cfb8c0564a2b78477c907fe3
Regression tested on aarch64-none-elf
|
|
bfd_canonicalize_symtab stores the symbols in the BFD, and returns
pointers to these. The ELF reader does not reuse these stored
symbols, so each call to bfd_canonicalize_symtab causes an allocation.
This interacts poorly with code like arm_pikeos_osabi_sniffer, which
searches the BFD symbol when called.
PR gdb/32758 points out a particularly pathological case: using "maint
info sections" on a program with a large number of sections (10000)
will cause 10000 calls to arm_pikeos_osabi_sniffer, allocating 20G.
I'm not sure BFD always worked this way. And, fixing BFD was an
option. However it seemed maybe better for GDB to adapt, since
adapting would mean that the fix would apply to all BFD back ends, and
not just ELF.
To that end, this patch adds a new gdb_bfd_canonicalize_symtab and
changes all callers of bfd_canonicalize_symtab to use it instead.
This new function caches the result in the per-BFD object.
I looked into having this return a view of "const asymbol *". However
both the compile module and machoread modify the returned symbols.
And while I think this is wrong, I haven't tried to fix this here.
Regression tested on x86-64 Fedora 40.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32758
|
|
Commit 3aaca06b672 ("gdb: fix color_option_def compile error (clang)")
fixed a compilation error in color_option_def when building with
clang. It seemed to me that it would be good to add a compile test
for this code.
|
|
|
|
|
|
|
