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.
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.
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:
https://sourceware.org/pipermail/gdb/2014-October/044643.html
Following through this time around.
Change-Id: I5b25a1ff7bce7b150d6f90f4c34047fae4b1f8b4
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.
This patch adds the test. I'm checking this in.
With "name" a char*, the length at name[0] might be negative, escaping
buffer limit checks.
* vms-alpha.c (evax_bfd_print_dst): Make name an unsigned char*.
(evax_bfd_print_emh): Likewise.
${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*.
* configure.ac: Invoke AC_CANONICAL_TARGET.
* libcollector/configure.ac: Likewise.
* Makefile.in: Regenerate.
* configure: Regenerate.
* doc/Makefile.in: Regenerate.
* gp-display-html/Makefile.in: Regenerate.
* libcollector/Makefile.in: Regenerate.
* libcollector/configure: Regenerate.
* src/Makefile.in: Regenerate.
In the process of fixing a buffer overflow in commit fe69d4fcf0,
I managed to introduce a fairly obvious NULL pointer dereference..
* peXXigen.c (_bfd_XX_bfd_copy_private_bfd_data_common): Don't
segfault on not finding section. Wrap overlong lines.
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.
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).
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.
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.
Now that {L,K}1OM support is gone, and with it the brokenness in
check_cpu_arch_compatible(), put in place a test making sure that only
extensions can be enabled via .arch for IAMCU, and that the base
architecture cannot be changed.
The checks done by check_cpu_arch_compatible() were halfway sensible
only at the time where only L1OM support was there. The purpose,
however, has always been to prevent bad uses of .arch (turning off the
base CPU "feature" flag) while at the same time permitting extensions to
be enabled / disabled. In order to achieve this (and to prevent
regressions when L1OM and K1OM support are removed)
- set CpuIAMCU in CPU_IAMCU_FLAGS,
- adjust the IAMCU check in the function itself (the other two similarly
broken checks aren't adjusted as they're slated to be removed anyway),
- avoid calling the function for extentions (which would never have the
base "feature" flag set),
- add a new testcase actually exercising ".arch iamcu" (which would also
regress with the planned removal).
In this commit:
commit b4f26d541a
Date: Tue Mar 2 13:42:37 2021 -0700
Import GNU Readline 8.1
We imported readline 8.1 into GDB. As a consequence bug PR cli/28833
was reported. This bug spotted that, when the user terminated GDB by
sending EOF (usually bound to Ctrl+d), the last prompt would become
corrupted. Here's what happens, the user is sat at a prompt like
this:
(gdb)
And then the user sends EOF (Ctrl+d), we now see this:
quit)
... gdb terminates, and we return to the shell ...
Notice the 'quit' was printed over the prompt.
This problem is a result of readline 8.1 enabling bracketed paste mode
by default. This problem is present in readline 8.0 too, but in that
version of readline bracketed paste mode is off by default, so a user
will not see the bug unless they specifically enable the feature.
Bracketed paste mode is available in readline 7.0 too, but the bug
is not present in this version of readline, see below for why.
What causes this problem is how readline disables bracketed paste
mode. Bracketed paste mode is a terminal feature that is enabled and
disabled by readline emitting a specific escape sequence. The problem
for GDB is that the escape sequence to disable bracketed paste mode
includes a '\r' character at the end, see this thread for more
details:
https://lists.gnu.org/archive/html/bug-bash/2018-01/msg00097.html
The change to add the '\r' character to the escape sequence used to
disable bracketed paste mode was introduced between readline 7.0 and
readline 8.0, this is why the bug would not occur when using older
versions of readline (note: I don't know if its even possible to build
GDB using readline 7.0. That really isn't important, I'm just
documenting the history of this issue).
So, the escape sequence to disable bracketed paste mode is emitted
from the readline function rl_deprep_terminal, this is called after
the user has entered a complete command and pressed return, or, if the
user sends EOF.
However, these two cases are slightly different. In the first case,
when the user has entered a command and pressed return, the cursor
will have moved to the next, empty, line, before readline emits the
escape sequence to leave bracketed paste mode. The final '\r'
character moves the cursor back to the beginning of this empty line,
which is harmless.
For the EOF case though, this is not what happens. Instead, the
escape sequence to leave bracketed paste mode is emitted on the same
line as the prompt. The final '\r' moves the cursor back to the start
of the prompt line. This leaves us ready to override the prompt.
It is worth noting, that this is not the intended behaviour of
readline, in rl_deprep_terminal, readline should emit a '\n' character
when EOF is seen. However, due to a bug in readline this does not
happen (the _rl_eof_found flag is never set). This is the first
readline bug that effects GDB.
GDB prints the 'quit' message from command_line_handler (in
event-top.c), this function is called (indirectly) from readline to
process the complete command line, but also in the EOF case (in which
case the command line is set to nullptr). As this is part of the
callback to process a complete command, this is called after readline
has disabled bracketed paste mode (by calling rl_deprep_terminal).
And so, when bracketed paste mode is in use, rl_deprep_terminal leaves
the cursor at the start of the prompt line (in the EOF case), and
command_line_handler then prints 'quit', which overwrites the prompt.
The solution to this problem is to print the 'quit' message earlier,
before rl_deprep_terminal is called. This is easy to do by using the
rl_deprep_term_function hook. It is this hook that usually calls
rl_deprep_terminal, however, if we replace this with a new function,
we can print the 'quit' string, and then call rl_deprep_terminal
ourselves. This allows the 'quit' to be printed before
rl_deprep_terminal is called.
The problem here is that there is no way in rl_deprep_terminal to know
if readline is processing EOF or not, and as a result, we don't know
when we should print 'quit'. This is the second readline bug that
effects GDB.
Both of these readline issues are discussed in this thread:
https://lists.gnu.org/archive/html/bug-readline/2022-02/msg00021.html
The result of that thread was that readline was patched to address
both of these issues.
Now it should be easy to backport the readline fix to GDB's in tree
copy of readline, and then change GDB to make use of these fixes to
correctly print the 'quit' string.
However, we are just about to branch GDB 12, and there is concern from
some that changing readline this close to a new release is a risky
idea, see this thread:
https://sourceware.org/pipermail/gdb-patches/2022-March/186391.html
So, this commit doesn't change readline at all. Instead, this commit
is the smallest possible GDB change in order to avoid the prompt
corruption.
In this commit I change GDB to print the 'quit' string on the line
after the prompt, but only when bracketed paste mode is on. This
avoids the overwriting issue, the user sees this:
(gdb)
quit
... gdb terminates, and returns to the shell ...
This isn't ideal, but is better than the existing behaviour. After
GDB 12 has branched, we can backport the readline fix, and apply a
real fix to GDB.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833
This started as a patch to implement string concatenation for Ada.
However, while working on this, I looked at how this code could
possibly be called. It turns out there are only two users of
concat_operation: Ada and D. So, in addition to implementing this for
Ada, this patch rewrites value_concat, removing the odd "concatenate
or repeat" semantics, which were completely unused. As Ada and D both
seem to represent strings using TYPE_CODE_ARRAY, this removes the
TYPE_CODE_STRING code from there as well.
eval_op_concat has code to search for an operator overload of
BINOP_CONCAT. However, the operator overloading code is specific to
C++, which does not have this operator. And,
binop_types_user_defined_p rejects this case right at the start, and
value_x_binop does not handle this case. I think this code has been
dead for a very long time. This patch removes it and hoists the
remaining call into concatenation::evaluate, removing eval_op_concat
entirely.
This adds some basic support for Wide_String and Wide_Wide_String to
the Ada expression evaluator. In particular, a string literal may be
converted to a wide or wide-wide string depending on context.
The patch updates an existing test case. Note that another test,
namely something like:
ptype Wide_Wide_String'("literal")
... would be nice to add, but when tested against a distro GNAT, this
did not work (probably due to lack of debuginfo); so, I haven't
included it here.
eval_op_string is only used in a single place -- the implementation of
string_operation. This patch turns it into the
string_operation::evaluate method, removing a bit of extraneous code.
The last two tests in gdb.base/ending-run.exp case fail on Powerpc when the
system does not have the needed glibc debug-info files loaded. In this
case, gdb is not able to determine where execution stopped. This behavior
looks as follows for the test case:
The next to the last test does a next command when the program is stopped
at the closing bracket for main. The message printed is:
0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6
which fails to match any of the test_multiple options.
The test then does another next command. On Powerpc, the
message printed it:
Cannot find bounds of current function
The test fails as the output does not match any of the options for the
gdb_test_multiple.
I checked the behavior on Powerpc to see if this is typical.
I ran gdb on the following simple program as shown below.
#include <stdio.h>
int
main(void)
{
printf("Hello, world!\n");
return 0;
}
gdb ./hello_world
<snip the gdb start info>
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./hello_world...
(No debugging symbols found in ./hello_world)
(gdb) break main
Breakpoint 1 at 0x818
(gdb) r
Starting program: /home/carll/hello_world
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1".
Breakpoint 1, 0x0000000100000818 in main ()
(gdb) n
Single stepping until exit from function main,
which has no line number information.
Hello, world!
0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6
(gdb) n
Cannot find bounds of current function
So it would seem that the messages seen from the test case are
"normal" output for Powerpc when the debug-info is not available.
The following patch adds the output from Powerpc as an option
to the gdb_test_multiple statement, identifying the output as the expected
output on Powerpc without the needed debug-info files installed.
The patch has been tested on a Power 10 system and an Intel
64-bit system. No additional regression failures were seen on
either platform.
GDB notifies users about user selected thread changes somewhat
inconsistently as mentioned on gdb-patches mailing list here:
https://sourceware.org/pipermail/gdb-patches/2022-February/185989.html
Consider GDB debugging a multi-threaded inferior with both CLI and GDB/MI
interfaces connected to separate terminals.
Assuming inferior is stopped and thread 1 is selected, when a thread
2 is selected using '-thread-select 2' command on GDB/MI terminal:
-thread-select 2
^done,new-thread-id="2",frame={level="0",addr="0x00005555555551cd",func="child_sub_function",args=[],file="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",fullname="/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c",line="30",arch="i386:x86-64"}
(gdb)
and on CLI terminal we get the notification (as expected):
[Switching to thread 2 (Thread 0x7ffff7daa640 (LWP 389659))]
#0 child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30
30 volatile int dummy = 0;
However, now that thread 2 is selected, if thread 1 is selected
using 'thread-select --thread 1 1' command on GDB/MI terminal
terminal:
-thread-select --thread 1 1
^done,new-thread-id="1",frame={level="0",addr="0x0000555555555294",func="main",args=[],file="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",fullname="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",line="66",arch="i386:x86-64"}
(gdb)
but no notification is printed on CLI terminal, despite the fact
that user selected thread has changed.
The problem is that when `-thread-select --thread 1 1` is executed
then thread is switched to thread 1 before mi_cmd_thread_select () is
called, therefore the condition "inferior_ptid != previous_ptid"
there does not hold.
To address this problem, we have to move notification logic up to
mi_cmd_execute () where --thread option is processed and notify
user selected contents observers there if context changes.
However, this in itself breaks GDB/MI because it would cause context
notification to be sent on MI channel. This is because by the time
we notify, MI notification suppression is already restored (done in
mi_command::invoke(). Therefore we had to lift notification suppression
logic also up to mi_cmd_execute (). This change in made distinction
between mi_command::invoke() and mi_command::do_invoke() unnecessary
as all mi_command::invoke() did (after the change) was to call
do_invoke(). So this patches removes do_invoke() and moves the command
execution logic directly to invoke().
With this change, all gdb.mi tests pass, tested on x86_64-linux.
Co-authored-by: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20631
Use -Wno-format-truncation and -Wno-switch only if they are supported.
PR gprof/28969
* configure.ac (GPROFNG_NO_FORMAT_TRUNCATION_CFLAGS): New
AC_SUBST for -Wno-format-truncation.
(GPROFNG_NO_SWITCH_CFLAGS): New AC_SUBST for -Wno-switch.
* Makefile.in: Regenerate.
* configure: Likewise.
* src/Makefile.am (AM_CFLAGS): Replace -Wno-format-truncation
and -Wno-switch with GPROFNG_NO_FORMAT_TRUNCATION_CFLAGS and
GPROFNG_NO_SWITCH_CFLAGS.
* src/Makefile.in: Regenerate.
Use -Wno-nonnull-compare only if it is supported.
PR gprof/28969
* libcollector/Makefile.am (AM_CFLAGS): Replace
-Wno-nonnull-compare with GPROFNG_NO_NONNULL_COMPARE_CFLAGS.
* libcollector/configure.ac (GPROFNG_NO_NONNULL_COMPARE_CFLAGS):
New AC_SUBST for -Wno-nonnull-compare.
* libcollector/Makefile.in: Regenerate.
* libcollector/aclocal.m4: Likewise.
* libcollector/configure: Likewise.
The AMDGPU HSA OS ABI (code object v3 and above) defines the
NT_AMDGPU_METADATA ELF note [1]. The content is a msgpack object
describing, among other things, the kernels present in the code object
and how to call them.
I think it would be useful for readelf to be able to display the content
of those notes. msgpack is a structured format, a bit like JSON, except
not text-based. It is therefore possible to dump the contents in
human-readable form without knowledge of the specific layout of the
note.
Add configury to binutils to optionally check for the msgpack C library
[2]. Add There is a new --with{,out}-msgpack configure flag, and the actual
library lookup is done using pkg-config.
If msgpack support is enabled, dumping a NT_AMDGPU_METADATA note looks
like:
$ readelf --notes amdgpu-code-object
Displaying notes found in: .note
Owner Data size Description
AMDGPU 0x0000040d NT_AMDGPU_METADATA (code object metadata)
{
"amdhsa.kernels": [
{
".args": [
{
".address_space": "global",
".name": "out.coerce",
".offset": 0,
".size": 8,
".value_kind": "global_buffer",
},
<snip>
If msgpack support is disabled, dump the contents as hex, as is done
with notes that are not handled in a special way. This allows one to
decode the contents manually (maybe using a command-line msgpack
decoder) if really needed.
[1] https://llvm.org/docs/AMDGPUUsage.html#code-object-metadata
[2] https://github.com/msgpack/msgpack-c/tree/c_master
binutils/ChangeLog:
* Makefile.am (readelf_CFLAGS): New.
(readelf_LDADD): Add MSGPACK_LIBS.
* Makefile.in: Re-generate.
* config.in: Re-generate.
* configure: Re-generate.
* configure.ac: Add --with-msgpack flag and check for msgpack
using pkg-config.
* readelf.c: Include msgpack.h if HAVE_MSGPACK.
(print_note_contents_hex): New.
(print_indents): New.
(dump_msgpack_obj): New.
(dump_msgpack): New.
(print_amdgpu_note): New.
(process_note): Handle NT_AMDGPU_METADATA note contents.
Use print_note_contents_hex.
Change-Id: Ia60a654e620bc32dfdb1bccd845594e2af328b84
Handle the NT_AMDGPU_METADATA note, which is described here:
https://llvm.org/docs/AMDGPUUsage.html#code-object-v3-note-records
As of this patch, just print out the name, not the contents, which is in
the msgpack format.
binutils/ChangeLog:
* readelf.c (get_amdgpu_elf_note_type): New.
(process_note): Handle "AMDGPU" notes.
include/ChangeLog:
* elf/amdgcn.h (NT_AMDGPU_METADATA): New.
Change-Id: Id2dba2e2aeaa55ef7464fb35aee9c7d5f96ddb23
Decode and print the AMDGPU-specific fields of e_flags, as documented
here:
https://llvm.org/docs/AMDGPUUsage.html#header
That is:
- The specific GPU model
- Whether the xnack and sramecc features are enabled
The result looks like:
- Flags: 0x52f
+ Flags: 0x52f, gfx906, xnack any, sramecc any
The flags for the "HSA" OS ABI are properly versioned and documented on
that page. But the NONE, PAL and MESA3D OS ABIs are not well documented
nor versioned. Taking a peek at the LLVM source code, we see that they
encode their flags the same way as HSA v3. For example, for PAL:
c8b614cd74/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp (L601)
So for those other OS ABIs, we read them the same as HSA v3.
binutils/ChangeLog:
* readelf.c: Include elf/amdgcn.h.
(decode_AMDGPU_machine_flags): New.
(get_machine_flags): Handle flags for EM_AMDGPU machine type.
include/ChangeLog:
* elf/amdgcn.h: Add EF_AMDGPU_MACH_AMDGCN_* and
EF_AMDGPU_FEATURE_* defines.
Change-Id: Ib5b94df7cae0719a22cf4e4fd0629330e9485c12
When the machine is EM_AMDGPU, handle the various OS ABIs described
here:
https://llvm.org/docs/AMDGPUUsage.html#header
For a binary with the HSA OS ABI, the change looks like:
- OS/ABI: <unknown: 40>
+ OS/ABI: AMD HSA
binutils/ChangeLog:
* readelf.c (get_osabi_name): Handle EM_AMDGPU OS ABIs.
include/ChangeLog:
* elf/common.h (ELFOSABI_AMDGPU_PAL, ELFOSABI_AMDGPU_MESA3D):
New.
Change-Id: I383590c390f7dc2fe0f902f50038735626d71863
There isn't an actual opcodes implementation for the AMDGCN arch (yet),
this is just the bare minimum to get
$ ./configure --target=amdgcn-hsa-amdhsa --disable-gas
$ make all-binutils
working later in this series.
opcodes/ChangeLog:
* configure.ac: Handle bfd_amdgcn_arch.
* configure: Re-generate.
Change-Id: Ib7d7c5533a803ed8b2a293e9275f667ed781ce79
Add support for the AMDGCN architecture to BFD.
This is the bare minimum to get
$ ./configure --target=amdgcn-hsa-amdhsa --disable-gas
$ make all-binutils
working later in this series.
The specific AMDGCN models added here are a bit arbitrary, based on
what we intend to initially support in GDB. This list will need to be
updated in the future anyway. The complete up-to-date list of existing
AMDGPU models can be found here:
https://llvm.org/docs/AMDGPUUsage.html#processors
The ELF format for this architecture is documented here:
https://llvm.org/docs/AMDGPUUsage.html#elf-code-object
The flags for the "HSA" OS ABI are properly versioned and documented on
that page. But the NONE, PAL and MESA3D OS ABIs are not well documented
nor versioned. Taking a peek at the LLVM source code, we see that they
encode their flags the same way as HSA v3. For example, for PAL:
c8b614cd74/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp (L601)
So at least, we know that all AMDGPU objects (of which AMDGCN objects
are a subset of) at the time of writing encode the specific GPU model in
the EF_AMDGPU_MACH field of e_flags.
bfd/ChangeLog:
* Makefile.am (ALL_MACHINES, ALL_MACHINES_CFILES):
Add cpu-amdgcn.c.
(BFD64_BACKENDS): Add elf64-amdgcn.lo.
(BFD64_BACKENDS_CFILES): Add elf64-amdgcn.c.
* Makefile.in: Re-generate.
* cpu-amdgcn.c: New.
* elf64-amdgcn.c: New.
* archures.c (bfd_architecture): Add bfd_arch_amdgcn and related
mach defines.
(bfd_amdgcn_arch): New.
(bfd_archures_list): Add bfd_amdgcn_arch.
* bfd-in2.h: Re-generate.
* config.bfd: Handle amdgcn* target.
* configure.ac: Handle amdgcn_elf64_le_vec.
* configure: Re-generate.
* elf-bfd.h (elf_target_id): Add AMDGCN_ELF_DATA.
* targets.c (amdgcn_elf64_le_vec): New.
(_bfd_target_vector): Add amdgcn_elf64_le_vec.
include/ChangeLog:
* elf/amdgpu.h: New.
* elf/common.h (ELFOSABI_AMDGPU_HSA): Add.
Change-Id: I969f7b14960797e88891c308749a6e341eece5b2
gdb.fortran/array-slices.exp and gdb.fortran/lbound-ubound.exp were
recently disabled unless testing with the native target, because they
rely on inferior I/O. However, when testing against gdbserver using
the native-gdbserver/native-extended-gdbserver boards, we do have
access to inferior I/O.
The right way to check whether the board can do I/O, is via checking
the gdb,noinferiorio board variable. Switch to using that.
And then, tweak the testcases to expect output to appear in
inferior_spawn_id, instead of gdb_spawn_id. When testing against the
native target, inferior_spawn_id is the same as gdb_spawn_id. When
testing against gdbserver, it maps to gdbserver_spawn_id.
This exposed a buglet in gdb.fortran/array-slices.f90's show_1d
subroutine -- it was missing printing newline at the end of the
"Expected GDB Output" text, leading to a test timeout. All other
subroutines end with advance=yes, except this one. Fix it by using
advance=yes here too.
Change-Id: I4640729f334431cfc24b0917e7d3977b677c6ca5
Let's hope this stays dead, but it's here as a patch separate from
those that removed use of powerpc_macros just in case it needs to be
resurrected.
include/
* opcode/ppc.h (struct powerpc_macro): Delete declaration.
(powerpc_macros, powerpc_num_macros): Likewise..
opcodes/
* ppc-opc.c (powerpc_macros, powerpc_num_macros): Delete.
gas/
* config/tc-ppc.c (ppc_macro): Delete function.
(ppc_macro_hash): Delete.
(ppc_setup_opcodes, md_assemble): Delete macro support.
This moves VLE insn out of the macro table. "e_slwi" and "e_srwi"
already exist in vle_opcodes as distinct instructions rather than
encodings of e_rlwinm.
opcodes/
* ppc-opc.c (vle_opcodes): Typo fix e_rlwinm operand.
Add "e_inslwi", "e_insrwi", "e_rotlwi", "e_rotrwi", "e_clrlwi",
"e_clrrwi", "e_extlwi", "e_extrwi", and "e_clrlslwi".
(powerpc_macros): Delete same. Delete "e_slwi" and "e_srwi" too.
gas/
* testsuite/gas/ppc/vle-simple-5.d: Update.
The extended instructions implemented in powerpc_macros aren't used by
the disassembler. That means instructions like "sldi r3,r3,2" appear
in disassembly as "rldicr r3,r3,2,61", which is annoying since many
other extended instructions are shown.
Note that some of the instructions moved out of the macro table to the
opcode table won't appear in disassembly, because they are aliases
rather than a subset of the underlying raw instruction. If enabled,
rotrdi, extrdi, extldi, clrlsldi, and insrdi would replace all
occurrences of rotldi, rldicl, rldicr, rldic and rldimi. (Or many
occurrences in the case of clrlsldi if n <= b was added to the extract
functions.)
The patch also fixes a small bug in opcode sanity checking.
include/
* opcode/ppc.h (PPC_OPSHIFT_SH6): Define.
opcodes/
* ppc-opc.c (insert_erdn, extract_erdn, insert_eldn, extract_eldn),
(insert_crdn, extract_crdn, insert_rrdn, extract_rrdn),
(insert_sldn, extract_sldn, insert_srdn, extract_srdn),
(insert_erdb, extract_erdb, insert_csldn, extract_csldb),
(insert_irdb, extract_irdn): New functions.
(ELDn, ERDn, ERDn, RRDn, SRDn, ERDb, CSLDn, CSLDb, IRDn, IRDb):
Define and add associated powerpc_operands entries.
(powerpc_opcodes): Add "rotrdi", "srdi", "extrdi", "clrrdi",
"sldi", "extldi", "clrlsldi", "insrdi" and corresponding record
(ie. dot suffix) forms.
(powerpc_macros): Delete same from here.
gas/
* config/tc-ppc.c (insn_validate): Don't modify value passed
to operand->insert for PPC_OPERAND_PLUS1 when calculating mask.
Handle PPC_OPSHIFT_SH6.
* testsuite/gas/ppc/prefix-reloc.d: Update.
* testsuite/gas/ppc/simpshft.d: Update.
ld/
* testsuite/ld-powerpc/elfv2so.d: Update.
* testsuite/ld-powerpc/notoc.d: Update.
* testsuite/ld-powerpc/notoc3.d: Update.
* testsuite/ld-powerpc/tlsdesc2.d: Update.
* testsuite/ld-powerpc/tlsget.d: Update.
* testsuite/ld-powerpc/tlsget2.d: Update.
* testsuite/ld-powerpc/tlsopt5.d: Update.
* testsuite/ld-powerpc/tlsopt6.d: Update.
Simon pointed out that commit 13835d88 ("Use function view when
iterating over block symbols") caused a regression. The bug is that
the new closure captures 'pc' by reference, but later code updates
this variable -- but the earlier code did not update the callback
structure with the new value.
This patch restores the old behavior by using a new varible name in an
inner scope.
gprofng didn't build with gcc 6.3 due to the usage of __attribute__
((fallthrough)). This patch uses /* FALLTHROUGH */ instead.
2022-03-15 Jose E. Marchesi <jose.marchesi@oracle.com>
* gprofng/src/gp-collect-app.cc (collect::check_args): Use
fallthrough comment instead of attribute.
I noticed that, occasionally, dwarf-mode would think that the objdump
subprocess was still running after it had clearly exited. I managed
to reliably reproduce this today and learned that a process sentinel
is not guaranteed to be run with the current buffer set to the process
buffer. This patch fixes the problem.
I've bumped the version number of dwarf-mode.el to make it easier to
install for users who already have an earlier one installed.
I'm checking this in.
2022-03-15 Tom Tromey <tromey@adacore.com>
* dwarf-mode.el: Now 1.7.
(dwarf--sentinel): Switch to the process buffer.
