Add an observable notified in target_detach just before calling the
detach method on the inferior's target stack. This allows observer to
do some work on the inferior while it's still ptrace-attached, in the
case of a native Linux inferior. Specifically, the amd-dbgapi target
will need it in order to call amd_dbgapi_process_detach before the
process gets ptrace-detached.
Change-Id: I28b6065e251012a4c2db8a600fe13ba31671e3c9
Approved-By: Andrew Burgess <aburgess@redhat.com>
A following patch will want to declare variables of the same type as
some ptid_t components. To make that easy (and avoid harcoding those
types everywhere), define some type definitions in the ptid_t struct for
each of them. Use them throughout ptid.h.
I initially used pid_t, lwp_t and tid_t, but there is the risk of some
system defining the pid_t type using a macro instead of a typedef, which
would break things. So, use the _type suffix instead.
Change-Id: I820b0bea9dafcb4914f1c9ba4bb96b5c666c8dec
Approved-By: Andrew Burgess <aburgess@redhat.com>
A following patch will want to install a breakpoint and then keep a
non-owning reference to it. Make install_breakpoint return a non-owning
reference, to make that easy.
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I2e8106a784021ff276ce251e24708cbdccc2d479
Approved-By: Andrew Burgess <aburgess@redhat.com>
In the ROCm GDB port, there are some amdgcn architectures known by BFD
that we don't actually support in GDB. We don't want
gdbarch_printable_names to return these architectures.
gdbarch_printable_names is used for a few things:
- completion of the "set architecture" command
- the gdb.architecture_names function in Python
- foreach-arch selftests
Add an optional callback to gdbarch_register that is a predicate
indicating whether the gdbarch supports the given bfd_arch_info. by
default, it is nullptr, meaning that the gdbarch accepts all "mach"s for
that architecture known by BFD.
Change-Id: I712f94351b0b34ed1f42e5cf7fc7ba051315d860
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
GDB has been converted to a C++ program for many years[1], and the
gdb_indent.sh will not be used any more. Therefore, remove the script as
obvious.
[1] https://sourceware.org/gdb/wiki/cxx-conversion
Approved-By: Simon Marchi <simark@simark.ca>
SFrame format is meant for generating stack traces only.
bfd/
* elf-bfd.h: Replace the use of "unwind" with "stack trace".
* elf-sframe.c: Likewise.
* elf64-x86-64.c: Likewise.
* elfxx-x86.c: Likewise.
include/
* elf/common.h: Likewise.
The merge test fais on numerous targets because they don't support the
necessary pc-relative relocs. This patch removes that part of the
merge test, and makes references to the merged strings from .data
rather than .text to better support targets that relax text by
default.
Don't define this. It is defined just before elf-bfd.h is included,
but doesn't have any relevance there. Instead is for aout64.h where
the default is 4 anyway.
Provide a way for config/obj-* to clean up at end of assembly, and do
so for ELF.
* obj.h (struct format_ops): Add "end".
* config/obj-aout.c (aout_format_ops): Init new field.
* config/obj-coff.c (coff_format_ops): Likewise.
* config/obj-ecoff.c (ecoff_format_ops): Likewise.
* config/obj-elf.c (elf_format_ops): Likewise.
(elf_begin): Move later in file. Clear some more variables.
(comment_section): Make file scope.
(free_section_idx): Rewrite.
(elf_adjust_symtab): Expand str_htab_create call and use
free_section_idx as delete function.
(elf_frob_file_after_relocs): Don't clean up groups.indexes here.
(elf_end): New function.
* config/obj-elf.h (obj_end): Define.
* config/obj-multi.h (obj_end): Define.
* output-file.c (output_file_close): Call obj_end.
This patch doesn't change gdbserver behaviour, but after later changes are
made it avoids a null pointer dereference when HWCAP needs to be obtained
for a specific process while current_thread is nullptr.
Fixing linux_read_auxv, linux_get_hwcap and linux_get_hwcap2 to take a PID
parameter seems more correct than setting current_thread in one particular
code path.
Changes are propagated to allow passing the new parameter through the call
chain.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
It helped me during development, catching bugs closer to when they actually
happened.
Also remove the equivalent gdb_assert in regcache_raw_read_unsigned, since
it's checking the same condition a few frames above.
Suggested-By: Simon Marchi <simon.marchi@efficios.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
I noticed that the gdb.debuginfod/fetch_src_and_symbols.exp script
doesn't work with the native-gdbserver board, I see this error:
ERROR: tcl error sourcing /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.debuginfod/fetch_src_and_symbols.exp.
ERROR: gdbserver does not support run without extended-remote
while executing
"error "gdbserver does not support $command without extended-remote""
(procedure "gdb_test_multiple" line 51)
invoked from within
This was introduced with this commit:
commit 7dd38e31d6
Date: Fri Jan 6 18:45:27 2023 -0500
gdb/linespec.c: Fix missing source file during breakpoint re-set
The problem is that the above commit introduces a direct use of the
"run" command, which doesn't work with 'target remote' targets, as
exercised by the native-gdbserver board.
To avoid this, in this commit I switch to using runto_main. However,
calling runto_main will, by default, delete all the currently set
breakpoints. As the point of the above commit was to check that a
breakpoint set before stating an inferior would be correctly re-set,
we need to avoid this breakpoint deleting behaviour.
To do this I make use of with_override, and override the
delete_breakpoints proc with a dummy proc which does nothing.
By reverting the GDB changes in commit 7dd38e31d6 I have confirmed
that even after my changes in this commit, the test still fails. But
with the fixes in commit 7dd38e31d6, this test now passed using the
unix, native-gdbserver, and native-extended-gdbserver boards.
Currently, when GDB loads debug information from a separate debug
file, there are a couple of warnings that could be produced if things
go wrong.
In find_separate_debug_file_by_buildid (build-id.c) GDB can give a
warning if the separate debug file doesn't include any actual debug
information, and in separate_debug_file_exists (symfile.c) we can warn
if the CRC checksum in the separate debug file doesn't match the
checksum in the original executable.
The problem here is that, when looking up debug information, GDB will
try several different approaches, lookup by build-id, lookup by
debug-link, and then a lookup from debuginfod. GDB can potentially
give a warning from an earlier attempt, and then succeed with a later
attempt. In the cases I have run into this is primarily a warning
about some out of date debug information on my machine, but then GDB
finds the correct information using debuginfod. This can be confusing
to a user, they will see warnings from GDB when really everything is
working just fine.
For example:
warning: the debug information found in "/usr/lib/debug//lib64/ld-2.32.so.debug" \
does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).
This diagnostic was printed on Fedora 33 even when the correct
debuginfo was downloaded.
In this patch I propose that we defer any warnings related to looking
up debug information from a separate debug file. If any of the
approaches are successful then GDB will not print any of the warnings.
As far as the user is concerned, everything "just worked". Only if
GDB completely fails to find any suitable debug information will the
warnings be printed.
The crc_mismatch test compiles two executables: crc_mismatch and
crc_mismatch-2 and then strips them of debuginfo creating separate
debug files. The test then replaces crc_mismatch-2.debug with
crc_mismatch.debug to trigger "CRC mismatch" warning. A local
debuginfod server is setup to supply the correct debug file, now when
GDB looks up the debug info no warning is given.
The build-id-no-debug-warning.exp is similar to the previous test. It
triggers the "separate debug info file has no debug info" warning by
replacing the build-id based .debug file with the stripped binary and
then loading it to GDB. It then also sets up local debuginfod server
with the correct debug file to download to make sure no warnings are
emitted.
This function has a gas_assert, ie. possible call to as_abort, which
calls as_report_context, which calls as_info_where.
* messages.c (as_info_where): Don't gas_assert.
I propose to rename cooked_index_vector and cooked_index such that the
"main" object, that is the entry point to the index, is called
cooked_index. The fact that the cooked index is implemented as a vector
of smaller indexes is an implementation detail.
This patch renames cooked_index to cooked_index_shard. The following
patch renames cooked_index_vector to cooked_index.
Change-Id: Id650f97dcb23c48f8409fa0974cd093ca0b75177
Approved-By: Tom Tromey <tom@tromey.com>
Currently, when using -gdwarf-2, gas emits a v3 .debug_line contribution.
Fix this by emitting a v2 .debug_line contribution instead.
gas/ChangeLog:
2023-01-31 Tom de Vries <tdevries@suse.de>
PR 23941
* dwarf2dbg.c (DWARF2_LINE_VERSION): Set to 2 for -gdwarf-2.
(DWARF2_LINE_OPCODE_BASE): Handle DWARF2_LINE_VERSION == 2.
(dwarf2_directive_loc): Bump dwarf_level when encountering
v3 .loc options.
(out_debug_line): Don't output v3 standard opcodes for v2.
* testsuite/gas/i386/debug1.d: Update.
* testsuite/gas/i386/dwarf2-line-1.d: Update.
* testsuite/gas/i386/dwarf2-line-4.d: Update.
Since commit 7d82b08e9e ("gdb/dwarf: dump cooked index contents in
cooked_index_functions::dump"), we see:
maint print objfiles /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-error/dw2-error^M
^M
Object file /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-error/dw2-error: Objfile at 0x614000005040, bfd at 0x6120000e08c0, 15 minsyms^M
^M
Cooked index in use:^M
^M
/home/smarchi/src/binutils-gdb/gdb/../gdbsupport/gdb-checked-static-cast.h:58: internal-error: checked_static_cast: Assertion `result != nullptr' failed.^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
----- Backtrace -----^M
FAIL: gdb.dwarf2/dw2-error.exp: maint print objfiles /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-error/dw2-error (GDB internal error)
The problem is that when cooked_index_functions fails to build an index,
per_objfile->index_table is nullptr. Therefore, add a nullptr check,
like other methods of cooked_index_functions already do.
Print the "Cooked index in use" message after the nullptr check, such
that if the cooked index failed to build, that message is not printed.
Change-Id: Id67aef592e76c41b1e3bde9838a4e36cef873253
Both static_cast and dynamic_cast handle nullptr (they return nullptr),
so I think checked_static_cast should too. This will allow doing a null
check after a checked_static_cast:
cooked_index_vector *table
= (gdb::checked_static_cast<cooked_index_vector *>
(per_bfd->index_table.get ()));
if (table != nullptr)
return;
Change-Id: If5c3134e63696f8e417c87b5f3901240c9f7ea97
Following 7d82b08e9e ("gdb/dwarf: dump cooked index contents in
cooked_index_functions::dump"), I see some failures like:
(gdb) mt print objfiles with-mf^M
^M
Object file /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/with-mf/with-mf: Objfile at 0x614000005040, bfd at 0x6120000e08c0, 18 minsyms ^M
^M
Cooked index in use:^M
^M
...
(gdb) FAIL: gdb.base/with-mf.exp: check if index present
This is because the format of the "Cooked index in use" line changed
slightly. Adjust ensure_gdb_index to expect the trailing colon.
Change-Id: If0a87575c02d8a0bc0d4b8ead540c234c62760f8
I see:
ERROR: wrong # args: should be "xfail message"
while executing
"xfail "no debug info" $gdb_test_name"
("uplevel" body line 3)
invoked from within
"uplevel {
if {!$has_runtime_debug_info} {
xfail "no debug info" $gdb_test_name
} else {
fail $gdb_test_name
}
}"
This is because the xfail takes only one argument, fix that.
Change-Id: I2e304d4fd3aa61067c04b5dac2be2ed34dab3190
Revert 1c66b8a039 and instead fix the broken list pointer.
PR 29998
* pe-dll.c (build_filler_bfd): Revert last change.
* ldlang.c (lang_process): When rescanning archives for lto,
fix file_chain.tail pointer if the insert point happens to be
at the end of the list.
I noticed that some of the Power6 DFP instructions were not covered by
the assembler tests. I've added a new test file which I believe
covers all the DFP Power6 instructions.
The existing gas/testsuite/gas/ppc/power6.d test is called:
POWER6 tests (includes DFP and Altivec)
And does cover some of the DFP instructions. But, given the number of
additional instructions I'm adding I opted to add a whole new test
file. I've left the original power6.d unchanged, so there is now some
overlap, but I don't think that should hurt much.
Along with the normal JAL alias, the C-extension one should have been
moved as well by 839189bc93 ("RISC-V: re-arrange opcode table for
consistent alias handling"), for the assembler to actually be able to
use it where/when possible.
Since neither this nor any other compressed branch insn was being tested
so far, take the opportunity and introduce a new testcase covering those.
After bfd_close nothing should access bfd memory. Now that bfd_close
always tidies up even after an error, attempting to tidy the cached
bfd list by calling bfd_cache_close is wrong and not needed.
PR 30060
* ar.c (remove_output): Don't call bfd_cache_close.
(output_bfd): Delete.
* arsup.c (ar_end): Call bfd_close_all_done, not bfd_cache_close.
This adjusts the testsuite to get rid of a number of XPASSes that have
appeared. Someone might like to look into a better patch for the s390
change.
aarch64-pe XPASS: weak symbols
arm-nacl XPASS: rgn-over8
mcore-pe XPASS: ld-scripts/provide-8
mips64-linux-gnuabi64 XPASS: vers4
mips64-linux-gnuabi64 XPASS: vers4b
mips-linux-gnu XPASS: vers4
mips-linux-gnu XPASS: vers4b
s390-linux-gnu XPASS: undefined line
sh4-linux-gnu XPASS: --gc-sections with __start_SECTIONNAME
sh-coff XPASS: objcopy object (simple copy)
sh-coff XPASS: objcopy executable (pr25662)
binutils/
* testsuite/binutils-all/objcopy.exp: Don't xfail "simple
copy" and "pr25662" on sh-*-coff. Remove all non-ELF xfails
on "ELF unknown section type" test.
ld/
* testsuite/ld-elfvers/vers.exp (vers4, vers4b): Don't xfail
all mips, just xfail mips irix.
* testsuite/ld-gc/pr19161.d: Don't xfail sh.
* testsuite/ld-scripts/rgn-over8-ok.d: Don't xfail nacl.
* testsuite/ld-scripts/weak.exp: Don't xfail aarch64-pe.
* testsuite/ld-undefined/undefined.exp: Conditionally xfail
"undefined line" depending on gcc version for s390.
The i386 builder shows:
../../binutils-gdb/gdb/dwarf2/cooked-index.c: In member function ‘void cooked_index_vector::dump(gdbarch*) const’:
../../binutils-gdb/gdb/dwarf2/cooked-index.c:492:40: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘std::__underlying_type_impl<sect_offset, true>::type’ {aka ‘long long unsigned int’} [-Werror=format=]
492 | gdb_printf (" DIE offset: 0x%lx\n",
| ~~^
| |
| long unsigned int
| %llx
493 | to_underlying (entry->die_offset));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| std::__underlying_type_impl<sect_offset, true>::type {aka long long unsigned int}
The die_offset's underlying type is uint64, so use PRIx64 in the format
string.
Change-Id: Ibdde4c624ed1bb50eced9a514a4e37aec70a1323
For some reason g++ 12.2.1 on sparc produces spurious warnings for
stringop-overread and restrict in fbsd-tdep.c for a memcpy call.
Use std::copy to avoid the warnings:
In function ‘void* memcpy(void*, const void*, size_t)’,
inlined from ‘gdb::optional<std::vector<unsigned char, gdb::default_init_allocator<unsigned char, std::allocator<unsigned char> > > > fbsd_make_note_desc(target_object, uint32_t)’ at ../../binutils-gdb/gdb/fbsd-tdep.c:666:10:
/usr/include/bits/string_fortified.h:29:33: error: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ specified bound 18446744073709551612 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=]
In function ‘void* memcpy(void*, const void*, size_t)’,
inlined from ‘gdb::optional<std::vector<unsigned char, gdb::default_init_allocator<unsigned char, std::allocator<unsigned char> > > > fbsd_make_note_desc(target_object, uint32_t)’ at ../../binutils-gdb/gdb/fbsd-tdep.c:673:10:
/usr/include/bits/string_fortified.h:29:33: error: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ accessing 18446744073709551612 bytes at offsets 0 and 0 overlaps 9223372036854775801 bytes at offset -9223372036854775805 [-Werror=restrict]
gdb/ChangeLog:
* fbsd-tdep.c (fbsd_make_note_desc): Use std::copy instead
of memcpy.
As I am investigating a crash I see with the cooked index, I thought it
would be useful to have a way to dump the index contents. For those not
too familiar with it (that includes me), it can help get a feel of what
it contains and how it is structured.
The cooked_index_functions::dump function is called as part of the
"maintenance print objfiles" command. I tried to make the output
well structured and indented to help readability, as this prints a lot
of text.
The dump function first dumps all cooked index entries, like this:
[25] ((cooked_index_entry *) 0x621000121220)
name: __ioinit
canonical: __ioinit
DWARF tag: DW_TAG_variable
flags: 0x2 [IS_STATIC]
DIE offset: 0x21a4
parent: ((cooked_index_entry *) 0x6210000f9610) [std]
Then the information about the main symbol:
main: ((cooked_index_entry *) 0x621000123b40) [main]
And finally the address map contents:
[1] ((addrmap *) 0x6210000f7910)
[0x0] ((dwarf2_per_cu_data *) 0)
[0x118a] ((dwarf2_per_cu_data *) 0x60c000007f00)
[0x1cc7] ((dwarf2_per_cu_data *) 0)
[0x1cc8] ((dwarf2_per_cu_data *) 0x60c000007f00)
[0x1cdf] ((dwarf2_per_cu_data *) 0)
[0x1ce0] ((dwarf2_per_cu_data *) 0x60c000007f00)
The display of address maps above could probably be improved, to show it
more as ranges, but I think this is a reasonable start.
Note that this patch depends on Pedro Alves' patch "enum_flags
to_string" [1]. If my patch is to be merged before Pedro's series, I
will cherry-pick this patch from his series and merge it before mine.
[1] https://inbox.sourceware.org/gdb-patches/20221212203101.1034916-8-pedro@palves.net/
Change-Id: Ida13e479fd4c8d21102ddd732241778bc3b6904a
This commit introduces shared infrastructure that can be used to
implement enum_flags -> to_string functions. With this, if we want to
support converting a given enum_flags specialization to string, we
just need to implement a function that provides the enumerator->string
mapping, like so:
enum some_flag
{
SOME_FLAG1 = 1 << 0,
SOME_FLAG2 = 1 << 1,
SOME_FLAG3 = 1 << 2,
};
DEF_ENUM_FLAGS_TYPE (some_flag, some_flags);
static std::string
to_string (some_flags flags)
{
static constexpr some_flags::string_mapping mapping[] = {
MAP_ENUM_FLAG (SOME_FLAG1),
MAP_ENUM_FLAG (SOME_FLAG2),
MAP_ENUM_FLAG (SOME_FLAG3),
};
return flags.to_string (mapping);
}
.. and then to_string(SOME_FLAG2 | SOME_FLAG3) produces a string like
"0x6 [SOME_FLAG2 SOME_FLAG3]".
If we happen to forget to update the mapping array when we introduce a
new enumerator, then the string representation will pretty-print the
flags it knows about, and then the leftover flags in hex (one single
number). For example, if we had missed mapping SOME_FLAG2 above, we'd
end up with:
to_string(SOME_FLAG2 | SOME_FLAG3) => "0x6 [SOME_FLAG2 0x4]");
Other than in the unit tests included, no actual usage of the
functionality is added in this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I835de43c33d13bc0c95132f42c3f97318b875779
Simon pointed out that the cooked index template-matching patch
introduced a failure in libstdc++ debug mode. In particular, the new
code violates the assumption of std::lower_bound and std::upper_bound
that the range is sorted with respect to the comparison.
When I first debugged this, I thought the problem was unfixable as-is
and that a second layer of filtering would have to be done. However,
on irc, Simon pointed out that it could perhaps be solved if the
comparison function were assured that one operand always came from the
index, with the other always being the search string.
This patch implements this idea.
First, a new mode is introduced: a sorting mode for
cooked_index_entry::compare. In this mode, strings are compared
case-insensitively, but we're careful to always sort '<' before any
other printable character. This way, two names like "func" and
"func<param>" will be sorted next to each other -- i.e., "func1" will
not be seen between them. This is important when searching.
Second, the compare function is changed to work in a strcmp-like way.
This makes it easier to test and (IMO) understand.
Third, the compare function is modified so that in non-sorting modes,
the index entry is always the first argument. This allows consistency
in compares.
I regression tested this in libstdc++ debug mode on x86-64 Fedora 36.
It fixes the crash that Simon saw.
This is v2. I believe it addresses the review comments, except for
the 'enum class' change, as I mentioned in email on the list.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This changes the lnp_state_machine constructor to initialize members
directly; and changes lnp_state_machine itself to initialize members
inline when possible.
Reviewed-By: Lancelot Six <lancelot.six@amd.com>
Users of addrmap::find and addrmap::foreach that have a const addrmap
should ideally receive const pointers to objects, to indicate they
should not be modified. However, users that have a non-const addrmap
should still receive a non-const pointer.
To achieve this, without adding more virtual methods, make the existing
find and foreach virtual methods private and prefix them with "do_".
Add small non-const and const wrappers for find and foreach.
Obviously, the const can be cast away, but if using static_cast
instead of C-style casts, then the compiler won't let you cast
the const away. I changed all the callers of addrmap::find and
addrmap::foreach I could find to make them use static_cast.
Change-Id: Ia8e69d022564f80d961413658fe6068edc71a094
The workaround for the vCont packet is no longer required due to the
former commit "gdb: Make global feature array a per-remote target array".
The vCont packet is now checked once when the connection is started and
the supported vCont actions are set to the target's remote state
attribute.
This patch adds per-remote target variables for the configuration of
memory read- and write packet size. It is a further change to commit
"gdb: Make global feature array a per-remote target array" to apply the
fixme notes described in commit 5b6d1e4 "Multi-target support".
The former global variables for that configuration are still available
to allow the command line configuration for all future remote
connections. Similar to the command line configuration of the per-
remote target feature array, the commands
- set remotewritesize (deprecated)
- set remote memory-read-packet-size
- set remote memory-write-packet-size
will configure the current target (if available). If no target is
available, the default configuration for future remote connections is
adapted. The show command will display the current remote target's
packet size configuration. If no remote target is selected, the default
configuration for future connections will be shown.
It is required to adapt the test gdb.base/remote.exp which is failing
for --target_board=native-extended-gdbserver. With that board GDB
connects to gdbserver at gdb start time. Due to this patch two loggings
"The target may not be able to.." are shown if the command 'set remote
memory-write-packet-size fixed' is executed while a target is connected
for the current inferior. To fix this, the clean_restart command is
moved to a later time point of the test. It is sufficient to be
connected to the server when "runto_main" is executed. Now the
connection time is similar to a testrun with
--target_board=native-gdbserver.
To allow the user to distinguish between the packet-size configuration
for future remote connections and for the currently selected target, the
commands' loggings are adapted.
This patch applies the appropriate FIXME notes described in commit 5b6d1e4
"Multi-target support".
"You'll notice that remote.c includes some FIXME notes. These refer to
the fact that the global arrays that hold data for the remote packets
supported are still globals. For example, if we connect to two
different servers/stubs, then each might support different remote
protocol features. They might even be different architectures, like
e.g., one ARM baremetal stub, and a x86 gdbserver, to debug a
host/controller scenario as a single program. That isn't going to
work correctly today, because of said globals. I'm leaving fixing
that for another pass, since it does not appear to be trivial, and I'd
rather land the base work first. It's already useful to be able to
debug multiple instances of the same server (e.g., a distributed
cluster, where you have full control over the servers installed), so I
think as is it's already reasonable incremental progress."
Using this patch it is possible to configure per-remote targets'
feature packets.
Given the following setup for two gdbservers:
~~~~
gdbserver --multi :1234
gdbserver --disable-packet=vCont --multi :2345
~~~~
Before this patch configuring of range-stepping was not possible for one
of two connected remote targets with different support for the vCont
packet. As one of the targets supports vCont, it should be possible to
configure "set range-stepping". However, the output of GDB looks like:
(gdb) target extended-remote :1234
Remote debugging using :1234
(gdb) add-inferior -no-connection
[New inferior 2]
Added inferior 2
(gdb) inferior 2
[Switching to inferior 2 [<null>] (<noexec>)]
(gdb) target extended-remote :2345
Remote debugging using :2345
(gdb) set range-stepping on
warning: Range stepping is not supported by the current target
(gdb) inferior 1
[Switching to inferior 1 [<null>] (<noexec>)]
(gdb) set range-stepping on
warning: Range stepping is not supported by the current target
~~~~
Two warnings are shown. The warning for inferior 1 should not appear
as it is connected to a target supporting the vCont package.
~~~~
(gdb) target extended-remote :1234
Remote debugging using :1234
(gdb) add-inferior -no-connection
[New inferior 2]
Added inferior 2
(gdb) inferior 2
[Switching to inferior 2 [<null>] (<noexec>)]
(gdb) target extended-remote :2345
Remote debugging using :2345
(gdb) set range-stepping on
warning: Range stepping is not supported by the current target
(gdb) inferior 1
[Switching to inferior 1 [<null>] (<noexec>)]
(gdb) set range-stepping on
(gdb)
~~~~
Now only one warning is shown for inferior 2, which is connected to
a target not supporting vCont.
The per-remote target feature array is realized by a new class
remote_features, which stores the per-remote target array and
provides functions to determine supported features of the target.
A remote_target object now has a new member of that class.
Each time a new remote_target object is initialized, a new per-remote
target array is constructed based on the global remote_protocol_packets
array. The global array is initialized in the function _initialize_remote
and can be configured using the command line. Before this patch the
command line configuration affected current targets and future remote
targets (due to the global feature array used by all remote
targets). This behavior is different and the configuration applies as
follows:
- If a target is connected, the command line configuration affects the
current connection. All other existing remote targets are not
affected.
- If not connected, the command line configuration affects future
connections.
The show command displays the current remote target's configuration. If no
remote target is selected the default configuration for future
connections is shown.
If we have for instance the following setup with inferior 2 being
selected:
~~~~
(gdb) info inferiors
Num Description Connection Executable
1 <null> 1 (extended-remote :1234)
* 2 <null> 2 (extended-remote :2345)
~~~~
Before this patch, if we run 'set remote multiprocess-feature-packet', the
following configuration was set:
The feature array of all remote targets (in this setup the two connected
targets) and all future remote connections are affected.
After this patch, it will be configured as follows:
The feature array of target with port :2345 which is currently selected
will be configured. All other existing remote targets are not affected.
The show command 'show remote multiprocess-feature-packet' will display
the configuration of target with port :2345.
Due to this configuration change, it is required to adapt the test
"gdb/testsuite/gdb.multi/multi-target-info-inferiors.exp" to configure the
multiprocess-feature-packet before the connections are created.
To inform the gdb user about the new behaviour of the 'show remote
PACKET-NAME' commands and the new configuration impact for remote
targets using the 'set remote PACKET-NAME' commands the commands'
outputs are adapted. Due to this change it is required to adapt each
test using the set/show remote 'PACKET-NAME' commands.
