Tom Tromey [Mon, 18 Apr 2022 18:56:41 +0000 (12:56 -0600)]
Import gnulib changes
This imports the gnulib patches that were mentioned by Eli. I created
the patches from gnulib git, ran them through filterdiff, and then
applied them using update-gnulib.sh's patch-applying facility.
I think the patches are either obviously Windows-specific or harmless,
but I encourage you to look for yourself.
I tested by rebuilding on x86-64 Fedora 34, and also using the Fedora
mingw cross toolchain.
gdb/gdbsupport: make xstrprintf and xstrvprintf return a unique_ptr
Before this commit the behaviour was:
(gdb) show remote X-packet
Support for the `X' packet is auto-detected, currently unknown.
The problem was caused by a failed attempt to ensure that some
allocated strings were deleted when GDB exits. The code in the above
commit attempted to make use of 'static' to solve this problem,
however, the solution was just wrong.
In this new commit I instead allocate a static vector into which all
the allocated strings are stored, this ensures the strings are
released when GDB exits (which makes output from tools like valgrind
cleaner), but each string within the vector can be unique, which fixes
the regression.
Fix this by testing whether 16llf is supported by doing ptype long_long_float
which gets us either:
...
type = <16-byte float>^M
...
or:
...
type = <12-byte float>^M
...
Tom de Vries [Fri, 15 Apr 2022 14:54:21 +0000 (16:54 +0200)]
[gdb/testsuite] Fix gdb.go/methods.exp with check-readmore
When running test-case gdb.go/methods.exp with make check we have:
...
(gdb) break main.T.Foo^M
Function "main.T.Foo" not defined.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) XFAIL: gdb.go/methods.exp: gdb_breakpoint: set breakpoint at main.T.Foo
...
but with make check-readmore the XFAIL fails to trigger:
...
(gdb) break main.T.Foo^M
Function "main.T.Foo" not defined.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.go/methods.exp: gdb_breakpoint: set breakpoint at main.T.Foo
...
This happens because this gdb_test_multiple "maintenance print symbols"
regexp:
...
-re "\r\n$gdb_prompt $" {
...
matches the entire command output.
Fix this by adding the missing ^ at the regexp start.
Lancelot SIX [Thu, 14 Apr 2022 17:21:04 +0000 (18:21 +0100)]
gdb/testsuite: Fix race in gdb.dwarf2/calling-convention.exp
Pedro Alves warned me that there is a race in
gdb.dwarf2/calling-convention.exp making the test sometimes fail on his
setup. This can be reliably reproduced using :
make check-read1 TESTS="gdb.dwarf2/calling-convention.exp"
The relevant part of the gdb.log file is:
return 35
Function 'foo' does not follow the target calling convention.
If you continue, setting the return value will probably lead to unpredictable behaviors.
Make foo return now? (y or n) PASS: gdb.dwarf2/calling-convention.exp: return 35
n
Not confirmed
(gdb) FAIL: gdb.dwarf2/calling-convention.exp: finish
The issue is that when doing the test for "return 35", the DejaGnu test
sends "n" (to tell GDB not to perform the return action) but never
consumes the "Not confirmed" acknowledgment sent by GDB. Later, when
trying to do the next test, DejaGnu tries to match the leftover output
from the "return" test. As this output is not expected, the test fails.
Fix by using gdb_test to send the "n" answer and match the confirmation
and consume all output to the prompt.
Also do minor adjustments to the main regex:
- Remove the leading ".*" which is not required.
- Ensure that the "?" from the question is properly escaped.
Tested on x86_64-gnu-linux, using
- make check TESTS="gdb.dwarf2/calling-convention.exp"
- make check-read1 TESTS="gdb.dwarf2/calling-convention.exp"
- make check-readmore TESTS="gdb.dwarf2/calling-convention.exp"
Co-authored-by: Pedro Alves <pedro@palves.net>
Change-Id: I42858b13db2cbd623c5c1739de65ad423e0c0938
Tom Tromey [Thu, 7 Apr 2022 16:17:02 +0000 (10:17 -0600)]
Silence -Wmaybe-uninitialized warning from target_waitstatus
Currently, one use of target_waitstatus yields a warning:
target/waitstatus.h: In function 'void stop_all_threads()':
target/waitstatus.h:175:13: warning: 'ws.target_waitstatus::m_value' may be used uninitialized in this function [-Wmaybe-uninitialized]
175 | m_value = other.m_value;
| ~~~~~~~~^~~~~~~~~~~~~~~
This patch silences the warning. I tried the "volatile member"
approach that was used for gdb::optional, but that didn't work, so
this patch simply initializes the member.
Tom Tromey [Thu, 31 Mar 2022 13:55:09 +0000 (07:55 -0600)]
Fix regression on Windows with WOW64
Internally at AdaCore, we recently started testing a 64-bit gdb
debugging 32-bit processes. This failed with gdb head, but not with
gdb 11.
The tests fail like this:
Starting program: [...].exe
warning: Could not load shared library symbols for WOW64_IMAGE_SECTION.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for WOW64_IMAGE_SECTION.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need "set solib-search-path" or "set sysroot"?
After some debugging and bisecting, to my surprise the bug was
introduced by commit 183be222 ("gdb, gdbserver: make target_waitstatus
safe").
The problem occurs in handle_exception. Previously the code did:
However, in the new code, the fallthrough case does:
+ ourstatus->set_stopped (GDB_SIGNAL_TRAP);
... which changes the 'kind' in 'ourstatus' after falling through.
This patch rearranges the 'last_sig' setting to more closely match
what was done before (this is probably not strictly needed but also
seemed harmless), and removes the fall-through in the
'ignore_first_breakpoint' case when __x86_64__ is defined.
Tom de Vries [Thu, 14 Apr 2022 12:56:21 +0000 (14:56 +0200)]
[gdb/testsuite] Fix gdb.base/annota1.exp with pie
Since commit 359efc2d894 ("[gdb/testsuite] Make gdb.base/annota1.exp more
robust") we see this fail with target board unix/-fPIE/-pie:
...
FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)
...
The problem is that the commit makes the number and order of matched
annotations fixed, while between target boards unix and unix/-fPIE/-pie there
is a difference:
...
\032\032post-prompt
Starting program: outputs/gdb.base/annota1/annota1
+\032\032breakpoints-invalid
+
\032\032starting
\032\032frames-invalid
...
Fix this by optionally matching the additional annotation.
Tom de Vries [Thu, 14 Apr 2022 12:56:21 +0000 (14:56 +0200)]
[gdb/testsuite] Make gdb.base/annota1.exp more robust
On openSUSE Tumbleweed I run into:
...
FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)
...
The problem is that the libthread_db message occurs at a location where it's
not expected:
...
Starting program: outputs/gdb.base/annota1/annota1 ^M
^M
^Z^Zstarting^M
^M
^Z^Zframes-invalid^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
^M
^Z^Zbreakpoints-invalid^M
^M
...
Fix this by making the matching more robust:
- rewrite the regexp such that each annotation is on a single line,
starting with \r\n\032\032 and ending with \r\n
- add a regexp variable optional_re, that matches all possible optional
output, and use it as a separator in the first part of the regexp
Tom de Vries [Thu, 14 Apr 2022 11:52:19 +0000 (13:52 +0200)]
[gdb/testsuite] Fix gdb.base/stap-probe.exp with read1
When running test-case gdb.base/stap-probe.exp with make target check-read1, I
run into this and similar:
...
FAIL: gdb.base/stap-probe.exp: without semaphore, not optimized: \
info probes stap (timeout)
...
Fix this by using gdb_test_lines instead of gdb_test.
Tom de Vries [Thu, 14 Apr 2022 11:17:24 +0000 (13:17 +0200)]
[gdb/testsuite] Detect 'No MPX support'
On openSUSE Leap 15.3, mpx support has been disabled for m32, so I run into:
...
(gdb) run ^M
Starting program: outputs/gdb.arch/i386-mpx/i386-mpx ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
No MPX support^M
...
and eventually into all sort of fails in this and other mpx test-cases.
Fix this by detecting the "No MPX support" message in have_mpx.
Tested on x86_64-linux with target boards unix and unix/-m32.
Tom de Vries [Wed, 13 Apr 2022 12:29:00 +0000 (14:29 +0200)]
[gdb/testsuite] Fix gdb.dwarf2/dw2-lines.exp for m32 pie
As reported in PR29043, when running test-case gdb.dwarf2/dw2-lines.exp with
target board unix/-m32/-fPIE/-pie, we run into:
...
Breakpoint 2, 0x56555540 in bar ()^M
(gdb) PASS: gdb.dwarf2/dw2-lines.exp: cv=2: cdw=32: lv=2: ldw=32: \
continue to breakpoint: foo \(1\)
next^M
Single stepping until exit from function bar,^M
which has no line number information.^M
0x56555587 in main ()^M
(gdb) FAIL: gdb.dwarf2/dw2-lines.exp: cv=2: cdw=32: lv=2: ldw=32: \
next to foo (2)
...
The problem is that the bar breakpoint ends up at an unexpected location
because:
- the synthetic debug info is incomplete and doesn't provide line info
for the prologue part of the function, so consequently gdb uses the i386
port prologue skipper to get past the prologue
- the i386 port prologue skipper doesn't get past a get_pc_thunk call.
Work around this in the test-case by breaking on bar_label instead.
Tested on x86_64-linux with target boards unix, unix/-m32, unix/-fPIE/-pie and
unix/-m32/-fPIE/-pie.
Simon Marchi [Wed, 13 Apr 2022 12:29:00 +0000 (14:29 +0200)]
gdb/testsuite: use nopie in gdb.dwarf2/dw2-inline-param.exp
I see this failure:
(gdb) run ^M
Starting program: /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-inline-param/dw2-inline-param ^M
Warning:^M
Cannot insert breakpoint 1.^M
Cannot access memory at address 0x113b^M
^M
(gdb) FAIL: gdb.dwarf2/dw2-inline-param.exp: runto: run to *0x113b
The test loads the binary in GDB, grabs the address of a symbol, strips
the binary, reloads it in GDB, runs the program, and then tries to place
a breakpoint at that address. The problem is that the binary is built
as position independent, so the address GDB grabs in the first place
isn't where the code ends up after running.
Fix this by linking the binary as non-position-independent. The
alternative would be to compute the relocated address where to place the
breakpoint, but that's not very straightforward, unfortunately.
I was confused for a while, I was trying to load the binary in GDB
manually to get the symbol address, but GDB was telling me the symbol
could not be found. Meanwhile, it clearly worked in gdb.log. The thing
is that GDB strips the binary in-place, so we don't have access to the
intermediary binary with symbols. Change the test to output the
stripped binary to a separate file instead.
Tom Tromey [Fri, 8 Apr 2022 16:11:58 +0000 (10:11 -0600)]
Fix bug in Ada number lexing
On irc, Pedro pointed out that Ada couldn't properly handle
0xffffffffffffffff. This used to work, but is a regression due to
some patches I wrote in the Ada lexer. This patch fixes the bug.
However, it turns out I somehow neglected to send part of the patch.
Internally, I also removed the "Ada Settings" node from the manual, as
it only documents the obsolete setting.
John Baldwin [Mon, 4 Apr 2022 22:08:15 +0000 (15:08 -0700)]
Handle TLS variable lookups when using separate debug files.
Commit df22c1e5d53c38f38bce6072bb46de240f9e0e2b handled the case that
a separate debug file was passed as the objfile for a shared library
to svr4_fetch_objfile_link_map. However, a separate debug file can
also be passed for TLS variables in the main executable. In addition,
frv_fetch_objfile_link_map also expects to be passed the original
objfile rather than a separate debug file, so pull the code to resolve
a separate debug file to the main objfile up into
target_translate_tls_address.
Simon Marchi [Mon, 4 Apr 2022 21:45:59 +0000 (17:45 -0400)]
gdb: don't copy entirely optimized out values in value_copy
Bug 28980 shows that trying to value_copy an entirely optimized out
value causes an internal error. The original bug report involves MI and
some Python pretty printer, and is quite difficult to reproduce, but
another easy way to reproduce (that is believed to be equivalent) was
proposed:
This is caused by 5f8ab46bc691 ("gdb: constify parameter of
value_copy"). It added an assertion that the contents buffer is
allocated if the value is not lazy:
if (!value_lazy (val))
{
gdb_assert (arg->contents != nullptr);
This was based on the comment on value::contents, which suggest that
this is the case:
/* Actual contents of the value. Target byte-order. NULL or not
valid if lazy is nonzero. */
gdb::unique_xmalloc_ptr<gdb_byte> contents;
However, it turns out that it can also be nullptr also if the value is
entirely optimized out, for example on exit of
allocate_optimized_out_value. That function creates a lazy value, marks
the entire value as optimized out, and then clears the lazy flag. But
contents remains nullptr.
This wasn't a problem for value_copy before, because it was calling
value_contents_all_raw on the input value, which caused contents to be
allocated before doing the copy. This means that the input value to
value_copy did not have its contents allocated on entry, but had it
allocated on exit. The result value had it allocated on exit. And that
we copied bytes for an entirely optimized out value (i.e. meaningless
bytes).
From here I see two choices:
1. respect the documented invariant that contents is nullptr only and
only if the value is lazy, which means making
allocate_optimized_out_value allocate contents
2. extend the cases where contents can be nullptr to also include
values that are entirely optimized out (note that you could still
have some entirely optimized out values that do have contents
allocated, it depends on how they were created) and adjust
value_copy accordingly
Choice #1 is safe, but less efficient: it's not very useful to allocate
a buffer for an entirely optimized out value. It's even a bit less
efficient than what we had initially, because values coming out of
allocate_optimized_out_value would now always get their contents
allocated.
Choice #2 would be more efficient than what we had before: giving an
optimized out value without allocated contents to value_copy would
result in an optimized out value without allocated contents (and the
input value would still be without allocated contents on exit). But
it's more risky, since it's difficult to ensure that all users of the
contents (through the various_contents* accessors) are all fine with
that new invariant.
In this patch, I opt for choice #2, since I think it is a better
direction than choice #1. #1 would be a pessimization, and if we go
this way, I doubt that it will ever be revisited, it will just stay that
way forever.
Add a selftest to test this. I initially started to write it as a
Python test (since the reproducer is in Python), but a selftest is more
straightforward.
The problem is that the test expects the following regexp:
".*#0 0x.*"
And that typically works, when the output of the frame command looks
like:
#0 0x00005555555551bb in child_sub_function () at ...
Note the lack of hexadecimal address in the failing case. Whether or
not the hexadecimal address is printed (roughly) depends on whether the
current PC is at the beginning of a line. So depending on where thread
2 was when GDB stopped it (after thread 1 hit its breakpoint), we can
get either output. Adjust the regexps to not expect an hexadecimal
prefix (0x) but a function name instead (either child_sub_function or
child_function). That one is always printed, and is also a good check
that we are in the frame we expect.
Note that for test "frame 5", we are showing a pthread frame (on my
system), so the function name is internal to pthread, not something we
can rely on. In that case, it's almost certain that we are not at the
beginning of a line, or that we don't have debug info, so I think it's
fine to expect the hex prefix.
And for test "frame 6", it's ok to _not_ expect a hex prefix (what the
test currently does), since we are showing thread 1, which has hit a
breakpoint placed at the beginning of a line.
When testing this, Tom de Vries pointed out that the current test code
doesn't ensure that the child threads are in child_sub_function when
they are stopped. If the scheduler chooses so, it is possible for the
child threads to be still in the pthread_barrier_wait or child_function
functions when they get stopped. So that would be another racy failure
waiting to happen.
The only way I can think of to ensure the child threads are in the
child_sub_function function when they get stopped is to synchronize the
threads using some variables instead of pthread_barrier_wait. So,
replace the barrier with an array of flags (one per child thread). Each
child thread flips its flag in child_sub_function to allow the main
thread to make progress and eventually hit the breakpoint.
I copied user-selected-context-sync.c to a new mi-cmd-user-context.c and
made modifications to that, to avoid interfering with
user-selected-context-sync.exp.
Rainer Orth [Thu, 31 Mar 2022 08:38:01 +0000 (10:38 +0200)]
Fix procfs.c compilation
procfs.c doesn't compile on Solaris:
/vol/src/gnu/gdb/hg/master/local/gdb/procfs.c: In member function ‘virtual bool procfs_target::info_proc(const char*, info_proc_what)’:
/vol/src/gnu/gdb/hg/master/local/gdb/procfs.c:3302:3: error: ‘gdb_argv’ was not declared in this scope
3302 | gdb_argv built_argv (args);
| ^~~~~~~~
/vol/src/gnu/gdb/hg/master/local/gdb/procfs.c:3303:20: error: ‘built_argv’ was not declared in this scope; did you mean ‘buildargv’?
3303 | for (char *arg : built_argv)
| ^~~~~~~~~~
| buildargv
Fixed by including "gdbsupport/buildargv.h".
Tested on amd64-pc-solaris2.11, sparcv9-sun-solaris2.11.
gdb/mi: consistently notify user when GDB/MI client uses -thread-select
Changes were made to GDB to address some inconsistencies in when
notifications are sent from a MI terminal to a CLI terminal (when
multiple terminals are in use, see new-ui command).
Unfortunately, in order to track when the currently selected frame has
changed, that commit grabs a frame_info pointer before and after an MI
command has executed, and compares the pointers to see if the frame
has changed.
This is not safe.
If the frame cache is deleted for any reason then the frame_info
pointer captured before the command started, is no longer valid, and
any comparisons based on that pointer are undefined.
This was leading to random test failures for some folk, see:
This commit changes GDB so we no longer hold frame_info pointers, but
instead store the frame_id and frame_level, this is safe even when the
frame cache is flushed.
Tom Tromey [Fri, 18 Mar 2022 04:36:12 +0000 (22:36 -0600)]
Add Rust parser check for end of expression
I noticed that "print 5," passed in Rust -- the parser wasn't checking
that the entire input was used. This patch fixes the problem. This
in turn pointed out another bug in the parser, namely that it didn't
lex the next token after handling a string token. This is also fixed
here.
liuzhensong [Sun, 13 Mar 2022 08:56:33 +0000 (16:56 +0800)]
ld:LoongArch: Add test cases to adapt to LoongArch32 and LoongArch64
ld/testsuite/ld-loongarch-elf
* ld-loongarch-elf.exp: Test LoongArch32 and LoongArch64 testcases respectively.
* jmp_op.d: Fix bug in test LoongArch32.
* disas-jirl-32.d: New test case for LoongArch32.
* disas-jirl-32.s: New test case for LoongArch32.
* disas-jirl.d: Skip test case LoongArch32.
* macro_op_32.d: New test case for LoongArch32.
* macro_op_32.s: New test case for LoongArch32.
* macro_op.d: Skip test case LoongArch32.
liuzhensong [Sun, 20 Mar 2022 01:19:55 +0000 (09:19 +0800)]
gas:LoongArch: Fix wrong line number in .debug_line
The dwarf2_emit_insn() can create debuginfo of line. But it is called
too late in append_fixp_and_insn. It causes extra offs when debuginfo
of line sets address.
Simon Marchi [Fri, 18 Mar 2022 19:55:26 +0000 (15:55 -0400)]
gdb/python: remove gdb._mi_commands dict
The motivation for this patch is the fact that py-micmd.c doesn't build
with Python 2, due to PyDict_GetItemWithError being a Python 3-only
function:
CXX python/py-micmd.o
/home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function ‘int micmdpy_uninstall_command(micmdpy_object*)’:
/home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: ‘PyDict_GetItemWithError’ was not declared in this scope; did you mean ‘PyDict_GetItemString’?
430 | PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (),
| ^~~~~~~~~~~~~~~~~~~~~~~
| PyDict_GetItemString
A first solution to fix this would be to try to replace
PyDict_GetItemWithError equivalent Python 2 code. But I looked at why
we are doing this in the first place: it is to maintain the
`gdb._mi_commands` Python dictionary that we use as a `name ->
gdb.MICommand object` map. Since the `gdb._mi_commands` dictionary is
never actually used in Python, it seems like a lot of trouble to use a
Python object for this.
My first idea was to replace it with a C++ map
(std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>). While
implementing this, I realized we don't really need this map at all. The
mi_command_py objects registered in the main MI command table can own
their backing micmdpy_object (that's a gdb.MICommand, but seen from the
C++ code). To know whether an mi_command is an mi_command_py, we can
use a dynamic cast. Since there's one less data structure to maintain,
there are less chances of messing things up.
- Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is
now what keeps the MICommand alive.
- Set micmdpy_object::mi_command in the constructor of mi_command_py.
If mi_command_py manages setting/clearing that field in
swap_python_object, I think it makes sense that it also takes care of
setting it initially.
- Move a bunch of checks from micmdpy_install_command to
swap_python_object, and make them gdb_asserts.
- In micmdpy_install_command, start by doing an mi_cmd_lookup. This is
needed to know whether there's a Python MI command already registered
with that name. But we can already tell if there's a non-Python
command registered with that name. Return an error if that happens,
rather than waiting for insert_mi_cmd_entry to fail. Change the
error message to "name is already in use" rather than "may already be
in use", since it's more precise.
I asked Andrew about the original intent of using a Python dictionary
object to hold the command objects. The reason was to make sure the
objects get destroyed when the Python runtime gets finalized, not later.
Holding the objects in global C++ data structures and not doing anything
more means that the held Python objects will be decref'd after the
Python interpreter has been finalized. That's not desirable. I tried
it and it indeed segfaults.
Handle this by adding a gdbpy_finalize_micommands function called in
finalize_python. This is the mirror of gdbpy_initialize_micommands
called in do_start_initialization. In there, delete all Python MI
commands. I think it makes sense to do it this way: if it was somehow
possible to unload Python support from GDB in the middle of a session
we'd want to unregister any Python MI command. Otherwise, these MI
commands would be backed with a stale PyObject or simply nothing.
Delete tests that were related to `gdb._mi_commands`.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3
Pedro Alves [Fri, 18 Mar 2022 19:14:25 +0000 (19:14 +0000)]
Fix crash with stepi, no debug info, and "set debug infrun 1"
A stepi in a function without debug info with "set debug infrun 1"
crashes GDB since commit c8353d682f69 (gdb/infrun: some extra infrun
debug print statements), due to a reference to
"tp->current_symtab->filename" when tp->current_symtab is null.
This commit adds the missing null check. The output in this case
becomes:
Tom Tromey [Mon, 7 Mar 2022 21:06:09 +0000 (14:06 -0700)]
Implement gdbarch_stack_frame_destroyed_p for aarch64
The internal AdaCore testsuite has a test that checks that an
out-of-scope watchpoint is deleted. This fails on some aarch64
configurations, reporting an extra stop:
(gdb) continue
Continuing.
Thread 3 hit Watchpoint 2: result
Old value = 64
New value = 0
0x0000000040021648 in pck.get_val (seed=0, off_by_one=false) at [...]/pck.adb:13
13 end Get_Val;
I believe what is happening here is that the variable is stored at:
and the extra stop is reported just before a return, when the ldp
instruction is executed:
0x0000000040021644 <+204>: ldp x29, x30, [sp], #48
0x0000000040021648 <+208>: ret
This instruction modifies the frame base calculation, and so the test
picks up whatever memory is pointed to in the callee frame.
Implementing the gdbarch hook gdbarch_stack_frame_destroyed_p fixes
this problem.
As usual with this sort of patch, it has passed internal testing, but
I don't have a good way to try it with dejagnu. So, I don't know
whether some existing test covers this. I suspect there must be one,
but it's also worth noting that this test passes for aarch64 in some
configurations -- I don't know what causes one to fail and another to
succeed.
Jan Beulich [Fri, 18 Mar 2022 09:55:45 +0000 (10:55 +0100)]
x86: also fold remaining multi-vector-size shift insns
By slightly relaxing the checking in operand_type_register_match() we
can fold the vector shift insns with an XMM source as well. While
strictly speaking an overlap in just one size (see the code comment) is
not enough (both operands could have multiple sizes with just a single
common one), this is good enough for all templates we have, or which
could sensibly / usefully appear (within the scope of the present
operand matching model).
Tightening this a little would be possible, but would require broadcast
related information to be passed into the function.
Tsukasa OI [Tue, 11 Jan 2022 10:14:02 +0000 (19:14 +0900)]
RISC-V: Prefetch hint instructions and operand set
This commit adds 'Zicbop' hint instructions.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): Add handling for
new instruction class.
gas/ChangeLog:
* config/tc-riscv.c (riscv_ip): Add handling for new operand
type 'f' (32-byte aligned pseudo S-type immediate for prefetch
hints).
(validate_riscv_insn): Likewise.
include/ChangeLog:
* opcode/riscv-opc.h (MATCH_PREFETCH_I, MASK_PREFETCH_I,
MATCH_PREFETCH_R, MASK_PREFETCH_R, MATCH_PREFETCH_W,
MASK_PREFETCH_W): New macros.
* opcode/riscv.h (enum riscv_insn_class): Add new instruction
class INSN_CLASS_ZICBOP.
opcodes/ChangeLog:
* riscv-dis.c (print_insn_args): Add handling for new operand
type.
* riscv-opc.c (riscv_opcodes): Add prefetch hint instructions.
H.J. Lu [Mon, 14 Mar 2022 22:38:04 +0000 (15:38 -0700)]
gprofng: Skip jsynprog with a broken javac
On CET enabled Linux/x86-64 machines, one can get
$ javac simple.java
Error: dl failure on line 894
Error: failed /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.322.b06-6.fc35.x86_64/jre/lib/amd64/server/libjvm.so, because /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.322.b06-6.fc35.x86_64/jre/lib/amd64/server/libjvm.so: rebuild shared object with SHSTK support enabled
Set GPROFNG_BROKEN_JAVAC to "yes" only with a broken javac and skip the
jsynprog test with a broken javac.
PR gprofng/28965
* Makefile.am (GPROFNG_BROKEN_JAVAC): New.
(check-DEJAGNU): Pass GPROFNG_BROKEN_JAVAC to runtest.
* configure.ac (GPROFNG_BROKEN_JAVAC): New AC_SUBST. Set to yes
with a broken javac.
* Makefile.in: Regenerate.
* configure: Likewise.
* testsuite/gprofng.display/display.exp: Skip jsynprog with a
broken javac.
John Baldwin [Thu, 17 Mar 2022 16:37:24 +0000 (09:37 -0700)]
Remove fall throughs in core_target::xfer_partial.
The cases for TARGET_OBJECT_LIBRARIES and TARGET_OBJECT_LIBRARIES_AIX
can try to fetch different data objects (such as
TARGET_OBJECT_SIGNAL_INFO) if gdbarch methods for the requested data
aren't present. Return with TARGET_XFER_E_IO if the gdbarch method
isn't present instead.
Pedro Alves [Wed, 16 Mar 2022 13:39:17 +0000 (13:39 +0000)]
gdb: Remove support for S+core
GCC removed support for score back in 2014 already. Back then, we
basically agreed about removing it from GDB too, but it ended up being
forgotten. See:
Tom Tromey [Wed, 16 Mar 2022 15:50:17 +0000 (09:50 -0600)]
Add another test for Ada Wide_Wide_String
In an earlier patch, I had written that I wanted to add this test:
ptype Wide_Wide_String'("literal")
... but that it failed with the distro GNAT. Further investigation
showed that it could be made to work by adding a function using
Wide_Wide_String to the program -- this caused the type to end up in
the debug info.
Alan Modra [Thu, 17 Mar 2022 04:10:23 +0000 (14:40 +1030)]
gprofng configure target tests
${target} in configure.ac should be the canonical target, so that for
example, someone configuring with --target=x86_64-linux will match
x86_64-*-linux*.
Alan Modra [Thu, 17 Mar 2022 01:24:40 +0000 (11:54 +1030)]
asan: buffer overflows after calling ignore_rest_of_line
operand() is not a place that should be calling ignore_rest_of_line.
ignore_rest_of_line shouldn't increment input_line_pointer if already
at buffer limit.
* expr.c (operand): Don't call ignore_rest_of_line.
* read.c (s_mri_common): Likewise.
(ignore_rest_of_line): Don't increment input_line_pointer if
already at buffer_limit.
Jan Beulich [Thu, 17 Mar 2022 10:05:56 +0000 (11:05 +0100)]
x86: don't accept base architectures as extensions
The -march= intentions are quite clear: A base architecture may be
followed by any number of extensions. Accepting a base architecture in
place of an extension will at best result in confusion, as the first of
the two (or more) items specified simply would not take effect, due to
being overridden by the later one(s).
Jan Beulich [Thu, 17 Mar 2022 10:05:11 +0000 (11:05 +0100)]
x86: never set i386_cpu_flags' "unused" field
Setting this field risks cpu_flags_all_zero() mistakenly returning
"false" when the object passed in was e.g. the result of ANDing together
two objects which had the bit set, or ANDNing together an object with
the field set and one with the field clear.
While there also avoid setting CpuNo64: Like Cpu64 this is driven
differently anyway and hence shouldn't be set anywhere by default.
Note that the moving of the two items in i386-gen.c's cpu_flags[] is
only for documentation purposes (and slight reducing of overhead), as
the fields are sorted anyway upon program start.
Jan Beulich [Thu, 17 Mar 2022 10:04:41 +0000 (11:04 +0100)]
x86: unify CPU flag on/off processing
There's no need for the arbitrary special "unknown" token: Simply
recognize the leading ~ and process everything else the same, merely
recording whether to set individual fields to 1 or 0.
While there exclude CpuIAMCU from CPU_UNKNOWN_FLAGS - CPU_IAMCU_FLAGS
override cpu_arch_flags anyway when -march=iamcu is passed, and there's
no reason to have the stray flag set even if no insn actually is keyed
to it.
projects / thirdparty / binutils-gdb.git / log
