Jan Beulich [Mon, 29 Mar 2021 10:06:09 +0000 (12:06 +0200)]
x86: VPSADBW's source operands are also commutative
In commit 79dec6b7baa2 ("x86-64: optimize certain commutative
VEX-encoded insns") I missed the fact that there being subtraction
involved here doesn't matter, as absolute differences get summed up.
Jan Beulich [Mon, 29 Mar 2021 10:05:25 +0000 (12:05 +0200)]
x86: fold SSE2AVX and their base MMX/SSE templates
This way not only the overall (source) table size shrinks by quite a
bit and the risk of related templates going out of sync with one another
gets lowered, but also (dis)similarities between neighboring templates
become easier to spot.
Note that for certain SSE2AVX templates this results in benign attribute
changes:
- LDMXCSR and STMXCSR: NoAVX gets set,
- MOVMSKPS, PMOVMSKB, PEXTR{B,W} (register destination), and PINSR{B,W}
(register source): IgnoreSize and NoRex64 get set,
- CVT{DQ,PS}2PD, CVTSD2SS, MOVMSKPD, MOVDDUP, PMOV{S,Z}X{BW,WD,DQ}, and
ROUNDSD: NoRex64 gets set,
- CVTSS2SD, INSERTPS, PEXTRW (memory destination), PINSRW (memory
source), and PMOV{S,Z}X{BD,WQ,BQ}: IgnoreSize gets set.
Similarly the "normal" (non-SSE2AVX)
- non-64-bit CVTS{I,S}2SD forms get NoRex64 set,
- CMP{EQ,ORD,NEQ,UNORD}{P,S}{S,D} forms get C set,
all again in a benign way.
The remaining differences in the generated table are due to re-ordering
of entries in the course of being folded into templates.
Jan Beulich [Mon, 29 Mar 2021 10:04:03 +0000 (12:04 +0200)]
x86: undo Prefix_0X<nn> use in opcode table
The table entries are more natural to read (and slightly shorter) when
the prefixes, like is the case for VEX/XOP/EVEX-encoded entries, are
specified as part of the opcode. This is particularly noticable for
side-by-side legacy and SSE2AVX entries.
An implication is that we now need to use "unsigned long long" for the
initially parsed opcode in i386-gen. I don't expect this to be an issue.
Jan Beulich [Mon, 29 Mar 2021 10:03:31 +0000 (12:03 +0200)]
x86: shrink some struct insn_template fields
Now that all base opcodes are only at most 2 bytes in size, shrink its
template field to just as much. By also shrinking extension_opcode and
operands to just what they really need, we can free up an entire 32-bit
slot (plus 4 left bits past the bitfields themselves).
At present this alters sizeof(struct insn_template) only for 32-bit
builds. In 64-bit builds it instead leaves a padding hole that will
allow to buffer future growth of other fields (opcode_modifier,
cpu_flags, operand_types[]).
Jan Beulich [Mon, 29 Mar 2021 10:02:50 +0000 (12:02 +0200)]
x86: derive opcode encoding space attribute from base opcode
Just like is already done for VEX/XOP/EVEX encoded insns, record the
encoding space information in the respective opcode modifier field. Do
this again without changing the source table, but rather by deriving the
values from their existing source representation.
Alan Modra [Sun, 28 Mar 2021 23:22:56 +0000 (09:52 +1030)]
TRUE/FALSE simplification
There is really no need to write code like "foo != 0 ? TRUE : FALSE"
unless we had stupidly defined FALSE as something other than 0 or TRUE
as something other than 1. The simpler "foo != 0" does just as well.
Similarly "(condition == TRUE)" or "(condition == FALSE) can be
simplified to "(condition)" and "(!condition)" respectively.
I'll note that there is reason to use "integer_expression != 0" when
assigning a bfd_boolean rather than the simpler "integer_expression",
if you expect the variable to have 0 or 1 value. It's probably even a
good idea to not rely on implicit conversion if bfd_boolean were _Bool.
Alan Modra [Sun, 28 Mar 2021 23:17:16 +0000 (09:47 +1030)]
binutils int vs bfd_boolean fixes
* objdump.c (process_links): Use type int.
* readelf.c (request_dump): Don't increment do_dump, set it.
* windint.h (target_is_bigendian): Use type bfd_boolean.
* windmc.c (target_is_bigendian): Likewise.
* windres.c (target_is_bigendian): Likewise.
Alan Modra [Sun, 28 Mar 2021 23:11:01 +0000 (09:41 +1030)]
hash table iterator callback functions int vs. bfd_boolean
Correct return type of callbacks invoked by htab_traverse and other
hashtab.h functions to int, and one case of a callback invoked by
elf_link_hash_traverse to bfd_boolean.
Alan Modra [Sun, 28 Mar 2021 23:09:15 +0000 (09:39 +1030)]
ELF output symbol hooks int vs. bfd_boolean
elf_backend_link_output_symbol_hook and elf_link_output_symstrtab may
return 2 when a symbol is to be discarded. Update places that use
bfd_boolean rather than int for these functions.
* elflink.c (elf_link_output_symstrtab): Make flinfo parameter
a void pointer.
(bfd_elf_final_link): Delete out_sym_func typedef and don't cast
elf_link_output_symstrtab when calling output_arch_syms and
output_arch_local_syms.
* elf-bfd.h (struct elf_backend_data <elf_backend_output_arch_syms,
elf_backend_output_arch_local_syms>): Change return type of func
arg to match elf_link_output_symstrtab.
* elf-vxworks.h (elf_vxworks_link_output_symbol_hook): Correct
return type.
* elf32-nds32.c (nds32_elf_output_symbol_hook): Correct return type.
(nds32_elf_output_arch_syms): Correct func return type.
Alan Modra [Sun, 28 Mar 2021 23:08:15 +0000 (09:38 +1030)]
elf_backend_relocate_section int vs. bfd_boolean
This functions was changed to return an int in commit ece5ef60797f but
since bfd_boolean was an int typedef I lazily left all the ELF
relocate_section functions as returning bfd_boolean, except the SPU
one. In order to use _Bool or bool in place of bfd_boolean we need to
be fussy about the return types.
Tom Tromey [Sun, 28 Mar 2021 16:43:15 +0000 (10:43 -0600)]
Simplify DWARF reader initialization
Now that the quick functions are separate from the object file format,
there's no need to have elfread.c push a new entry on the objfile 'qf'
list. Instead, this detail can be pushed into the DWARF reader. That
is what this patch implements.
I wasn't sure whether lazy reading still makes sense or not. It's
still only used by ELF, and only in certain situations (like vfork, I
think). It may not be carrying its weight, so we may want to consider
removing this in the future.
Also, I'm unclear on why the various indices are only used for ELF.
This seems sub-optimal. However, I haven't tried to address that
here.
gdb/ChangeLog
2021-03-28 Tom Tromey <tom@tromey.com>
* elfread.c (can_lazily_read_symbols): Move to dwarf2/read.c.
(elf_symfile_read): Simplify.
* dwarf2/read.c (struct lazy_dwarf_reader): Move from elfread.c.
(make_lazy_dwarf_reader): New function.
(make_dwarf_gdb_index, make_dwarf_debug_names): Now static.
(dwarf2_initialize_objfile): Return void. Remove index_kind
parameter. Push on 'qf' list.
* dwarf2/public.h (dwarf2_initialize_objfile): Change return
type. Remove 'index_kind' parameter.
(make_dwarf_gdb_index, make_dwarf_debug_names): Don't declare.
Tom Tromey [Sat, 27 Mar 2021 22:41:53 +0000 (16:41 -0600)]
Don't clear 'qf' in elf_symfile_read
I noticed that I forgot to make a change in my series to make it
possible to attach multiple debug readers to an objfile. In one spot,
elf_symfile_read still clears the 'qf' list. However, this should
have been removed toward the end of that series.
This patch fixes the offending spot. Tested on x86-64 Fedora 32.
gdb/ChangeLog
2021-03-27 Tom Tromey <tom@tromey.com>
Will Schmidt [Sat, 27 Mar 2021 14:31:27 +0000 (14:31 +0000)]
gdb/testsuite: make some test names unique in gdb.arch/powerpc-*.exp
Resolve some duplicate test name warnings in gdb.arch/powerpc-*.exp
tests by either extending the existing test names, or providing a new
test name.
gdb/testsuite/ChangeLog:
* gdb.arch/powerpc-disassembler-options.exp: Extend some test
names for uniqueness.
* gdb.arch/powerpc-fpscr-gcore.exp: Add more test names for
uniqueness.
Lancelot SIX [Fri, 26 Mar 2021 16:46:57 +0000 (16:46 +0000)]
gdb-add-index.sh: Remove use of non posix 'local'
While working on gdb-add-index.sh, it appeared that it uses the non
POSIX 'local' keyword. Instead of using local to allow variable
shadowing, I rename the local one to avoid name conflicts altogether.
This commit gets rid of the following shellcheck warning:
In gdb-add-index.sh line 63:
local file="$1"
^--------^ SC2039: In POSIX sh, 'local' is undefined.
gdb/ChangeLog:
* contrib/gdb-add-index.sh: Avoid variable shadowing and get
rid of 'local'.
Tom Tromey [Fri, 26 Mar 2021 19:44:24 +0000 (13:44 -0600)]
Use function view in quick_symbol_functions::map_symbol_filenames
This changes quick_symbol_functions::map_symbol_filenames to use a
function_view, and updates all the uses. It also changes the final
parameter to 'bool'. A couple of spots are further updated to use
operator() rather than a lambda.
gdb/ChangeLog
2021-03-26 Tom Tromey <tom@tromey.com>
* symtab.c (struct output_source_filename_data): Add 'output'
method and operator().
(output_source_filename_data::output): Rename from
output_source_filename.
(output_partial_symbol_filename): Remove.
(info_sources_command): Update.
(struct add_partial_filename_data): Add operator().
(add_partial_filename_data::operator()): Rename from
maybe_add_partial_symtab_filename.
(make_source_files_completion_list): Update.
* symfile.c (quick_symbol_functions): Update.
* symfile-debug.c (objfile::map_symbol_filenames): Update.
* quick-symbol.h (symbol_filename_ftype): Change type of 'fun' and
'need_fullname'. Remove 'data' parameter.
(struct quick_symbol_functions) <map_symbol_filenames>: Likewise.
* psymtab.c (psymbol_functions::map_symbol_filenames): Update.
* psympriv.h (struct psymbol_functions) <map_symbol_filenames>:
Change type of 'fun' and 'need_fullname'. Remove 'data'
parameter.
* objfiles.h (struct objfile) <map_symbol_filenames>: Change type
of 'fun' and 'need_fullname'. Remove 'data' parameter.
* mi/mi-cmd-file.c (print_partial_file_name): Remove 'ignore'
parameter.
(mi_cmd_file_list_exec_source_files): Update.
* dwarf2/read.c
(dwarf2_base_index_functions::map_symbol_filenames): Update.
Tom Tromey [Fri, 26 Mar 2021 19:44:24 +0000 (13:44 -0600)]
Simplify use of map_matching_symbols in ada-lang.c
I noticed that ada-lang.c creates a lambda to call
aux_add_nonlocal_symbols. However, this code can be simplified a bit
by changing match_data to implement operator(), and then simply
passing the object as the callback. That is what this patch
implements.
gdb/ChangeLog
2021-03-26 Tom Tromey <tom@tromey.com>
I noticed that psymbol_functions::expand_symtabs_matching calls
make_ignore_params once per psymtab that is matched. This seems
possibly expensive, so this patch hoists the call out of the loop.
gdb/ChangeLog
2021-03-26 Tom Tromey <tom@tromey.com>
* psymtab.c (psymbol_functions::expand_symtabs_matching): Only
call make_ignore_params once.
Tom Tromey [Fri, 26 Mar 2021 19:28:03 +0000 (13:28 -0600)]
Allow expand_symtabs_matching to examine imported psymtabs
Currently the psymtab variant of expand_symtabs_matching has this
check:
/* We skip shared psymtabs because file-matching doesn't apply
to them; but we search them later in the loop. */
if (ps->user != NULL)
continue;
In a larger series I'm working on, it's convenient to remove this
check. And, I noticed that a similar check is not done for
expand_symtabs_with_fullname. So, it made sense to me to remove the
check here as well.
gdb/ChangeLog
2021-03-26 Tom Tromey <tom@tromey.com>
Keith Seitz [Thu, 25 Mar 2021 17:31:48 +0000 (10:31 -0700)]
Save/restore file offset while reading notes in core file
A recent bug (RH BZ 1931344) has exposed a bug in the core file
build-ID support that I introduced a while ago. It is pretty
easy to demonstate the problem following a simplified procedure
outlined in that bug:
[shell1]
shell1$ /usr/libexec/qemu-kvm
[shell2]
shell2$ pkill -SEGV -x qemu-kvm
[shell1]
Segmentation fault (core dumped)
Load this core file into GDB without specifying an executable
(an unfortunate Fedora/RHEL-ism), and GDB will inform the user
to install debuginfo for the "missing" executable:
$ gdb -nx -q core.12345
...
Missing separate debuginfo for the main executable file
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/e2/e9c66d3117fb2bbb5b2be122f04f2664e5df54
Core was generated by `/usr/libexec/qemu-kvm'.
Program terminated with signal SIGSEGV, Segmentation fault.
...
The suggested build-ID is actaully for gmp not qemu-kvm. The problem
lies in _bfd_elf_core_find_build_id, where we loop over program headers
looking for note segments:
/* Read in program headers and parse notes. */
for (i = 0; i < i_ehdr.e_phnum; ++i, ++i_phdr)
{
Elf_External_Phdr x_phdr;
elf_read_notes uses bfd_seek to forward the stream to the location of
the note segment. When control returns to _bfd_elf_core_fild_build_id,
the stream is no longer in the location looking at program headers, and
all subsequent reads will read from the wrong file offset.
To fix this, this patch marks the stream location and ensures
that it is restored after elf_read_notes is called.
bfd/ChangeLog
2021-03-26 Keith Seitz <keiths@redhat.com>
* elfcore.h (_bfd_elf_core_find_build_id): Seek file
offset of program headers after calling elf_read_notes.
Andrew Burgess [Tue, 2 Mar 2021 14:19:56 +0000 (14:19 +0000)]
gdb/testsuite: more testing of pretty printer 'array' display_hint
This commit adds a couple of tests to the python pretty printer
testing.
I've added a test for the 'array' display hint. This display hint is
tested by gdb.python/py-mi.exp, however, the MI testing is done via
the varobj interface, and this code makes its own direct calls to the
Python pretty printers from gdb/varobj.c. What this means is that the
interface to the pretty printers in gdb/python/py-prettyprint.c is not
tested for the 'array' display hint path.
I also added a test for what happens when the display_hint method
raises an exception. There wasn't a bug that inspired this test, just
while adding the previous test I thought, I wonder what happens if...
The current behaviour of GDB seems reasonable, GDB displays the Python
exception, and then continues printing the value as if display_hint
had returned None. I added a test to lock in this behaviour.
Simon Marchi [Mon, 6 Jul 2020 19:53:28 +0000 (15:53 -0400)]
gdb: defer commit resume until all available events are consumed
Rationale
---------
Let's say you have multiple threads hitting a conditional breakpoint
at the same time, and all of these are going to evaluate to false.
All these threads will need to be resumed.
Currently, GDB fetches one target event (one SIGTRAP representing the
breakpoint hit) and decides that the thread should be resumed. It
calls resume and commit_resume immediately. It then fetches the
second target event, and does the same, until it went through all
threads.
The result is therefore something like:
- consume event for thread A
- resume thread A
- commit resume (affects thread A)
- consume event for thread B
- resume thread B
- commit resume (affects thread B)
- consume event for thread C
- resume thread C
- commit resume (affects thread C)
For targets where it's beneficial to group resumptions requests (most
likely those that implement target_ops::commit_resume), it would be
much better to have:
- consume event for thread A
- resume thread A
- consume event for thread B
- resume thread B
- consume event for thread C
- resume thread C
- commit resume (affects threads A, B and C)
Implementation details
----------------------
To achieve this, this patch adds another check in
maybe_set_commit_resumed_all_targets to avoid setting the
commit-resumed flag of targets that readily have events to provide to
infrun.
To determine if a target has events readily available to report, this
patch adds an `has_pending_events` target_ops method. The method
returns a simple bool to say whether or not it has pending events to
report.
Testing
=======
To test this, I start GDBserver with a program that spawns multiple
threads:
The remote target receives a bunch of stop notifications for all
threads that have hit the breakpoint. infrun consumes and processes
one event, decides it should not cause a stop, prepares a displaced
step, after which we should see:
[infrun] maybe_set_commit_resumed_all_process_targets: not requesting commit-resumed for target remote, target has pending events
Same for a second thread (since we have 2 displaced step buffers).
For the following threads, their displaced step is deferred since
there are no more buffers available.
After consuming the last event the remote target has to offer, we get:
[infrun] maybe_set_commit_resumed_all_process_targets: enabling commit-resumed for target remote
[infrun] maybe_call_commit_resumed_all_process_targets: calling commit_resumed for target remote
[remote] Sending packet: $vCont;s:p14d16b.14d1b1;s:p14d16b.14d1b2#55
[remote] Packet received: OK
Without the patch, there would have been one vCont;s just after each
prepared displaced step.
gdb/ChangeLog:
yyyy-mm-dd Simon Marchi <simon.marchi@efficios.com>
Pedro Alves <pedro@palves.net>
* async-event.c (async_event_handler_marked): New.
* async-event.h (async_event_handler_marked): Declare.
* infrun.c (maybe_set_commit_resumed_all_targets): Switch to
inferior before calling target method. Don't commit-resumed if
target_has_pending_events is true.
* remote.c (remote_target::has_pending_events): New.
* target-delegates.c: Regenerate.
* target.c (target_has_pending_events): New.
* target.h (target_ops::has_pending_events): New target method.
(target_has_pending_events): New.
Simon Marchi [Mon, 25 Jan 2021 04:57:29 +0000 (23:57 -0500)]
gdb: generalize commit_resume, avoid commit-resuming when threads have pending statuses
The rationale for this patch comes from the ROCm port [1], the goal
being to reduce the number of back and forths between GDB and the
target when doing successive operations. I'll start with explaining
the rationale and then go over the implementation. In the ROCm / GPU
world, the term "wave" is somewhat equivalent to a "thread" in GDB.
So if you read if from a GPU stand point, just s/thread/wave/.
ROCdbgapi, the library used by GDB [2] to communicate with the GPU
target, gives the illusion that it's possible for the debugger to
control (start and stop) individual threads. But in reality, this is
not how it works. Under the hood, all threads of a queue are
controlled as a group. To stop one thread in a group of running ones,
the state of all threads is retrieved from the GPU, all threads are
destroyed, and all threads but the one we want to stop are re-created
from the saved state. The net result, from the point of view of GDB,
is that the library stopped one thread. The same thing goes if we
want to resume one thread while others are running: the state of all
running threads is retrieved from the GPU, they are all destroyed, and
they are all re-created, including the thread we want to resume.
This leads to some inefficiencies when combined with how GDB works,
here are two examples:
- Stopping all threads: because the target operates in non-stop mode,
when the user interface mode is all-stop, GDB must stop all threads
individually when presenting a stop. Let's suppose we have 1000
threads and the user does ^C. GDB asks the target to stop one
thread. Behind the scenes, the library retrieves 1000 thread
states and restores the 999 others still running ones. GDB asks
the target to stop another one. The target retrieves 999 thread
states and restores the 998 remaining ones. That means that to
stop 1000 threads, we did 1000 back and forths with the GPU. It
would have been much better to just retrieve the states once and
stop there.
- Resuming with pending events: suppose the 1000 threads hit a
breakpoint at the same time. The breakpoint is conditional and
evaluates to true for the first thread, to false for all others.
GDB pulls one event (for the first thread) from the target, decides
that it should present a stop, so stops all threads using
stop_all_threads. All these other threads have a breakpoint event
to report, which is saved in `thread_info::suspend::waitstatus` for
later. When the user does "continue", GDB resumes that one thread
that did hit the breakpoint. It then processes the pending events
one by one as if they just arrived. It picks one, evaluates the
condition to false, and resumes the thread. It picks another one,
evaluates the condition to false, and resumes the thread. And so
on. In between each resumption, there is a full state retrieval
and re-creation. It would be much nicer if we could wait a little
bit before sending those threads on the GPU, until it processed all
those pending events.
To address this kind of performance issue, ROCdbgapi has a concept
called "forward progress required", which is a boolean state that
allows its user (i.e. GDB) to say "I'm doing a bunch of operations,
you can hold off putting the threads on the GPU until I'm done" (the
"forward progress not required" state). Turning forward progress back
on indicates to the library that all threads that are supposed to be
running should now be really running on the GPU.
It turns out that GDB has a similar concept, though not as general,
commit_resume. One difference is that commit_resume is not stateful:
the target can't look up "does the core need me to schedule resumed
threads for execution right now". It is also specifically linked to
the resume method, it is not used in other contexts. The target
accumulates resumption requests through target_ops::resume calls, and
then commits those resumptions when target_ops::commit_resume is
called. The target has no way to check if it's ok to leave resumed
threads stopped in other target methods.
To bridge the gap, this patch generalizes the commit_resume concept in
GDB to match the forward progress concept of ROCdbgapi. The current
name (commit_resume) can be interpreted as "commit the previous resume
calls". I renamed the concept to "commit_resumed", as in "commit the
threads that are resumed".
In the new version, we have two things:
- the commit_resumed_state field in process_stratum_target: indicates
whether GDB requires target stacks using this target to have
resumed threads committed to the execution target/device. If
false, an execution target is allowed to leave resumed threads
un-committed at the end of whatever method it is executing.
- the commit_resumed target method: called when commit_resumed_state
transitions from false to true. While commit_resumed_state was
false, the target may have left some resumed threads un-committed.
This method being called tells it that it should commit them back
to the execution device.
Let's take the "Stopping all threads" scenario from above and see how
it would work with the ROCm target with this change. Before stopping
all threads, GDB would set the target's commit_resumed_state field to
false. It would then ask the target to stop the first thread. The
target would retrieve all threads' state from the GPU and mark that
one as stopped. Since commit_resumed_state is false, it leaves all
the other threads (still resumed) stopped. GDB would then proceed to
call target_stop for all the other threads. Since resumed threads are
not committed, this doesn't do any back and forth with the GPU.
To simplify the implementation of targets, this patch makes it so that
when calling certain target methods, the contract between the core and
the targets guarantees that commit_resumed_state is false. This way,
the target doesn't need two paths, one for commit_resumed_state ==
true and one for commit_resumed_state == false. It can just assert
that commit_resumed_state is false and work with that assumption.
This also helps catch places where we forgot to disable
commit_resumed_state before calling the method, which represents a
probable optimization opportunity. The commit adds assertions in the
target method wrappers (target_resume and friends) to have some
confidence that this contract between the core and the targets is
respected.
The scoped_disable_commit_resumed type is used to disable the commit
resumed state of all process targets on construction, and selectively
re-enable it on destruction (see below for criteria). Note that it
only sets the process_stratum_target::commit_resumed_state flag. A
subsequent call to maybe_call_commit_resumed_all_targets is necessary
to call the commit_resumed method on all target stacks with process
targets that got their commit_resumed_state flag turned back on. This
separation is because we don't want to call the commit_resumed methods
in scoped_disable_commit_resumed's destructor, as they may throw.
On destruction, commit-resumed is not re-enabled for a given target
if:
1. this target has no threads resumed, or
2. this target has at least one resumed thread with a pending status
known to the core (saved in thread_info::suspend::waitstatus).
The first point is not technically necessary, because a proper
commit_resumed implementation would be a no-op if the target has no
resumed threads. But since we have a flag do to a quick check, it
shouldn't hurt.
The second point is more important: together with the
scoped_disable_commit_resumed instance added in fetch_inferior_event,
it makes it so the "Resuming with pending events" described above is
handled efficiently. Here's what happens in that case:
1. The user types "continue".
2. Upon destruction, the scoped_disable_commit_resumed in the
`proceed` function does not enable commit-resumed, as it sees some
threads have pending statuses.
3. fetch_inferior_event is called to handle another event, the
breakpoint hit evaluates to false, and that thread is resumed.
Because there are still more threads with pending statuses, the
destructor of scoped_disable_commit_resumed in
fetch_inferior_event still doesn't enable commit-resumed.
4. Rinse and repeat step 3, until the last pending status is handled
by fetch_inferior_event. In that case,
scoped_disable_commit_resumed's destructor sees there are no more
threads with pending statues, so it asks the target to commit
resumed threads.
This allows us to avoid all unnecessary back and forths, there is a
single commit_resumed call once all pending statuses are processed.
This change required remote_target::remote_stop_ns to learn how to
handle stopping threads that were resumed but pending vCont. The
simplest example where that happens is when using the remote target in
all-stop, but with "maint set target-non-stop on", to force it to
operate in non-stop mode under the hood. If two threads hit a
breakpoint at the same time, GDB will receive two stop replies. It
will present the stop for one thread and save the other one in
thread_info::suspend::waitstatus.
Before this patch, when doing "continue", GDB first resumes the thread
without a pending status:
Sending packet: $vCont;c:p172651.172676#f3
It then consumes the pending status in the next fetch_inferior_event
call:
[infrun] do_target_wait_1: Using pending wait status status->kind = stopped, signal = GDB_SIGNAL_TRAP for Thread 1517137.1517137.
[infrun] target_wait (-1.0.0, status) =
[infrun] 1517137.1517137.0 [Thread 1517137.1517137],
[infrun] status->kind = stopped, signal = GDB_SIGNAL_TRAP
It then realizes it needs to stop all threads to present the stop, so
stops the thread it just resumed:
[infrun] stop_all_threads: Thread 1517137.1517137 not executing
[infrun] stop_all_threads: Thread 1517137.1517174 executing, need stop
remote_stop called
Sending packet: $vCont;t:p172651.172676#04
This is an unnecessary resume/stop. With this patch, we don't commit
resumed threads after proceeding, because of the pending status:
[infrun] maybe_commit_resumed_all_process_targets: not requesting commit-resumed for target extended-remote, a thread has a pending waitstatus
When GDB handles the pending status and stop_all_threads runs, we stop a
resumed but pending vCont thread:
That thread was never actually resumed on the remote stub / gdbserver,
so we shouldn't send a packet to the remote side asking to stop the
thread.
Note that there are paths that resume the target and then do a
synchronous blocking wait, in sort of nested event loop, via
wait_sync_command_done. For example, inferior function calls, or any
run control command issued from a breakpoint command list. We handle
that making wait_sync_command_one a "sync" point -- force forward
progress, or IOW, force-enable commit-resumed state.
gdb/ChangeLog:
yyyy-mm-dd Simon Marchi <simon.marchi@efficios.com>
Pedro Alves <pedro@palves.net>
* infcmd.c (run_command_1, attach_command, detach_command)
(interrupt_target_1): Use scoped_disable_commit_resumed.
* infrun.c (do_target_resume): Remove
target_commit_resume call.
(commit_resume_all_targets): Remove.
(maybe_set_commit_resumed_all_targets): New.
(maybe_call_commit_resumed_all_targets): New.
(enable_commit_resumed): New.
(scoped_disable_commit_resumed::scoped_disable_commit_resumed)
(scoped_disable_commit_resumed::~scoped_disable_commit_resumed)
(scoped_disable_commit_resumed::reset)
(scoped_disable_commit_resumed::reset_and_commit)
(scoped_enable_commit_resumed::scoped_enable_commit_resumed)
(scoped_enable_commit_resumed::~scoped_enable_commit_resumed):
New.
(proceed): Use scoped_disable_commit_resumed and
maybe_call_commit_resumed_all_targets.
(fetch_inferior_event): Use scoped_disable_commit_resumed.
* infrun.h (struct scoped_disable_commit_resumed): New.
(maybe_call_commit_resumed_all_process_targets): New.
(struct scoped_enable_commit_resumed): New.
* mi/mi-main.c (exec_continue): Use scoped_disable_commit_resumed.
* process-stratum-target.h (class process_stratum_target):
<commit_resumed_state>: New.
* record-full.c (record_full_wait_1): Change commit_resumed_state
around calling commit_resumed.
* remote.c (class remote_target) <commit_resume>: Rename to...
<commit_resumed>: ... this.
(struct stop_reply): Move up.
(remote_target::commit_resume): Rename to...
(remote_target::commit_resumed): ... this. Check if there is any
thread pending vCont resume.
(remote_target::remote_stop_ns): Generate stop replies for resumed
but pending vCont threads.
(remote_target::wait_ns): Add gdb_assert.
* target-delegates.c: Regenerate.
* target.c (target_wait, target_resume): Assert that the current
process_stratum target isn't in commit-resumed state.
(defer_target_commit_resume): Remove.
(target_commit_resume): Remove.
(target_commit_resumed): New.
(make_scoped_defer_target_commit_resume): Remove.
(target_stop): Assert that the current process_stratum target
isn't in commit-resumed state.
* target.h (struct target_ops) <commit_resume>: Rename to ...
<commit_resumed>: ... this.
(target_commit_resume): Remove.
(target_commit_resumed): New.
(make_scoped_defer_target_commit_resume): Remove.
* top.c (wait_sync_command_done): Use
scoped_enable_commit_resumed.
Pedro Alves [Mon, 22 Feb 2021 00:18:10 +0000 (00:18 +0000)]
target_is_non_stop_p and sync targets
gdb.base/maint-target-async-off.exp fails if you test against
gdbserver with "maint set target-non-stop on" forced.
(gdb) run
Starting program: build/gdb/testsuite/outputs/gdb.base/maint-target-async-off/maint-target-async-off
Breakpoint 1, main () at src/gdb/testsuite/gdb.base/maint-target-async-off.c:21
21 return 0;
(gdb) FAIL: gdb.base/maint-target-async-off.exp: continue until exit (timeout)
Above, GDB just stopped listening to stdin.
Basically, GDB assumes that a target working in non-stop mode
operation also supports async mode; it's a requirement. GDB
misbehaves badly otherwise, and even hits failed assertions.
Fix this by making target_is_non_stop_p return false if async is off.
gdb/ChangeLog:
* target.c (target_always_non_stop_p): Also check whether the
target can async.
Tom Tromey [Fri, 26 Mar 2021 15:37:22 +0000 (09:37 -0600)]
Avoid some pointer chasing in DWARF reader
I noticed a spot in the DWARF reader using "per_objfile->per_bfd",
where a local per_bfd variable had already been created. Looking
through the file, I found a number of such spots. This patch changes
them to use the already-existing local, avoiding a bit of excess
pointer chasing.
gdb/ChangeLog
2021-03-26 Tom Tromey <tom@tromey.com>
Andrew Burgess [Tue, 16 Mar 2021 10:17:07 +0000 (10:17 +0000)]
gdb/testsuite: resolve remaining duplicate test names in gdb.cp/*.exp
This commit resolves the remaining duplicate test names in
gdb.cp/*.exp. These are all the easy duplicates, I'm either giving
tests a new, unique name, extending an existing name to make it
unique, or changing an existing name to better reflect what the test
is actually doing, and thus, making this test name unique.
There should be no change in what is tested after this commit.
gdb/testsuite/ChangeLog:
* gdb.cp/breakpoint.exp: Extend test names to make them unique.
* gdb.cp/casts.exp: Give tests unique names.
* gdb.cp/filename.exp: Likewise.
* gdb.cp/gdb2495.exp: Likewise.
* gdb.cp/mb-ctor.exp: Extend test names to make them unique.
* gdb.cp/misc.exp: Rename test to make it unique.
* gdb.cp/nsnested.exp: Give tests unique names.
* gdb.cp/ovldbreak.exp: Likewise.
* gdb.cp/pr17494.exp: Rename test to reflect what is actually
being tested. This also removes the duplicate test name.
* gdb.cp/ref-types.exp: Likewise.
* gdb.cp/temargs.exp: Likewise.
Andrew Burgess [Wed, 17 Mar 2021 09:39:06 +0000 (09:39 +0000)]
gdb/testsuite: resolve duplicate test name in gdb.cp/cplusfuncs.exp
While resolving duplicate test names I spotted that a test in
gdb.cp/cplusfuncs.exp included an unescaped '[]'. In TCL square
brackets enclose expressions to evaluate, and so in this case, where
there is no enclosed expression, this just evaluates to the empty
string.
This clearly was not what the test intended, so in this commit I have
escaped the square brackets. This has extended the test coverage.
gdb/testsuite/ChangeLog:
* gdb.cp/cplusfuncs.exp (test_paddr_operator_functions): Escape
square brackets in test.
Andrew Burgess [Wed, 17 Mar 2021 09:19:50 +0000 (09:19 +0000)]
gdb/testsuite: remove duplicate test from gdb.cp/maint.exp
I wanted to remove the duplicate test name from gdb.cp/maint.exp. In
this test we run some checks against different operator names. For
one operator we test with a variable number of spaces. However, we
were accidentally testing the one space version twice, and the zero
space version not at all, leading to a duplicate test name.
I could have just changed the duplicate one space version into the
missing zero space version, but I thought it would be neater to wrap
multiple tests in a loop, and check all operators with either zero,
one, or two spaces.
These tests are super quick so take almost no extra time, and this
gives marginally more test coverage.
gdb/testsuite/ChangeLog:
* gdb.cp/maint.exp (test_first_component): Run more tests with a
variable number of spaces, this removes the duplicate testing of
'operator ->' which existed before.
Andrew Burgess [Tue, 16 Mar 2021 10:21:40 +0000 (10:21 +0000)]
gdb/testsuite: remove duplicate test names from gdb.cp/gdb2384.exp
The test gdb.cp/gdb2384.exp contains some duplicate test names, and
also some test names with a string inside parentheses at the end. In
order to resolve the duplicates the obvious choice would be to add yet
more strings inside parentheses at the end of names, however, this is
discouraged in our test naming scheme.
The string in parentheses originates from a comment in the test source
code, which naturally leads to including this comment in the test
name.
In this commit I have changed the comment in the test source to remove
the string in parentheses, I then rename the tests in the .exp script
to match, making sure that all test names are unique.
There should be no change in test coverage after this commit.
gdb/testsuite/ChangeLog:
* gdb.cp/gdb2384.cc (main): Change comments used for breakpoints.
* gdb.cp/gdb2384.exp: Change and extend test names to avoid
duplicates, and also to avoid having a string inside parentheses
at the end of test names.
Andrew Burgess [Tue, 16 Mar 2021 10:09:25 +0000 (10:09 +0000)]
gdb/testsuite: remove duplicate test names for gdb.cp/nsusing.exp
In trying to resolve the duplicate test names for the
gdb.cp/nsusing.exp script, I ended up giving the test script a serious
spring clean.
This reverts some of the changes introduced in commit df83a9bf8b0d,
but I don't think that we have lost any testing.
The test program is made of many functions, the test script wants to
stop in different functions and check which symbols are in scope.
Previously the test script would either restart GDB completely in
order to "progress" to the next function, or the script would restart
the test program using 'runto'.
In this commit I have reordered the steps of the test to correspond to
program order, I then progress through the test program once by just
placing a breakpoint and then continuing. As I said, the test is
checking which symbols are in scope at each location, so the exact
order of the tests doesn't matter, so long as we check the correct
symbols at each location.
I have also given the comments capital letters and full stops, and
re-wrapped them to a more sensible line length.
There was a duplicate test block introduced in the df83a9bf8b0d
commit which I have removed in this commit, this duplicate code was
responsible for one of the duplicate test names.
The other duplicate test name was due to the same command being run at
different locations, in this case I just gave the two tests explicit,
unique, names.
gdb/testsuite/ChangeLog:
* gdb.cp/nsusing.exp: Rewrite test, remove a duplicate test block.
Avoid repeated uses of 'runto', and instread just progress once
through the test stopping at different breakpoints. Give comments
a capital letter and full stop. Give duplicate tests unique names.
Jan Beulich [Fri, 26 Mar 2021 10:43:19 +0000 (11:43 +0100)]
x86-64: don't accept supposedly disabled MOVQ forms
While all of MMX, SSE, and SSE2 are included in "generic64", they can be
individually disabled. There are two MOVQ forms lacking respective
attributes. While the MMX one would get refused anyway (due to MMX
registers not recognized with .nommx), the assembler did happily accept
the SSE2 form. Add respective CPU settings to both, paralleling what the
MOVD counterparts have.
Pedro Alves [Sat, 13 Feb 2021 16:25:26 +0000 (16:25 +0000)]
Fix bkpt-other-inferior.exp race
When testing with "maint set target-non-stop on",
gdb.server/bkpt-other-inferior.exp sometimes fails like so:
(gdb) inferior 2
[Switching to inferior 2 [process 368191] (<noexec>)]
[Switching to thread 2.1 (Thread 368191.368191)]
[remote] Sending packet: $m7ffff7fd0100,1#5b
[remote] Packet received: 48
[remote] Sending packet: $m7ffff7fd0100,1#5b
[remote] Packet received: 48
[remote] Sending packet: $m7ffff7fd0100,9#63
[remote] Packet received: 4889e7e8e80c000049
#0 0x00007ffff7fd0100 in ?? ()
(gdb) PASS: gdb.server/bkpt-other-inferior.exp: inf 2: switch to inferior
break -q main
Breakpoint 2 at 0x1138: file /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.server/server.c, line 21.
(gdb) PASS: gdb.server/bkpt-other-inferior.exp: inf 2: set breakpoint
delete breakpoints
Delete all breakpoints? (y or n) y
(gdb) [remote] wait: enter
[remote] wait: exit
FAIL: gdb.server/bkpt-other-inferior.exp: inf 2: delete all breakpoints in delete_breakpoints (timeout)
ERROR: breakpoints not deleted
Remote debugging from host ::1, port 55876
monitor exit
The problem is here:
(gdb) [remote] wait: enter
The testcase isn't expecting any output after the prompt.
Why is that "[remote] wait" output? What happens is that "delete
breakpoints" queries the user, and `query` disables/reenables target
async, which results in the remote target's async event handler ending
up marked:
(top-gdb) bt
#0 mark_async_event_handler (async_handler_ptr=0x556bffffffff) at ../../src/gdb/async-event.c:295
#1 0x0000556bf71b711f in infrun_async (enable=1) at ../../src/gdb/infrun.c:119
#2 0x0000556bf7471387 in target_async (enable=1) at ../../src/gdb/target.c:3684
#3 0x0000556bf748a0bd in gdb_readline_wrapper_cleanup::~gdb_readline_wrapper_cleanup (this=0x7ffe3cf30eb0, __in_chrg=<optimized out>) at ../../src/gdb/top.c:1074
#4 0x0000556bf74874e2 in gdb_readline_wrapper (prompt=0x556bfa17da60 "Delete all breakpoints? (y or n) ") at ../../src/gdb/top.c:1096
#5 0x0000556bf75111c5 in defaulted_query(const char *, char, typedef __va_list_tag __va_list_tag *) (ctlstr=0x556bf7717f34 "Delete all breakpoints? ", defchar=0 '\000', args=0x7ffe3cf31020) at ../../src/gdb/utils.c:893
#6 0x0000556bf751166f in query (ctlstr=0x556bf7717f34 "Delete all breakpoints? ") at ../../src/gdb/utils.c:985
#7 0x0000556bf6f11404 in delete_command (arg=0x0, from_tty=1) at ../../src/gdb/breakpoint.c:13500
...
... which then later results in a target_wait call:
(top-gdb) bt
#0 remote_target::wait_ns (this=0x7ffe3cf30f80, ptid=..., status=0xde530314f0802800, options=...) at ../../src/gdb/remote.c:7937
#1 0x0000556bf7369dcb in remote_target::wait (this=0x556bfa0b2180, ptid=..., status=0x7ffe3cf31568, options=...) at ../../src/gdb/remote.c:8173
#2 0x0000556bf745e527 in target_wait (ptid=..., status=0x7ffe3cf31568, options=...) at ../../src/gdb/target.c:2000
#3 0x0000556bf71be686 in do_target_wait_1 (inf=0x556bfa1573d0, ptid=..., status=0x7ffe3cf31568, options=...) at ../../src/gdb/infrun.c:3463
#4 0x0000556bf71be88b in <lambda(inferior*)>::operator()(inferior *) const (__closure=0x7ffe3cf31320, inf=0x556bfa1573d0) at ../../src/gdb/infrun.c:3526
#5 0x0000556bf71bebcd in do_target_wait (wait_ptid=..., ecs=0x7ffe3cf31540, options=...) at ../../src/gdb/infrun.c:3539
#6 0x0000556bf71bf97b in fetch_inferior_event () at ../../src/gdb/infrun.c:3879
#7 0x0000556bf71a27f8 in inferior_event_handler (event_type=INF_REG_EVENT) at ../../src/gdb/inf-loop.c:42
#8 0x0000556bf71cc8b7 in infrun_async_inferior_event_handler (data=0x0) at ../../src/gdb/infrun.c:9220
#9 0x0000556bf6ecb80f in check_async_event_handlers () at ../../src/gdb/async-event.c:327
#10 0x0000556bf76b011a in gdb_do_one_event () at ../../src/gdbsupport/event-loop.cc:216
...
... which returns TARGET_WAITKIND_IGNORE.
Fix this by only enabling remote output around setting the breakpoint.
gdb/testsuite/ChangeLog:
* gdb.server/bkpt-other-inferior.exp: Only enable remote output
around setting the breakpoint.
Pedro Alves [Sat, 13 Feb 2021 19:16:44 +0000 (19:16 +0000)]
Fix problem exposed by gdb.server/stop-reply-no-thread-multi.exp
Running gdb.server/stop-reply-no-thread-multi.exp with "maint set
target-non-stop on" occasionally hit an internal error like this:
...
continue
Continuing.
warning: multi-threaded target stopped without sending a thread-id, using first non-exited thread
/home/pedro/gdb/binutils-gdb/src/gdb/inferior.c:291: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
This is a bug, please report it.
FAIL: gdb.server/stop-reply-no-thread-multi.exp: to_disable=Tthread: continue until exit (GDB internal error)
The backtrace looks like this:
...
#5 0x0000560357b0879c in internal_error (file=0x560357be6c18 "/home/pedro/gdb/binutils-gdb/src/gdb/inferior.c", line=291, fmt=0x560357be6b21 "%s: Assertion `%s' failed.") at /home/pedro/gdb/binutils-gdb/src/gdbsupport/errors.cc:55
#6 0x000056035762061b in find_inferior_pid (targ=0x5603596e9560, pid=0) at /home/pedro/gdb/binutils-gdb/src/gdb/inferior.c:291
#7 0x00005603576206e6 in find_inferior_ptid (targ=0x5603596e9560, ptid=...) at /home/pedro/gdb/binutils-gdb/src/gdb/inferior.c:305
#8 0x00005603577d43ed in remote_target::check_pending_events_prevent_wildcard_vcont (this=0x5603596e9560, may_global_wildcard=0x7fff84fb05f0) at /home/pedro/gdb/binutils-gdb/src/gdb/remote.c:7215
#9 0x00005603577d2a9c in remote_target::commit_resumed (this=0x5603596e9560) at /home/pedro/gdb/binutils-gdb/src/gdb/remote.c:6680
...
pid is 0 in this case because the queued event is a process exit event
with no pid associated:
(top-gdb) p event->ws
During symbol reading: .debug_line address at offset 0x563c9a is 0 [in module /home/pedro/gdb/binutils-gdb/build/gdb/gdb]
$1 = {kind = TARGET_WAITKIND_EXITED, value = {integer = 0, sig = GDB_SIGNAL_0, related_pid = {m_pid = 0, m_lwp = 0, m_tid = 0}, execd_pathname = 0x0, syscall_number = 0}}
(top-gdb)
This fixes it, and adds a "maint set target-non-stop on/off" axis to the testcase.
gdb/ChangeLog:
* remote.c
(remote_target::check_pending_events_prevent_wildcard_vcont):
Check whether the event's ptid is not null_ptid before looking up
the corresponding inferior.
gdb/testsuite/ChangeLog:
* gdb.server/stop-reply-no-thread-multi.exp (run_test): Add
"target_non_stop" parameter and use it.
(top level): Add "maint set target-non-stop on/off" testing axis.
Nick Alcock [Thu, 25 Mar 2021 16:32:46 +0000 (16:32 +0000)]
ld: do not rely on the exact size of the CTF symtypetabs in test results
The data object and function info sections (collectively "symtypetabs")
usually (i.e. if non-indexed) have sizes defined by the size of the ELF
dynamic symbol table in the object they are linked to. This means test
results should not depend on the exact sizes of these sections, because
adding entirely irrelevant symbols to the dynsym can cause spurious test
failures. (This also means we should not match the offset of sections
that follow them, since those too depend on the exact size of the
symtypetab sections.)
Spotted by turning the sanitizer on, which introduced new dynsym entries
and expanded the symtypetab sizes to match.
ld/ChangeLog
2021-03-25 Nick Alcock <nick.alcock@oracle.com>
* testsuite/ld-ctf/array.d: Only check that the data object
section is nonempty: do not check its exact size.
* testsuite/ld-ctf/diag-parlabel.d: Likewise.
* testsuite/ld-ctf/slice.d: Likewise.
* testsuite/ld-ctf/data-func-conflicted.d: Likewise, and for the
func info section too.
* testsuite/ld-ctf/function.d: Likewise, for the func info section.
Nick Alcock [Thu, 25 Mar 2021 16:32:46 +0000 (16:32 +0000)]
libctf: fix ELF-in-BFD checks in the presence of ASAN
The address sanitizer contains a redirector that captures dlopen calls,
so checks for dlopen with AC_SEARCH_LIBS will always conclude that
dlopen is present when the sanitizer is on. This means it won't add
-ldl to LIBS even if needed, and the immediately-following attempt to
actually link with -lbfd will fail because libbfd also needs dlsym,
which ASAN does *not* contain a redirector for.
If we check for dlsym instead of dlopen, the check works whether ASAN is
on or off. (bfd uses both in close proximity: if it needs one, it will
always need the other.)
libctf/ChangeLog
2021-03-25 Nick Alcock <nick.alcock@oracle.com>
* configure.ac: Check for dlsym, not dlopen.
* configure: Regenerate.
Nick Alcock [Thu, 25 Mar 2021 16:32:46 +0000 (16:32 +0000)]
libctf: don't dereference out-of-bounds locations in the qualifier hashtab
isqualifier, which is used by ctf_lookup_by_name to figure out if a
given word in a type name is a qualifier, takes the address of a
possibly out-of-bounds location before checking its bounds.
In any reasonable compiler this will just lead to a harmless address
computation that is then discarded if out-of-bounds, but it's still
undefined behaviour and the sanitizer rightly complains.
libctf/ChangeLog
2021-03-25 Nick Alcock <nick.alcock@oracle.com>
Nick Alcock [Thu, 25 Mar 2021 16:32:46 +0000 (16:32 +0000)]
libctf: make ctf_bfdopen_ctfsect a debugger entry point
This makes it possible to use LIBCTF_DEBUG to debug things that happen
before the ctf_bfdopen_internal call that ctf_bfdopen_ctfsect eventually
thunks down to (symtab/strtab lookup, archive opening, etc).
This is not important for ctf_open callers, since ctf_fdopen already
calls libctf_init_debug, but ctf_bfdopen_ctfsect is a public entry point
that can be called directly (e.g. objdump and readelf both do so).
libctf/ChangeLog
2021-03-25 Nick Alcock <nick.alcock@oracle.com>
Nick Alcock [Thu, 25 Mar 2021 16:32:46 +0000 (16:32 +0000)]
libctf, serialize: functions with no args have a NULL dtd_vlen
Every place that accesses a function's dtd_vlen accesses it only if the
number of args is nonzero, except the serializer, which always tries to
memcpy it. The number of bytes it memcpys in this case is zero, but it
is still undefined behaviour to copy zero bytes from a null pointer.
So check for this case explicitly.
libctf/ChangeLog
2021-03-25 Nick Alcock <nick.alcock@oracle.com>
PR libctf/27628
* ctf-serialize.c (ctf_emit_type_sect): Allow for a NULL vlen in
CTF_K_FUNCTION types.
Nick Alcock [Thu, 25 Mar 2021 16:32:46 +0000 (16:32 +0000)]
include: always do unsigned left-shift in CTF_SET_STID
This turns into a signed left shift by 31 bits, otherwise. This is an
offset and is always treated as unsigned in any case, so add an
appropriate cast.
include/ChangeLog
2021-03-25 Nick Alcock <nick.alcock@oracle.com>
PR libctf/27628
* ctf-api.h: Fix some indentation.
(CTF_SET_STID): Always do an unsigned shift, even if STID is
signed.
Nick Alcock [Thu, 25 Mar 2021 16:32:46 +0000 (16:32 +0000)]
libctf, dump: do not emit size or alignment if it would error
When we dump normal types, we emit their size and/or alignment:
but size and alignment dumping can return errors if the type is
part of a chain that terminates in a forward.
Emitting 0xffffffff as a size or alignment is unhelpful, so simply
skip emitting this info for any type for which size or alignment
checks return an error, no matter what the error is.
libctf/ChangeLog
2021-03-25 Nick Alcock <nick.alcock@oracle.com>
* ctf-dump.c (ctf_dump_format_type): Don't emit size or alignment
on error.
This is a failure from the `supports_memtag` proc added recently (this
new proc is in lib/gdb.exp).
The problem here is that `supports_memtag` is hitting one of the
default error cases in gdb_test_multiple, specifically it is finding a
$gdb_prompt left unmatched from an earlier call to gdb_test_multiple.
Looking back through the test output I found that the problem is the
proc `gnat_runtime_has_debug_info` in lib/ada.exp. This proc is not
matching the trailing $gdb_prompt. This leaves the prompt in the
expect buffer, then when we run `supports_memtag` it sees the prompt
and thinks that the test completed with no output.
Fixed by making use of `-wrap` in `gnat_runtime_has_debug_info` to
ensure the trailing prompt gets matched.
gdb/testsuite/ChangeLog:
* lib/ada.exp (gnat_runtime_has_debug_info): Use -wrap with
gdb_test_multiple.
gdb/riscv: Allow breakpoints to be created at invalid addresses
Unfortunately, the call to read_code was left in by mistake. The
result is that GDB will fail when trying to create the breakpoint,
rather than when trying to install the breakpoint (as is the case with
other targets).
This commit fixes this mistake and removes the offending call to
read_code.
gdb/ChangeLog:
* riscv-tdep.c (riscv_breakpoint_kind_from_pc): Remove call to
read_code.
Jan Beulich [Thu, 25 Mar 2021 07:20:55 +0000 (08:20 +0100)]
x86: fix CMPXCHG8B special case when disallowing q suffix outside of 64-bit mode
In match_template() i.tm hasn't been filled yet, so it is necessarily t
which needs checking. This is only a latent issue as no other templates
with the same base_opcode have an extension_opcode of 1.
Jan Beulich [Thu, 25 Mar 2021 07:20:19 +0000 (08:20 +0100)]
x86: flag bad S/G insn operand combinations
For VEX-encoded ones, all three involved vector registers have to be
distinct. For EVEX-encoded ones an actual mask register has to be in use
and zeroing-masking cannot be used (violation of either will #UD).
Additionally both involved vector registers have to be distinct for
EVEX-encoded gathers.
Jan Beulich [Thu, 25 Mar 2021 07:18:41 +0000 (08:18 +0100)]
x86: fix AMD Zen3 insns
For INVLPGB the operand count was wrong (besides %edx there's also %ecx
which is an input to the insn). In this case I see little sense in
retaining the bogus 2-operand template. Plus swapping of the operands
wasn't properly suppressed for Intel syntax.
For PVALIDATE, RMPADJUST, and RMPUPDATE bogus single operand templates
were specified. These get retained, as the address operand is the only
one really needed to expressed non-default address size, but only for
compatibility reasons. Proper multi-operand insn get introduced and the
testcases get adjusted / extended accordingly.
While at it also drop the redundant definition of __amd64__ - we already
have x86_64 defined (or not) to distinguish 64-bit and non-64-bit cases.
Jan Beulich [Thu, 25 Mar 2021 07:17:45 +0000 (08:17 +0100)]
x86-64: limit breakage from gcc movdir64b et al workaround
This is only a partial fix for PR/gas 27419, in that it limits the bad
behavior of accepting mismatched operands to just x32 mode. The full fix
would be to revert commits 27f134698ac5 and b3a3496f83a1, and to address
the issue in gcc instead.
Simon Marchi [Wed, 24 Mar 2021 22:08:12 +0000 (18:08 -0400)]
gdb: remove current_top_target function
The current_top_target function is a hidden dependency on the current
inferior. Since I'd like to slowly move towards reducing our dependency
on the global current state, remove this function and make callers use
current_inferior ()->top_target ()
There is no expected change in behavior, but this one step towards
making those callers use the inferior from their context, rather than
refer to the global current inferior.
gdb/ChangeLog:
* target.h (current_top_target): Remove, make callers use the
current inferior instead.
* target.c (current_top_target): Remove.
Simon Marchi [Wed, 24 Mar 2021 22:07:30 +0000 (18:07 -0400)]
gdb: move all "current target" wrapper implementations to target.c
The following patch removes the current_top_target function, replacing
uses with `current_inferior ()->top_target ()`. This is a problem for
uses in target.h, because they don't have access to the current_inferior
function and the inferior structure: target.h can't include inferior.h,
otherwise that would make a cyclic inclusion.
Avoid this by moving all implementations of the wrappers that call
target methods with the current target to target.c. Many of them are
changed from a macro to a function, which is an improvement for
readability and debuggability, IMO.
target_shortname and target_longname were not function-like macros, so a
few adjustments are needed.
Luis Machado [Mon, 15 Jun 2020 18:55:02 +0000 (15:55 -0300)]
Add memory tagging testcases
Add an AArch64-specific test and a more generic memory tagging test that
other architectures can run.
Even though architectures not supporting memory tagging can run the memory
tagging tests, the runtime check will make the tests bail out early, as it
would make no sense to proceed without proper support.
It is also tricky to do any further runtime tests for memory tagging, given
we'd need to deal with tags, and those are arch-specific. Therefore the
test in gdb.base is more of a smoke test.
If an architecture wants to implement memory tagging, then it makes sense to
have tests within gdb.arch instead.
gdb/testsuite/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* gdb.arch/aarch64-mte.c: New file.
* gdb.arch/aarch64-mte.exp: New test.
* gdb.base/memtag.c: New file.
* gdb.base/memtag.exp: New test.
* lib/gdb.exp (supports_memtag): New function.
Luis Machado [Mon, 15 Jun 2020 18:51:21 +0000 (15:51 -0300)]
Document new "x" and "print" memory tagging extensions
Document the changes to the "print" and "x" commands to support memory
tagging.
gdb/doc/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* gdb.texinfo (Data): Document memory tagging changes to the "print"
command.
(Examining Memory): Document memory tagging changes to the "x"
command.
(Memory Tagging): Update with more information on changes to the "x"
and "print" commands.
Luis Machado [Mon, 15 Jun 2020 18:50:55 +0000 (15:50 -0300)]
Extend "x" and "print" commands to support memory tagging
Extend the "x" and "print" commands to make use of memory tagging
functionality, if supported by the architecture.
The "print" command will point out any possible tag mismatches it finds
when dealing with pointers, in case such a pointer is tagged. No additional
modifiers are needed.
Suppose we have a pointer "p" with value 0x1234 (logical tag 0x0) and that we
have an allocation tag of 0x1 for that particular area of memory. This is the
expected output:
(gdb) p/x p
Logical tag (0x0) does not match the allocation tag (0x1).
$1 = 0x1234
The "x" command has a new 'm' modifier that will enable displaying of
allocation tags alongside the data dump. It will display one allocation
tag per line.
AArch64 has a tag granule of 16 bytes, which means we can have one tag for
every 16 bytes of memory. In this case, this is what the "x" command will
display with the new 'm' modifier:
(gdb) x/32bxm p
<Allocation Tag 0x1 for range [0x1230,0x1240)>
0x1234: 0x01 0x02 0x00 0x00 0x00 0x00 0x00 0x00
0x123c: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
<Allocation Tag 0x1 for range [0x1240,0x1250)>
0x1244: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x124c: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
(gdb) x/4gxm a
<Allocation Tag 0x1 for range [0x1230,0x1240)>
0x1234: 0x0000000000000201 0x0000000000000000
<Allocation Tag 0x1 for range [0x1240,0x1250)>
0x1244: 0x0000000000000000 0x0000000000000000
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* printcmd.c (decode_format): Handle the 'm' modifier.
(do_examine): Display allocation tags when required/supported.
(should_validate_memtags): New function.
(print_command_1): Display memory tag mismatches.
* valprint.c (show_memory_tag_violations): New function.
(value_print_option_defs): Add new option "memory-tag-violations".
(user_print_options) <memory_tag_violations>: Initialize to 1.
* valprint.h (struct format_data) <print_tags>: New field.
(value_print_options) <memory_tag_violations>: New field.
gdb/testsuite/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* gdb.base/options.exp: Adjust for new print options.
* gdb.base/with.exp: Likewise.
Luis Machado [Mon, 15 Jun 2020 18:49:37 +0000 (15:49 -0300)]
New memory-tag commands
Add new commands under the "memory-tag" prefix to allow users to inspect,
modify and check memory tags in different ways.
The available subcommands are the following:
- memory-tag print-logical-tag <expression>: Prints the logical tag for a
particular address.
- memory-tag withltag <expression> <tag>: Prints the address tagged with the
logical tag <tag>.
- memory-tag print-allocation-tag <expression>: Prints the allocation tag for
a particular address.
- memory-tag setatag <expression> <length> <tags>: Sets one or more allocation
tags to the specified tags.
- memory-tag check <expression>: Checks if the logical tag in <address>
matches its allocation tag.
These commands make use of the memory tagging gdbarch methods, and are still
available, but disabled, when memory tagging is not supported by the
architecture.
I've pondered about a way to make these commands invisible when memory tagging
is not available, but given the check is at runtime (and support may come and go
based on a process' configuration), that is a bit too late in the process to
either not include the commands or get rid of them.
Ideas are welcome.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* printcmd.c: Include gdbsupport/rsp-low.h.
(memory_tag_list): New static global.
(process_print_command_args): Factored out of
print_command_1.
(print_command_1): Use process_print_command_args.
(show_addr_not_tagged, show_memory_tagging_unsupported)
(memory_tag_command, memory_tag_print_tag_command)
(memory_tag_print_logical_tag_command)
(memory_tag_print_allocation_tag_command, parse_with_logical_tag_input)
(memory_tag_with_logical_tag_command, parse_set_allocation_tag_input)
(memory_tag_set_allocation_tag_command, memory_tag_check_command): New
functions.
(_initialize_printcmd): Add "memory-tag" prefix and subcommands.
gdbsupport/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* rsp-low.cc (fromhex, hex2bin): Move to ...
* common-utils.cc: ... here.
(fromhex) Change error message text to not be RSP-specific.
* rsp-low.h (fromhex, hex2bin): Move to ...
* common-utils.h: ... here.
Luis Machado [Mon, 15 Jun 2020 18:44:20 +0000 (15:44 -0300)]
AArch64: Report tag violation error information
Whenever a memory tag violation occurs, we get a SIGSEGV. Additional
information can be obtained through the siginfo data structure.
For AArch64 the Linux kernel may expose the fault address and tag
information, if we have a synchronous event. Otherwise there is
no fault address available.
The synchronous event looks like this:
--
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0500fffff7ff8000
Allocation tag 0x1.
Logical tag 0x5
--
The asynchronous event looks like this:
--
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault
Memory tag violation
Fault address unavailable.
--
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* aarch64-linux-tdep.c
(aarch64_linux_report_signal_info): New function.
(aarch64_linux_init_abi): Register
aarch64_linux_report_signal_info as the report_signal_info hook.
* arch/aarch64-linux.h (SEGV_MTEAERR): Define.
(SEGV_MTESERR): Define.
Luis Machado [Mon, 15 Jun 2020 18:11:07 +0000 (15:11 -0300)]
AArch64: Add unit testing for logical tag set/get operations
Add some unit testing to exercise setting/getting logical tags in the
AArch64 implementation.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* aarch64-linux-tdep.c: Include gdbsupport/selftest.h.
(aarch64_linux_ltag_tests): New function.
(_initialize_aarch64_linux_tdep): Register aarch64_linux_ltag_tests.
Luis Machado [Mon, 15 Jun 2020 17:24:53 +0000 (14:24 -0300)]
Refactor parsing of /proc/<pid>/smaps
The Linux kernel exposes the information about MTE-protected pages via the
proc filesystem, more specifically through the smaps file.
What we're looking for is a mapping with the 'mt' flag, which tells us that
mapping was created with a PROT_MTE flag and, thus, is capable of using memory
tagging.
We already parse that file for other purposes (core file
generation/filtering), so this patch refactors the code to make the parsing
of the smaps file reusable for memory tagging.
The function linux_address_in_memtag_page uses the refactored code to allow
querying for memory tag support in a particular address, and it gets used in the
next patch.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* linux-tdep.c (struct smaps_vmflags) <memory_tagging>: New flag
bit.
(struct smaps_data): New struct.
(decode_vmflags): Handle the 'mt' flag.
(parse_smaps_data): New function, refactored from
linux_find_memory_regions_full.
(linux_address_in_memtag_page): New function.
(linux_find_memory_regions_full): Refactor into parse_smaps_data.
* linux-tdep.h (linux_address_in_memtag_page): New prototype.
Luis Machado [Fri, 19 Jun 2020 20:33:13 +0000 (17:33 -0300)]
AArch64: Implement memory tagging target methods for AArch64
The patch implements the memory tagging target hooks for AArch64, so we
can handle MTE.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* Makefile.in (ALL_64_TARGET_OBS): Add arch/aarch64-mte-linux.o.
(HFILES_NO_SRCDIR): Add arch/aarch64-mte-linux.h and
nat/aarch64-mte-linux-ptrace.h.
* aarch64-linux-nat.c: Include nat/aarch64-mte-linux-ptrace.h.
(aarch64_linux_nat_target) <supports_memory_tagging>: New method
override.
<fetch_memtags>: New method override.
<store_memtags>: New method override.
(aarch64_linux_nat_target::supports_memory_tagging): New method.
(aarch64_linux_nat_target::fetch_memtags): New method.
(aarch64_linux_nat_target::store_memtags): New method.
* arch/aarch64-mte-linux.c: New file.
* arch/aarch64-mte-linux.h: Include gdbsupport/common-defs.h.
(AARCH64_MTE_GRANULE_SIZE): Define.
(aarch64_memtag_type): New enum.
(aarch64_mte_get_tag_granules): New prototype.
* configure.nat (NATDEPFILES): Add nat/aarch64-mte-linux-ptrace.o.
* configure.tgt (aarch64*-*-linux*): Add arch/aarch64-mte-linux.o.
* nat/aarch64-mte-linux-ptrace.c: New file.
* nat/aarch64-mte-linux-ptrace.h: New file.
Luis Machado [Mon, 15 Jun 2020 16:59:40 +0000 (13:59 -0300)]
AArch64: Add MTE register set support for GDB and gdbserver
AArch64 MTE support in the Linux kernel exposes a new register
through ptrace. This patch adds the required code to support it.
include/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* elf/common.h (NT_ARM_TAGGED_ADDR_CTRL): Define.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* aarch64-linux-nat.c (fetch_mteregs_from_thread): New function.
(store_mteregs_to_thread): New function.
(aarch64_linux_nat_target::fetch_registers): Update to call
fetch_mteregs_from_thread.
(aarch64_linux_nat_target::store_registers): Update to call
store_mteregs_to_thread.
* aarch64-tdep.c (aarch64_mte_register_names): New struct.
(aarch64_cannot_store_register): Handle MTE registers.
(aarch64_gdbarch_init): Initialize and setup MTE registers.
* aarch64-tdep.h (gdbarch_tdep) <mte_reg_base>: New field.
<has_mte>: New method.
* arch/aarch64-linux.h (AARCH64_LINUX_SIZEOF_MTE): Define.
gdbserver/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* linux-aarch64-low.cc (aarch64_fill_mteregset): New function.
(aarch64_store_mteregset): New function.
(aarch64_regsets): Add MTE register set entry.
(aarch64_sve_regsets): Add MTE register set entry.
Luis Machado [Mon, 15 Jun 2020 16:52:27 +0000 (13:52 -0300)]
AArch64: Add target description/feature for MTE registers
This patch adds a target description and feature "mte" for aarch64.
It includes one new register, tag_ctl, that can be used to configure the
tag generation rules and sync/async modes. It is 64-bit in size.
The patch also adjusts the code that creates the target descriptions at
runtime based on CPU feature checks.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* aarch64-linux-nat.c
(aarch64_linux_nat_target::read_description): Take MTE flag into
account.
Slight refactor to hwcap flag checking.
* aarch64-linux-tdep.c
(aarch64_linux_core_read_description): Likewise.
* aarch64-tdep.c (tdesc_aarch64_list): Add one more dimension for
MTE.
(aarch64_read_description): Add mte_p parameter and update to use it.
Update the documentation.
(aarch64_gdbarch_init): Update call to aarch64_read_description.
* aarch64-tdep.h (aarch64_read_description): Add mte_p parameter.
* arch/aarch64.c: Include ../features/aarch64-mte.c.
(aarch64_create_target_description): Add mte_p parameter and update
the code to use it.
* arch/aarch64.h (aarch64_create_target_description): Add mte_p
parameter.
* features/Makefile (FEATURE_XMLFILES): Add aarch64-mte.xml.
* features/aarch64-mte.c: New file, generated.
* features/aarch64-mte.xml: New file.
gdbserver/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* linux-aarch64-ipa.cc (get_ipa_tdesc): Update call to
aarch64_linux_read_description.
(initialize_low_tracepoint): Likewise.
* linux-aarch64-low.cc (aarch64_target::low_arch_setup): Take MTE flag
into account.
* linux-aarch64-tdesc.cc (tdesc_aarch64_list): Add one more dimension
for MTE.
(aarch64_linux_read_description): Add mte_p parameter and update to
use it.
* linux-aarch64-tdesc.h (aarch64_linux_read_description): Add mte_p
parameter.
Luis Machado [Mon, 15 Jun 2020 16:39:30 +0000 (13:39 -0300)]
AArch64: Add MTE CPU feature check support
This patch is a preparation for the next patches implementing MTE. It just adds
a HWCAP2 constant for MTE, creates a new generic arch/aarch64-mte-linux.h file
and includes that file in the source files that will use it.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* Makefile.in (HFILES_NO_SRCDIR): Add arch/aarch64-mte-linux.h.
* aarch64-linux-nat.c: Include arch/aarch64-mte-linux.h.
* aarch64-linux-tdep.c: Likewise
* arch/aarch64-mte-linux.h: New file.
gdbserver/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* linux-aarch64-low.cc: Include arch/aarch64-mte-linux.h.
Luis Machado [Mon, 15 Jun 2020 18:18:55 +0000 (15:18 -0300)]
Add GDB-side remote target support for memory tagging
This patch adds memory tagging support to GDB's remote side, with
packet string checks, new packet support and an implementation of
the two new tags methods fetch_memtags and store_memtags.
GDBserver needs to know how to read/write allocation tags, since that is
done via ptrace. It doesn't need to know about logical tags.
The new packets are:
qMemTags:<address>,<length>:<type>
--
Reads tags of the specified type from the address range
[<address>, <address + length>)
QMemTags:<address>,<length>:<type>:<uninterpreted tag bytes>
--
Writes the tags of specified type represented by the uninterpreted bytes to
the address range [<address>, <address + length>).
The interpretation of what to do with the tag bytes is up to the arch-specific
code.
Note that these new packets consider the case of packet size overflow as an
error, given the common use case is to read/write only a few memory tags at
a time. Having to use a couple new packets for multi-part transfers wouldn't
make sense for the little use it would have.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* remote.c (PACKET_memory_tagging_feature): New enum.
(remote_memory_tagging_p): New function.
(remote_protocol_features): New "memory-tagging" entry.
(remote_target::remote_query_supported): Handle memory tagging
support.
(remote_target::supports_memory_tagging): Implement.
(create_fetch_memtags_request, parse_fetch_memtags_reply)
(create_store_memtags_request): New functions.
(remote_target::fetch_memtags): Implement.
(remote_target::store_memtags): Implement.
(_initialize_remote): Add new "memory-tagging-feature"
config command.
Luis Machado [Fri, 19 Jun 2020 20:36:14 +0000 (17:36 -0300)]
New gdbarch memory tagging hooks
We need some new gdbarch hooks to help us manipulate memory tags without having
to have GDB call the target methods directly.
This patch adds the following hooks:
gdbarch_memtag_to_string
--
Returns a printable string corresponding to the tag.
gdbarch_tagged_address_p
--
Checks if a particular address is protected with memory tagging.
gdbarch_memtag_matches_p
--
Checks if the logical tag of a pointer and the allocation tag from the address
the pointer points to matches.
gdbarch_set_memtags:
--
Sets either the allocation tag or the logical tag for a particular value.
gdbarch_get_memtag:
--
Gets either the allocation tag or the logical tag for a particular value.
gdbarch_memtag_granule_size
--
Sets the memory tag granule size, which represents the number of bytes a
particular allocation tag covers. For example, this is 16 bytes for
AArch64's MTE.
I've used struct value as opposed to straight CORE_ADDR so other architectures
can use the infrastructure without having to rely on a particular type for
addresses/pointers. Some architecture may use pointers of 16 bytes that don't
fit in a CORE_ADDR, for example.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* arch-utils.c (default_memtag_to_string, default_tagged_address_p)
(default_memtag_matches_p, default_set_memtags)
(default_get_memtag): New functions.
* arch-utils.h (default_memtag_to_string, default_tagged_address_p)
(default_memtag_matches_p, default_set_memtags)
(default_get_memtag): New prototypes.
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbarch.sh (memtag_to_string, tagged_address_p, memtag_matches_p)
(set_memtags, get_memtag, memtag_granule_size): New gdbarch hooks.
(enum memtag_type): New enum.
Jan Beulich [Wed, 24 Mar 2021 07:33:33 +0000 (08:33 +0100)]
x86: derive opcode length from opcode value
In the majority of cases we can easily determine the length from the
encoding, irrespective of whether a prefix is specified there as well.
We further don't even need to record the value in the table entries, as
it's easy enough to determine it (without any guesswork, unless an insn
with major opcode 00 appeared that requires a 2nd opcode byte to be
specified explicitly) when installing the chosen template for further
processing.
Should an encoding appear which
- has a major opcode byte of 66, F3, or F2,
- requires a 2nd opcode byte to be specified explicitly,
- doesn't have a mandatory prefix
we'd need to convert all templates presently encoding a mandatory prefix
this way to the Prefix_0X<nn> model to eliminate the respective guessing
i386-gen does.
Jan Beulich [Wed, 24 Mar 2021 07:32:32 +0000 (08:32 +0100)]
x86: derive mandatory prefix attribute from base opcode
Just like is already done for legacy encoded insns, record the mandatory
prefix information in the respective opcode modifier field. Do this
without changing the source table, but rather by deriving the values from
their existing source representation.
Jan Beulich [Wed, 24 Mar 2021 07:31:41 +0000 (08:31 +0100)]
x86: don't use opcode_length to identify pseudo prefixes
This is in preparation of opcode_length going away as a field in the
templates. Identify pseudo prefixes by a base opcode of zero instead:
No real prefix has an opcode of zero. This at the same time allows
dropping a curious special case from i386-gen.
Since most attributes are identical for all pseudo prefixes, take the
opportunity and also template them.
Jan Beulich [Tue, 23 Mar 2021 16:09:53 +0000 (17:09 +0100)]
x86: re-number PREFIX_0X<nn>
In preparation to use PREFIX_0X<nn> attributes also in VEX/XOP/EVEX
encoding templates, renumber the pseudo-enumerators such that their
values can then also be used directly in the respective prefix bit
fields.
Jan Beulich [Tue, 23 Mar 2021 16:08:39 +0000 (17:08 +0100)]
x86: split opcode prefix and opcode space representation
Commit 8b65b8953af2 ("x86: Remove the prefix byte from non-VEX/EVEX
base_opcode") used the opcodeprefix field for two distinct purposes. In
preparation of having VEX/XOP/EVEX and non-VEX templates become similar
in the representatioon of both encoding space and opcode prefixes, split
the field to have a separate one holding an insn's opcode space.
Simon Marchi [Tue, 23 Mar 2021 13:50:32 +0000 (09:50 -0400)]
gdb: remove unpush_target free function
unpush_target unpushes the passed-in target from the current inferior's
target stack. Calling it is therefore an implicit dependency on the
current global inferior. Remove that function and make the callers use
the inferior::unpush_target method directly. This sometimes allows
using the inferior from the context rather than the global current
inferior.
target_unpusher::operator() now needs to be implemented in target.c,
otherwise target.h and inferior.h both need to include each other, and
that wouldn't work.
gdb/ChangeLog:
* target.h (unpush_target): Remove, update all callers
to use `inferior::unpush_target` instead.
(struct target_unpusher) <operator()>: Just declare.
* target.c (unpush_target): Remove.
(target_unpusher::operator()): New.
projects / thirdparty / binutils-gdb.git / log
