While building gdbserver on GNU/Linux, the build failed with:
../../../binutils-gdb/gdb/gdbserver/linux-x86-tdesc.c: In function ‘const target_desc* amd64_linux_read_description(uint64_t, bool)’:
../../../binutils-gdb/gdb/gdbserver/linux-x86-tdesc.c:121:67: error: too few arguments to function ‘target_desc* amd64_create_target_description(uint64_t, bool, bool, bool)’
*tdesc = amd64_create_target_description (xcr0, is_x32, true);
^
In file included from ../../../binutils-gdb/gdb/gdbserver/linux-x86-tdesc.c:26:0:
../../../binutils-gdb/gdb/gdbserver/../arch/amd64.h:21:14: note: declared here
target_desc *amd64_create_target_description (uint64_t xcr0, bool is_x32,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
According to Joel Brobecker:
> I think the parameter should be set to "true". Otherwise, it will
> not include the fs_base and gs_base register in the list of registers.
> Although the name of the source file says x86, the code itself is
> protected by...
>
> #ifdef __x86_64__
>
> ... and is inside a function called amd64_linux_read_description.
> I also verified that this file gets compiled on amd64-linux platforms.
> See gdb/gdbserver/configure.srv:
>
> x86_64-*-linux*) srv_regobj="$srv_amd64_linux_regobj $srv_i386_linux_regobj"
>
> The last piece of confirmation is that setting the parameter to "true"
> provides the behavior before the parameter was added; and the reason
> for adding the parameter was to remove the {fs,gs}_base registers
> from the list for Windows only.
Therefore I'm pushing the patch to unbreak the build.
gdb/gdbserver/ChangeLog:
2018-06-29 Joel Brobecker <brobecker@adacore.com>
* linux-x86-tdesc.c (amd64_linux_read_description): Add missing
parameter in call to 'amd64_create_target_description'.
GDB is currently crashing anytime we try to access the fs_base/gs_base
registers, either to read them, or to write them. This can be observed
under various scenarios:
- Explicit reference to those registers (eg: print $fs_base) --
probably relatively rare;
- Calling a function in the inferior, with the crash happening
because we are trying to read those registers in order to save
their value ahead of making the function call;
- Just a plain "info registers";
The crash was introduced by the following commit:
| commit 48aeef91c2
| Date: Mon Jun 26 18:14:43 2017 -0700
| Subject: Include the fs_base and gs_base registers in amd64 target descriptions.
The Windows-nat implementation was unfortunately not prepared to deal
with those new registers. In particular, the way it fetches registers
is done by using a table where the index is the register number, and
the value at that index is the offset in the area in the thread's CONTEXT
data where the corresponding register value is stored.
For instance, in amd64-windows-nat.c, we can find the mappings static
array containing the following 57 elements in it:
#define context_offset(x) (offsetof (CONTEXT, x))
static const int mappings[] =
{
context_offset (Rax),
[...]
context_offset (FloatSave.MxCsr)
};
That array is then used by windows_fetch_one_register via:
char *context_offset = ((char *) &th->context) + mappings[r];
The problem is that fs_base's register number is 172, which is
well past the end of the mappings array (57 elements in total).
We end up getting an undefined offset, which happens to be so large
that it then causes the address where we try to read the register
value (a little bit later) to be invalid, thus crashing GDB with
a SEGV.
This patch side-steps the issue entirely by removing support for
those registers in GDB on x86_64-windows, because a look at the
CONTEXT structure indicates no support for getting those registers.
A more comprehensive fix would patch the potential buffer overflow
of the mappings array, but this can be done as a separate commit.
gdb/ChangeLog:
* gdb/amd64-tdep.h (amd64_create_target_description): Add
"segments" parameter.
* gdb/amd64-tdep.c (amd64_none_init_abi, amd64_x32_none_init_abi)
(_initialize_amd64_tdep): Update call to
amd64_create_target_description.
(amd64_target_description): Add "segments" parameter. Adjust
the implementation to use it.
* gdb/amd64-linux-tdep.c (amd64_linux_read_description): Update
call to amd64_create_target_description.
* gdb/amd64-windows-tdep.c (amd64_windows_init_abi): Likewise.
* gdb/arch/amd64.h (amd64_create_target_description): Add
"segments" register.
* gdb/arch/amd64.c (amd64_create_target_description): Add
"segments" parameter. Call create_feature_i386_64bit_segments
only if SEGMENTS is true.
* gdb/gdbserver/win32-i386-low.c (i386_arch_setup): Update
call to amd64_create_target_description.
Tested on x86_64-windows using AdaCore's testsuite (by Joel Brobecker
<brobecker at adacore dot com>).
Fedora rpmbuild has been complaining:
*** WARNING: ./usr/src/debug/gdb-8.1.50.20180618-24.fc28.x86_64/gdb/gdbserver/x86-tdesc.h is executable but has empty or no shebang, removing executable bit
gdb/gdbserver/ChangeLog
2018-06-28 Jan Kratochvil <jan.kratochvil@redhat.com>
* x86-tdesc.h: Remove executable permission flag.
gdb/testsuite/ChangeLog
2018-06-28 Jan Kratochvil <jan.kratochvil@redhat.com>
* lib/compiler.c: Remove executable permission flag.
When trying to run the update-gnulib.sh script in gdb, I get this:
Error: Wrong automake version (Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ([^ =:+{}]+)}/ at /opt/automake/1.11.1/bin/automake line 4113.), we need 1.11.1.
Aborting.
Apparently, it's an issue with a regex in automake that triggers a
warning starting with Perl 5.22. It has been fixed in automake 1.15.1.
So I think it's a good excuse to bump the versions of autoconf and
automake used in the gnulib import. And to avoid requiring multiple
builds of autoconf/automake, it was suggested that we bump the required
version of those tools for all binutils-gdb.
For autoconf, the 2.69 version is universally available, so it's an easy
choice. For automake, different distros and distro versions have
different automake versions. But 1.15.1 seems to be the most readily
available as a package. In any case, it's easy to build it from source.
I removed the version checks from AUTOMAKE_OPTIONS and AC_PREREQ,
because I don't think they are useful in our case. They only specify a
lower bound for the acceptable version of automake/autoconf. That's
useful if you let the user choose the version of the tool they want to
use, but want to set a minimum version (because you use a feature that
was introduced in that version). In our case, we force people to use a
specific version anyway. For the autoconf version, we have the check in
config/override.m4 that enforces the version we want. It will be one
less thing to update next time we change autotools version.
I hit a few categories of problems that required some changes. They are
described below along with the chosen solutions.
Problem 1:
configure.ac:17: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated. For more info, see:
configure.ac:17: http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_005fINIT_005fAUTOMAKE-invocation
Solution 1:
Adjust the code based on the example at that URL.
Problem 2 (in zlib/):
Makefile.am: error: required file './INSTALL' not found
Makefile.am: 'automake --add-missing' can install 'INSTALL'
Makefile.am: error: required file './NEWS' not found
Makefile.am: error: required file './AUTHORS' not found
Makefile.am: error: required file './COPYING' not found
Makefile.am: 'automake --add-missing' can install 'COPYING'
Solution 2:
Add the foreign option to AUTOMAKE_OPTIONS.
Problem 3:
doc/Makefile.am:20: error: support for Cygnus-style trees has been removed
Solution 3:
Remove the cygnus options.
Problem 4:
Makefile.am:656: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
Solution 4:
Rename "INCLUDES = " to "AM_CPPFLAGS += " (because AM_CPPFLAGS is
already defined earlier).
Problem 5:
doc/Makefile.am:71: warning: suffix '.texinfo' for Texinfo files is discouraged; use '.texi' instead
doc/Makefile.am: warning: Oops!
doc/Makefile.am: It appears this file (or files included by it) are triggering
doc/Makefile.am: an undocumented, soon-to-be-removed automake hack.
doc/Makefile.am: Future automake versions will no longer place in the builddir
doc/Makefile.am: (rather than in the srcdir) the generated '.info' files that
doc/Makefile.am: appear to be cleaned, by e.g. being listed in CLEANFILES or
doc/Makefile.am: DISTCLEANFILES.
doc/Makefile.am: If you want your '.info' files to be placed in the builddir
doc/Makefile.am: rather than in the srcdir, you have to use the shiny new
doc/Makefile.am: 'info-in-builddir' automake option.
Solution 5:
Rename .texinfo files to .texi.
Problem 6:
doc/Makefile.am: warning: Oops!
doc/Makefile.am: It appears this file (or files included by it) are triggering
doc/Makefile.am: an undocumented, soon-to-be-removed automake hack.
doc/Makefile.am: Future automake versions will no longer place in the builddir
doc/Makefile.am: (rather than in the srcdir) the generated '.info' files that
doc/Makefile.am: appear to be cleaned, by e.g. being listed in CLEANFILES or
doc/Makefile.am: DISTCLEANFILES.
doc/Makefile.am: If you want your '.info' files to be placed in the builddir
doc/Makefile.am: rather than in the srcdir, you have to use the shiny new
doc/Makefile.am: 'info-in-builddir' automake option.
Solution 6:
Remove the hack at the bottom of doc/Makefile.am and use
the info-in-builddir automake option.
Problem 7:
doc/Makefile.am:35: error: required file '../texinfo.tex' not found
doc/Makefile.am:35: 'automake --add-missing' can install 'texinfo.tex'
Solution 7:
Use the no-texinfo.tex automake option. We also have one in
texinfo/texinfo.tex, not sure if we should point to that, or move it
(or a newer version of it added with automake --add-missing) to
top-level.
Problem 8:
Makefile.am:131: warning: source file 'config/tc-aarch64.c' is in a subdirectory,
Makefile.am:131: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled. For now, the corresponding output
automake: object file(s) will be placed in the top-level directory. However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
Solution 8:
Use subdir-objects, that means adjusting references to some .o that will now
be in config/.
Problem 9:
configure.ac:375: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2601: _AC_COMPILE_IFELSE is expanded from...
../../lib/autoconf/general.m4:2617: AC_COMPILE_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from...
../../lib/autoconf/general.m4:2042: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2063: AC_CACHE_CHECK is expanded from...
configure.ac:375: the top level
Solution 9:
Use AC_LANG_SOURCE, or use proper quoting.
Problem 10 (in intl/):
configure.ac:7: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
/usr/share/aclocal/threadlib.m4:36: gl_THREADLIB_EARLY_BODY is expanded from...
/usr/share/aclocal/threadlib.m4:29: gl_THREADLIB_EARLY is expanded from...
/usr/share/aclocal/threadlib.m4:318: gl_THREADLIB is expanded from...
/usr/share/aclocal/lock.m4:9: gl_LOCK is expanded from...
/usr/share/aclocal/intl.m4:211: gt_INTL_SUBDIR_CORE is expanded from...
/usr/share/aclocal/intl.m4:25: AM_INTL_SUBDIR is expanded from...
/usr/share/aclocal/gettext.m4:57: AM_GNU_GETTEXT is expanded from...
configure.ac:7: the top level
Solution 10:
Add AC_USE_SYSTEM_EXTENSIONS in configure.ac.
ChangeLog:
* libtool.m4: Use AC_LANG_SOURCE.
* configure.ac: Remove AC_PREREQ, use AC_LANG_SOURCE.
* README-maintainer-mode: Update version requirements.
* ar-lib: New file.
* test-driver: New file.
* configure: Re-generate.
bfd/ChangeLog:
* Makefile.am (AUTOMAKE_OPTIONS): Remove 1.11.
(INCLUDES): Rename to ...
(AM_CPPFLAGS): ... this.
* configure.ac: Remove AC_PREREQ.
* doc/Makefile.am (AUTOMAKE_OPTIONS): Remove 1.9, cygnus, add
info-in-builddir no-texinfo.tex.
(info_TEXINFOS): Rename bfd.texinfo to bfd.texi.
* doc/bfd.texinfo: Rename to ...
* doc/bfd.texi: ... this.
* Makefile.in: Re-generate.
* aclocal.m4: Re-generate.
* config.in: Re-generate.
* configure: Re-generate.
* doc/Makefile.in: Re-generate.
binutils/ChangeLog:
* configure.ac: Remove AC_PREREQ.
* doc/Makefile.am (AUTOMAKE_OPTIONS): Remove cygnus, add
info-in-builddir no-texinfo.tex.
* Makefile.in: Re-generate.
* aclocal.m4: Re-generate.
* config.in: Re-generate.
* configure: Re-generate.
* doc/Makefile.in: Re-generate.
config/ChangeLog:
* override.m4 (_GCC_AUTOCONF_VERSION): Bump from 2.64 to 2.69.
etc/ChangeLog:
* configure.in: Remove AC_PREREQ.
* configure: Re-generate.
gas/ChangeLog:
* Makefile.am (AUTOMAKE_OPTIONS): Remove 1.11, add subdir-objects.
(TARG_CPU_O, OBJ_FORMAT_O, ATOF_TARG_O): Add config/ prefix.
* configure.ac (TARG_CPU_O, OBJ_FORMAT_O, ATOF_TARG_O, emfiles,
extra_objects): Add config/ prefix.
* doc/as.texinfo: Rename to...
* doc/as.texi: ... this.
* doc/Makefile.am: Rename as.texinfo to as.texi throughout.
Remove DISTCLEANFILES hack.
(AUTOMAKE_OPTIONS): Remove 1.8, cygnus, add no-texinfo.tex and
info-in-builddir.
* Makefile.in: Re-generate.
* aclocal.m4: Re-generate.
* config.in: Re-generate.
* configure: Re-generate.
* doc/Makefile.in: Re-generate.
gdb/ChangeLog:
* common/common-defs.h (PACKAGE_NAME, PACKAGE_VERSION,
PACKAGE_STRING, PACKAGE_TARNAME): Undefine.
* configure.ac: Remove AC_PREREQ, add missing quoting.
* gnulib/configure.ac: Modernize usage of
AC_INIT/AM_INIT_AUTOMAKE. Remove AC_PREREQ.
* gnulib/update-gnulib.sh (AUTOCONF_VERSION): Bump to 2.69.
(AUTOMAKE_VERSION): Bump to 1.15.1.
* configure: Re-generate.
* config.in: Re-generate.
* aclocal.m4: Re-generate.
* gnulib/aclocal.m4: Re-generate.
* gnulib/config.in: Re-generate.
* gnulib/configure: Re-generate.
* gnulib/import/Makefile.in: Re-generate.
gdb/gdbserver/ChangeLog:
* configure.ac: Remove AC_PREREQ, add missing quoting.
* configure: Re-generate.
* config.in: Re-generate.
* aclocal.m4: Re-generate.
gdb/testsuite/ChangeLog:
* configure.ac: Remove AC_PREREQ.
* configure: Re-generate.
gold/ChangeLog:
* configure.ac: Remove AC_PREREQ, add missing quoting and usage
of AC_LANG_SOURCE.
* Makefile.in: Re-generate.
* aclocal.m4: Re-generate.
* configure: Re-generate.
* testsuite/Makefile.in: Re-generate.
gprof/ChangeLog:
* configure.ac: Remove AC_PREREQ.
* Makefile.am: Remove DISTCLEANFILES hack.
(AUTOMAKE_OPTIONS): Remove 1.11, add info-in-builddir.
* Makefile.in: Re-generate.
* aclocal.m4: Re-generate.
* configure: Re-generate.
* gconfig.in: Re-generate.
intl/ChangeLog:
* configure.ac: Add AC_USE_SYSTEM_EXTENSIONS, remove AC_PREREQ.
* configure: Re-generate.
* config.h.in: Re-generate.
* aclocal.m4: Re-generate.
ld/ChangeLog:
* configure.ac: Remove AC_PREREQ.
* Makefile.am: Remove DISTCLEANFILES hack, rename ld.texinfo to
ld.texi, ldint.texinfo to ldint.texi throughout.
(AUTOMAKE_OPTIONS): Add info-in-builddir.
* README: Rename ld.texinfo to ld.texi, ldint.texinfo to
ldint.texi throughout.
* gen-doc.texi: Likewise.
* h8-doc.texi: Likewise.
* ld.texinfo: Rename to ...
* ld.texi: ... this.
* ldint.texinfo: Rename to ...
* ldint.texi: ... this.
* Makefile.in: Re-generate.
* aclocal.m4: Re-generate.
* config.in: Re-generate.
* configure: Re-generate.
libdecnumber/ChangeLog:
* configure.ac: Remove AC_PREREQ.
* configure: Re-generate.
* aclocal.m4.
libiberty/ChangeLog:
* configure.ac: Remove AC_PREREQ.
* configure: Re-generate.
* config.in: Re-generate.
opcodes/ChangeLog:
* Makefile.am (AUTOMAKE_OPTIONS): Remove 1.11.
* configure.ac: Remove AC_PREREQ.
* Makefile.in: Re-generate.
* aclocal.m4: Re-generate.
* configure: Re-generate.
readline/ChangeLog.gdb:
* configure: Re-generate.
* examples/rlfe/configure: Re-generate.
sim/ChangeLog:
* All configure.ac: Remove AC_PREREQ.
* All configure: Re-generate.
zlib/ChangeLog.bin-gdb:
* configure.ac: Modernize AC_INIT call, remove AC_PREREQ.
* Makefile.am (AUTOMAKE_OPTIONS): Remove 1.8, cygnus, add
foreign.
* Makefile.in: Re-generate.
* aclocal.m4: Re-generate.
* configure: Re-generate.
The variable has been removed in c12a508 ("Add client_state struct."),
remove the leftover declaration.
gdb/gdbserver/ChangeLog:
* tracepoint.h (current_traceframe): Remove declaration.
Add checks to detect SVE tdesc. Easiest way to do this is by checking the
size of the vector registers.
Use the common aarch64 ptrace copy functions for reading/writing registers.
A wrapper is required due to the common functions using reg_buffer_common.
gdbserver/
* linux-aarch64-low.c (is_sve_tdesc): New function.
(aarch64_sve_regs_copy_to_regcache): Likewise.
(aarch64_sve_regs_copy_from_regcache): Likewise.
(aarch64_regs_info): Add SVE checks.
(initialize_low_arch): Initialize SVE.
Add support for reading and writing registers for Aarch64 SVE.
We need to support the cases where the kernel only gives us a
fpsimd structure. This occurs when there is no active SVE state
in the kernel (for example, after starting a new process).
Added checks to make sure the vector length has not changed whilst
the process is running.
gdb/
* aarch64-linux-nat.c (fetch_sveregs_from_thread): New function.
(store_sveregs_to_thread): Likewise.
(aarch64_linux_fetch_inferior_registers): Check for SVE.
(aarch64_linux_store_inferior_registers): Likewise.
* nat/aarch64-sve-linux-ptrace.c (aarch64_sve_get_sveregs): New
function.
(aarch64_sve_regs_copy_to_regcache): Likewise.
(aarch64_sve_regs_copy_from_regcache): Likewise.
* nat/aarch64-sve-linux-ptrace.h (aarch64_sve_get_sveregs): New
declaration.
(aarch64_sve_regs_copy_to_regcache): Likewise.
(aarch64_sve_regs_copy_from_regcache): Likewise.
(sve_context): Structure from Linux headers.
(SVE_SIG_ZREGS_SIZE): Define from Linux headers.
(SVE_SIG_ZREG_SIZE): Likewise.
(SVE_SIG_PREG_SIZE): Likewise.
(SVE_SIG_FFR_SIZE): Likewise.
(SVE_SIG_REGS_OFFSET): Likewise.
(SVE_SIG_ZREGS_OFFSET): Likewise.
(SVE_SIG_ZREG_OFFSET): Likewise.
(SVE_SIG_ZREGS_SIZE): Likewise.
(SVE_SIG_PREGS_OFFSET): Likewise.
(SVE_SIG_PREG_OFFSET): Likewise.
(SVE_SIG_PREGS_SIZE): Likewise.
(SVE_SIG_FFR_OFFSET): Likewise.
(SVE_SIG_REGS_SIZE): Likewise.
(SVE_SIG_CONTEXT_SIZE): Likewise.
(SVE_PT_REGS_MASK): Likewise.
(SVE_PT_REGS_FPSIMD): Likewise.
(SVE_PT_REGS_SVE): Likewise.
(SVE_PT_VL_INHERIT): Likewise.
(SVE_PT_VL_ONEXEC): Likewise.
(SVE_PT_REGS_OFFSET): Likewise.
(SVE_PT_FPSIMD_OFFSET): Likewise.
(SVE_PT_FPSIMD_SIZE): Likewise.
(SVE_PT_SVE_ZREG_SIZE): Likewise.
(SVE_PT_SVE_PREG_SIZE): Likewise.
(SVE_PT_SVE_FFR_SIZE): Likewise.
(SVE_PT_SVE_FPSR_SIZE): Likewise.
(SVE_PT_SVE_FPCR_SIZE): Likewise.
(__SVE_SIG_TO_PT): Likewise.
(SVE_PT_SVE_OFFSET): Likewise.
(SVE_PT_SVE_ZREGS_OFFSET): Likewise.
(SVE_PT_SVE_ZREG_OFFSET): Likewise.
(SVE_PT_SVE_ZREGS_SIZE): Likewise.
(SVE_PT_SVE_PREGS_OFFSET): Likewise.
(SVE_PT_SVE_PREG_OFFSET): Likewise.
(SVE_PT_SVE_PREGS_SIZE): Likewise.
(SVE_PT_SVE_FFR_OFFSET): Likewise.
(SVE_PT_SVE_FPSR_OFFSET): Likewise.
(SVE_PT_SVE_FPCR_OFFSET): Likewise.
(SVE_PT_SVE_SIZE): Likewise.
(SVE_PT_SIZE): Likewise.
(HAS_SVE_STATE): New define.
gdbserver/
* Makefile.in: Add aarch64-sve-linux-ptrace.c.
A purely virtual class containing functions from gdb/regcache.h
Both the gdb regcache structures and gdbserver regcache inherit
directly from reg_buffer_common. This will allow for common
functions which require the use of a regcache.
gdb/
* common/common-regcache.h (reg_buffer_common): New structure.
* regcache.c (reg_buffer::invalidate): Move from detached_regcache.
(reg_buffer::raw_supply): Likewise.
(reg_buffer::raw_supply_integer): Likewise.
(reg_buffer::raw_supply_zeroed): Likewise.
(reg_buffer::raw_collect): Likewise.
(reg_buffer::raw_collect_integer): Likewise.
* regcache.h (reg_buffer::invalidate): Move from detached_regcache.
(reg_buffer::raw_supply): Likewise.
(reg_buffer::raw_supply_integer): Likewise.
(reg_buffer::raw_supply_zeroed): Likewise.
(reg_buffer::raw_collect): Likewise.
(reg_buffer::raw_collect_integer): Likewise.
gdbserver/
* regcache.c (new_register_cache): Use new.
(free_register_cache): Use delete.
(register_data): Use const.
(supply_register): Move body inside regcache.
(regcache::raw_supply): New override function.
(collect_register): Move body inside regcache.
(regcache::raw_collect): New override function.
(regcache::get_register_status): New override function.
* regcache.h (struct regcache): Inherit from reg_buffer_common.
This removes a use of queue.h from gdbserver/event-loop.c, replacing
it with std::queue.
I was not completely sure whether std::queue is even that useful.
Perhaps plain std::list could be used just as easily.
Tested by the buildbot.
gdb/gdbserver/ChangeLog
2018-06-09 Tom Tromey <tom@tromey.com>
* event-loop.c (gdb_event, gdb_event_p): Remove typedefs. Don't
declare queue.
(event_queue): Use std::queue.
(gdb_event_xfree): Remove.
(initialize_event_loop, process_event, wait_for_event): Update.
This makes gdbreplay share a bit more code with gdbserver, and paves
the way to share more in future. Including common-defs.h pulls in
defines and headers that gdb and gdbserver assume are always
defined/available too, such as for example _(), ansidecl.h or a set of
system headers. Including that revealed (static vs extern conflict)
gdbreplay had a local copy of perror_with_name (which exited directly
instead of throwing an error). So I removed gdbreplay's local copy,
and then added enough .o files until gdbreplay linked successfully.
Also, use xstrdup instead of strdup.
gdb/gdbserver/ChangeLog:
2018-06-08 Pedro Alves <palves@redhat.com>
* Makefile.in (GDBREPLAY_OBS): Add common/cleanups.o,
common/common-exceptions.o, common/common-utils.o,
common/errors.o, common/print-utils.o and utils.o.
* gdbreplay.c: Include "common-defs.h" instead of the two
'config.h's here. Don't include stdio.h, errno.h, stdlib.h,
string.h or alloca.h.
(perror_with_name): Delete.
(remote_open): Use xstrdup instead of strdup.
(main): Rename to ...
(captured_main): ... this.
(main): New.
Collect per client specific global data items into struct client_state,
which is similar in purpose to remote.c::remote_state.
gdbserver/ChangeLog
* server.h (struct client_state): New.
* server.c (cont_thread, general_thread, multi_process)
(report_fork_events, report_vfork_events, report_exec_events)
(report_thread_events, swbreak_feature, hwbreak_feature)
(vCont_supported, disable_randomization, pass_signals)
(program_signals, program_signals_p, last_status, last_ptid, own_buf):
Moved to client_state.
* remote-utils.c (remote_debug, noack_mode)
(transport_is_reliable): Moved to client_state.
* tracepoint.c (current_traceframe): Moved to client_state.
Update all callers.
* server.c, remote-utils.c, tracepoint.c, fork-child.c,
linux-low.c, remote-utils.h, target.c: Use client_state.
Returns 0 for systems without SVE support.
Note the defines taken from Linux kernel headers
in aarch64-sve-linux-ptrace.h.
gdb/
* Makefile.in: Add new header.
* gdb/arch/aarch64.h (sve_vg_from_vl): New macro.
(sve_vl_from_vg): Likewise.
(sve_vq_from_vl): Likewise.
(sve_vl_from_vq): Likewise.
(sve_vq_from_vg): Likewise.
(sve_vg_from_vq): Likewise.
* configure.nat: Add new c file.
* nat/aarch64-sve-linux-ptrace.c: New file.
* nat/aarch64-sve-linux-ptrace.h: New file.
gdbserver/
* configure.srv: Add new c/h file.
Our interpretation of the layout of floating-point general registers
(FGRs) in o32 MIPS/Linux core files is different from how the kernel
makes them, affecting the CP0 Status.FR=0 aka FP32 mode (we don't
currently support the CP0 Status.FR=1 aka FP64 mode with the o32 ABI).
In the FP32 mode pairs of consecutive even/odd-numbered 32-bit registers
are placed together as 64-bit values in even-indexed 64-bit slots
corresponding to the even index, leaving the odd-indexed 64-bit slots
unused. These 64-bit values are stored according to the endianness in
effect, which is how the MIPS II SDC1 instruction would store them.
It has always been like that with the Linux kernel for MIPS II and
higher ISA processors, which are the vast majority ever supported, as it
is indeed SDC1 that the kernel uses to store FGRs in a floating-point
context.
With MIPS I processors, which lack the SDC1 instruction, a layout that
we expect used to be used long ago, but it was corrected for consistency
with newer processors back in 2002, with `linux-mips.org' (LMO) commit
42533948caac ("Major pile of FP emulator changes."), the fix corrected
with LMO commit 849fa7a50dff ("R3k FPU ptrace() handling fixes."), and
then broken and fixed over and over again, until last time fixed with
commit 80cbfad79096 ("MIPS: Correct MIPS I FP context layout").
Consequently the values we see in FP32 core files or produce with the
`gcore' command are different from those obtained from the same FP
context of a live process, e.g. with a big-endian configuration these
live values:
(gdb) info registers float
f0: 0x4b5c6d7e flt: 14445950 dbl: 1.7446153562345001e-274
f1: 0x0718293a flt: 1.14473244e-34
f2: 0xc3d4e5f6 flt: -425.79657 dbl: -1.046160437414959e-233
f3: 0x8f90a1b2 flt: -1.42617791e-29
f4: 0x4c5d6e7f flt: 58046972 dbl: 1.1908587841220294e-269
f5: 0x08192a3b flt: 4.60914044e-34
f6: 0xc4d5e6f7 flt: -1711.21765 dbl: -6.2784661835068965e-306
f7: 0x8091a2b3 flt: -1.33745124e-38
f8: 0x45566778 flt: 3430.4668 dbl: 1.6530355595710607e-303
f9: 0x01122334 flt: 2.68412219e-38
f10: 0xcddeeff0 flt: -467533312 dbl: -2.1174864564135575e-262
f11: 0x899aabbc flt: -3.72356497e-33
f12: 0x46576879 flt: 13786.1182 dbl: 1.143296486773654e-298
f13: 0x02132435 flt: 1.08102453e-37
f14: 0xcedfe0f1 flt: -1.87803046e+09 dbl: -1.4399511533369862e-257
f15: 0x8a9bacbd flt: -1.4990934e-32
f16: 0x4758697a flt: 55401.4766 dbl: 7.8856820439568725e-294
f17: 0x03142536 flt: 4.3536007e-37
f18: 0xcfd0e1f2 flt: -7.00893696e+09 dbl: -9.7791926757340559e-253
f19: 0x8b9cadbe flt: -6.03504325e-32
f20: 0x48596a7b flt: 222633.922 dbl: 5.4255001483306113e-289
f21: 0x04152637 flt: 1.75324132e-36
f22: 0xc0d1e2f3 flt: -6.55895376 dbl: -6.6332401002310683e-248
f23: 0x8c9daebf flt: -2.42948516e-31
f24: 0x495a6b7c flt: 894647.75 dbl: 3.7244369058749787e-284
f25: 0x05162738 flt: 7.06016945e-36
f26: 0xc1d2e3f4 flt: -26.3613052 dbl: -4.4941535759306202e-243
f27: 0x8d9eafb0 flt: -9.77979703e-31
f28: 0x4a5b6c7d flt: 3595039.25 dbl: 2.5514593711161396e-279
f29: 0x06172839 flt: 2.84294945e-35
f30: 0xc2d3e4f5 flt: -105.947182 dbl: -3.035646690850097e-238
f31: 0x8e9fa0b1 flt: -3.93512664e-30
fcsr: 0x0
fir: 0xf30000
(gdb)
show up in a core file as these:
(gdb) info registers float
f0: 0x0718293a flt: 1.14473244e-34 dbl: nan
f1: 0x7ff80000 flt: nan
f2: 0x8f90a1b2 flt: -1.42617791e-29 dbl: nan
f3: 0x7ff80000 flt: nan
f4: 0x08192a3b flt: 4.60914044e-34 dbl: nan
f5: 0x7ff80000 flt: nan
f6: 0x8091a2b3 flt: -1.33745124e-38 dbl: nan
f7: 0x7ff80000 flt: nan
f8: 0x01122334 flt: 2.68412219e-38 dbl: nan
f9: 0x7ff80000 flt: nan
f10: 0x899aabbc flt: -3.72356497e-33 dbl: nan
f11: 0x7ff80000 flt: nan
f12: 0x02132435 flt: 1.08102453e-37 dbl: nan
f13: 0x7ff80000 flt: nan
f14: 0x8a9bacbd flt: -1.4990934e-32 dbl: nan
f15: 0x7ff80000 flt: nan
f16: 0x03142536 flt: 4.3536007e-37 dbl: nan
f17: 0x7ff80000 flt: nan
f18: 0x8b9cadbe flt: -6.03504325e-32 dbl: nan
f19: 0x7ff80000 flt: nan
f20: 0x04152637 flt: 1.75324132e-36 dbl: nan
f21: 0x7ff80000 flt: nan
f22: 0x8c9daebf flt: -2.42948516e-31 dbl: nan
f23: 0x7ff80000 flt: nan
f24: 0x05162738 flt: 7.06016945e-36 dbl: nan
f25: 0x7ff80000 flt: nan
f26: 0x8d9eafb0 flt: -9.77979703e-31 dbl: nan
f27: 0x7ff80000 flt: nan
f28: 0x06172839 flt: 2.84294945e-35 dbl: nan
f29: 0x7ff80000 flt: nan
f30: 0x8e9fa0b1 flt: -3.93512664e-30 dbl: nan
f31: 0x7ff80000 flt: nan
(gdb)
Notice how values from odd-numbered registers are shown in corresponding
even-numbered registers and how dummy 0x7ff80000 NaN values, which the
kernel places in unused slots, are reported in odd-numbered registers.
Correct our intepretation then, to match the kernel's. As it happens
the o32 FGR core file representation matches that used by the `ptrace'
PTRACE_GETFPREGS request, which means our 64-bit handlers can be readily
used, as they already correctly handle the differences between o32 FP32
mode vs n32/n64 representations.
Adjust comments accordingly throughout, in particular remove a reference
to the r3000/tx39 MIPS I processor peculiarity, long irrelevant.
Add a test case to verify correctness. Avoid GCC bugs and limitations
in the test case where possible; the test case still fails to build with
GCC 8 and the o32 FP64 mode (i.e. with `-mips32r2 -mfp64' options)
giving:
mips-fpregset-core.c: In function 'main':
mips-fpregset-core.c:66:3: error: inconsistent operand constraints in an 'asm'
asm (
^~~
(GCC PR target/85909), but that is not a concern for us as yet, because
as noted above we do not currently support the o32 FP64 mode anyway.
gdb/
* mips-linux-tdep.h (mips_supply_fpregset, mips_fill_fpregset):
Remove prototypes.
* mips-linux-nat.c (supply_fpregset): Always call
`mips64_supply_fpregset' rather than `mips_supply_fpregset'.
(fill_fpregset): Always call `mips64_fill_fpregset' rather than
`mips_fill_fpregset'.
* mips-linux-tdep.c (mips_supply_fpregset)
(mips_supply_fpregset_wrapper, mips_fill_fpregset)
(mips_fill_fpregset_wrapper): Remove functions.
(mips64_supply_fpregset, mips64_fill_fpregset): Update comments.
(mips_linux_fpregset): Remove variable.
(mips_linux_iterate_over_regset_sections): Use
`mips64_linux_fpregset' in place of `mips_linux_fpregset'.
(mips_linux_o32_sigframe_init): Remove comment.
gdb/testsuite/
* gdb.arch/mips-fpregset-core.exp: New test.
* gdb.arch/mips-fpregset-core.c: New test source.
Currently, the function used by gdbserver to parse integers from
received File I/O commands will detect overflow and fail for any value
over 0xfffffff. Among other things, this has the effect of limiting
the file offsets for reading or writing to about 268MB which can be
insufficient for particularly large libraries.
This change allows the parsing of integers up to the true maximum
positive value of 0x7fffffff, increasing the file size limit to about
2GB.
gdb/gdbserver/ChangeLog:
2018-05-23 Erik Kurzinger <ekurzinger@nvidia.com>
PR server/23198
* hostio.c (require_int): Do not report overflow for integers
between 0xfffffff and 0x7fffffff.
Fix an issue with `gdbserver' on big-endian n64 MIPS targets, where
$dspctl is 32-bit while the `ptrace' transfer data type is 64-bit.
Such register data is held in the low order 32 bits of the 64-bit data
quantity exchanged with the buffer used by `fetch_register' and
`store_register', however `supply_register' and `collect_register'
access the same data as a 32-bit quantity. Consequently the register is
presented and written as all-zeros held in the most-significant part of
the big-endian 64-bit data quantity represented in the buffer:
(gdb) info registers
zero at v0 v1
R0 0000000000000000 0000000000000001 0000000000000001 0000000000000000
a0 a1 a2 a3
R4 00000001200212b0 0000000000000000 0000000000000021 000000012001a260
a4 a5 a6 a7
R8 000000012001a260 0000000000000004 800000010c60c000 fffffffffffffff8
t0 t1 t2 t3
R12 0000000000000000 000000fff7edab68 0000000000000001 0000000000000000
s0 s1 s2 s3
R16 000000fff7ee2068 0000000120008b80 0000000000000000 0000000000000000
s4 s5 s6 s7
R20 000000000052e5c8 000000000052f008 0000000000000000 0000000000000000
t8 t9 k0 k1
R24 0000000000000000 00000001200027c0 0000000000000000 0000000000000000
gp sp s8 ra
R28 00000001200212b0 000000ffffffc850 000000ffffffc850 0000000120005ee8
status lo hi badvaddr
0000000000109cf3 0000000000943efe 000000000000000e 000000012001a008
cause pc
0000000000800024 0000000120005ee8
fcsr fir hi1 lo1
0e800000 00f30000 0000000000000000 0101010101010101
hi2 lo2 hi3 lo3
0202020202020202 0303030303030303 0404040404040404 0505050505050505
dspctl restart
00000000 0000000000000000
(gdb)
Correct this problem then by using the `mips_supply_register'
`mips_collect_register' accessors for 32-bit registers where the
`ptrace' data type is 64-bit. These accessors already operate on 32-bit
data quantities held in 64-bit containers:
(gdb) info registers
zero at v0 v1
R0 0000000000000000 0000000000000001 0000000000000001 0000000000000000
a0 a1 a2 a3
R4 00000001200212b0 0000000000000000 0000000000000021 000000012001a260
a4 a5 a6 a7
R8 000000012001a260 0000000000000004 800000010d82e900 fffffffffffffff8
t0 t1 t2 t3
R12 0000000000000000 000000fff7edab68 0000000000000001 0000000000000000
s0 s1 s2 s3
R16 000000fff7ee2068 0000000120008b80 0000000000000000 0000000000000000
s4 s5 s6 s7
R20 000000000052e5c8 000000000052f008 0000000000000000 0000000000000000
t8 t9 k0 k1
R24 0000000000000000 00000001200027c0 0000000000000000 0000000000000000
gp sp s8 ra
R28 00000001200212b0 000000ffffffc850 000000ffffffc850 0000000120005ee8
status lo hi badvaddr
0000000000109cf3 0000000000943efe 000000000000000e 000000012001a008
cause pc
0000000000800024 0000000120005ee8
fcsr fir hi1 lo1
0e800000 00f30000 0000000000000000 0101010101010101
hi2 lo2 hi3 lo3
0202020202020202 0303030303030303 0404040404040404 0505050505050505
dspctl restart
55aa33cc 0000000000000000
(gdb)
gdb/gdbserver/
* linux-mips-low.c [HAVE_PTRACE_GETREGS] (mips_collect_register)
(mips_supply_register): Move outside HAVE_PTRACE_GETREGS.
(mips_collect_ptrace_register, mips_supply_ptrace_register): New
functions.
(the_low_target): Wire them.
The 4-byte VSCR register is found inside a 16-byte field in the regset
returned by ptrace and in core files. The position of VSCR depends on
the endianess of the target, which was previously assumed to be
big-endian for the purpose of getting VSCR. This patch removes this
assumption to fix access to VSCR in little-endian mode.
gdb/ChangeLog:
2018-05-22 Pedro Franco de Carvalho <pedromfc@linux.vnet.ibm.com>
* ppc-tdep.h (struct ppc_reg_offsets): Remove vector register
offset fields.
* ppc-fbsd-tdep.c (ppc32_fbsd_reg_offsets): Remove initializers
for vector register offset fields.
(ppc64_fbsd_reg_offsets): Likewise.
* ppc-nbsd-tdep.c (_initialize_ppcnbsd_tdep): Remove assignment
to vector register offset fields.
* ppc-obsd-tdep.c (_initialize_ppcnbsd_tdep): Remove assignment
to vector register offset fields.
* ppc-obsd-nat.c (_initialize_ppcobsd_nat): Remove assignment to
vector register offset fields.
* rs6000-aix-tdep.c (rs6000_aix32_reg_offsets): Remove
initializers for vector register offset fields.
(rs6000_aix64_reg_offsets): Likewise.
* rs6000-tdep.c (ppc_vrreg_offset): Remove.
(ppc_supply_vrregset): Remove.
(ppc_collect_vrregset): Remove.
* ppc-linux-tdep.c (ppc_linux_collect_vrregset): New function.
(ppc_linux_vrregset) : New function.
(ppc32_le_linux_vrregmap, ppc32_be_linux_vrregmap)
(ppc32_le_linux_vrregset, ppc32_be_linux_vrregset): New globals.
(ppc32_linux_vrregset): Remove.
(ppc_linux_iterate_over_regset_sections): Call ppc_linux_vrregset
and use result instead of ppc32_linux_vrregset.
(ppc32_linux_reg_offsets): Remove initializers for vector register
offset fields.
(ppc64_linux_reg_offsets): Likewise.
* ppc-linux-tdep.h (ppc_linux_vrregset): New declaration.
* ppc-linux-nat.c: Include regset.h.
(gdb_vrregset_t): Adjust comment to account for little-endian
mode.
(supply_vrregset, fill_vrregset): Remove.
(fetch_altivec_register, store_altivec_register): Remove.
(fetch_altivec_registers): Add regno parameter. Get regset using
ppc_linux_vrregset. Use regset to supply registers.
(store_altivec_registers): Add regno parameter. Get regset using
ppc_linux_vrregset. Use regset to collect registers.
(fetch_register): Call fetch_altivec_registers instead of
fetch_altivec_register.
(store_register): Call store_altivec_registers instead of
store_altivec_register.
(fetch_ppc_registers): Call fetch_altivec_registers with -1 for
the new regno parameter.
(store_ppc_registers): Call store_altivec_registers with -1 for
the new regno parameter.
gdb/gdbserver/ChangeLog:
2018-05-22 Pedro Franco de Carvalho <pedromfc@linux.vnet.ibm.com>
* linux-ppc-low.c (ppc_fill_vrregset): Add vscr_offset variable.
Set vscr_offset to 0 in little-endian mode and 12 in big-endian
mode. Call collect_register_by_name with vscr using
vscr_offset. Zero-pad vscr and vrsave fields in collector buffer.
(ppc_store_vrregset): Add and set vscr_offset variable as in
ppc_fill_vrregset. Call supply_register_by_name with vscr using
vscr_offset.
This patch defines constants for the sizes of the two vector
regsets (vector-scalar registers and regular vector registers).
The native, gdbserver and core file targets are changed to use these
constants.
The Linux ptrace calls return (or read) a smaller regset than the one
found in core files for vector registers, because ptrace uses a single
4-byte quantity for vrsave at the end of the regset, while the
core-file regset uses a full 16-byte field for vrsave. For simplicity,
the larger size is used in both cases, and so a buffer with 12 unused
additional bytes is passed to ptrace in the native target.
gdb/ChangeLog:
2018-05-22 Pedro Franco de Carvalho <pedromfc@linux.vnet.ibm.com>
* arch/ppc-linux-common.h (PPC_LINUX_SIZEOF_VRREGSET)
(PPC_LINUX_SIZEOF_VSXREGSET): Define.
* ppc-linux-nat.c (SIZEOF_VSXREGS, SIZEOF_VRREGS): Remove.
(gdb_vrregset_t): Change array type size to
PPC_LINUX_SIZEOF_VRREGSET.
(gdb_vsxregset_t): Change array type size to
PPC_LINUX_SIZEOF_VSXREGSET.
* ppc-linux-tdep.c (ppc_linux_iterate_over_regset_sections):
Change integer literals to PPC_LINUX_SIZEOF_VRREGSET and
PPC_LINUX_SIZEOF_VSXREGSET.
gdb/gdbserver/ChangeLog:
2018-05-22 Pedro Franco de Carvalho <pedromfc@linux.vnet.ibm.com>
* linux-ppc-low.c (SIZEOF_VSXREGS, SIZEOF_VRREGS): Remove.
(ppc_arch_setup): Change SIZEOF_VRREGS and SIZEOF_VSXREGS to
PPC_LINUX_SIZEOF_VRREGSET and PPC_LINUX_SIZEOF_VSXREGSET.
Currently the linux-ppc-low.c fill/store functions for extended
regsets check whether they should execute by using the global hwcap
variable.
This patch explicitly sets the regset sizes to zero when needed to
disable them instead, so that the fill/store functions are not called
in the first place by regsets_fetch_inferior_registers in linux-low.c.
gdb/gdbserver/ChangeLog:
2018-05-22 Pedro Franco de Carvalho <pedromfc@linux.vnet.ibm.com>
* linux-ppc-low.c (ppc_fill_vsxregset): Remove ppc_hwcap check.
(ppc_store_vsxregset): Likewise.
(ppc_fill_vrregset): Likewise.
(ppc_store_vrregset): Likewise.
(ppc_fill_evrregset): Likewise.
(ppc_store_evrregset): Likewise.
(ppc_regsets): Set VSX/VR/EVR regset sizes to 0.
(ppc_arch_setup): Iterate through ppc_regsets and set sizes when
needed.
This patch moves the native target wordsize getter for ppc linux to
nat/ so that it can be used to simplify ppc_arch_setup in
gdbserver. The ptrace call used to get MSR for this is ultimately the
same as before, but it is no longer necessary to create a temporary
regcache to call fetch_inferior_registers.
gdb/ChangeLog:
2018-05-22 Pedro Franco de Carvalho <pedromfc@linux.vnet.ibm.com>
* configure.nat <linux powerpc>: Add ppc-linux.o to NATDEPFILES.
* ppc-linux-nat.c (ppc_linux_target_wordsize): Move to
nat/ppc-linux.c.
(ppc_linux_nat_target::auxv_parse): Get thread id tid. Call
ppc_linux_target_wordsize with tid.
(ppc_linux_nat_target::read_description): Call ppc_linux_target
wordsize with tid.
* nat/ppc-linux.c: Include nat/gdb_ptrace.h.
(ppc64_64bit_inferior_p): Add static and inline specifiers.
(ppc_linux_target_wordsize): Move here from ppc-linux-nat.c. Add
tid parameter. Remove static specifier.
* nat/ppc-linux.h (ppc64_64bit_inferior_p): Remove declaration.
(ppc_linux_target_wordsize): New declaration.
gdb/gdbserver/ChangeLog:
2018-05-22 Pedro Franco de Carvalho <pedromfc@linux.vnet.ibm.com>
* linux-ppc-low.c (ppc_arch_setup): Remove code for getting the
wordsize of the inferior. Call ppc_linux_target_wordsize.
Share target description declarations and selection among ppc linux
native targets, core files, gdbserver and IPA.
To avoid complicated define guards, gdbserver and IPA now have
declarations for all descriptions, including 64-bit generated
descriptions when compiled in 32-bit mode. These have always been
linked into the gdbserver and IPA binaries. Because they might be
uninitialized, the selection function checks that the selected
description is initialized.
gdb/ChangeLog:
2018-05-22 Pedro Franco de Carvalho <pedromfc@linux.vnet.ibm.com>
* arch/ppc-linux-common.c: New file.
* arch/ppc-linux-common.h: New file.
* arch/ppc-linux-tdesc.h: New file.
* configure.tgt (powerpc*-*-linux*): Add arch/ppc-linux-common.o.
* Makefile.in (ALL_TARGET_OBS): Add arch/ppc-linux-common.o.
(HFILES_NO_SRCDIR): Add arch/ppc-linux-common.h and
arch/ppc-linux-tdesc.h.
* ppc-linux-nat.c: Include arch/ppc-linux-common.h and
arch/ppc-linux-tdesc.h.
(ppc_linux_nat_target::read_description): Remove target
description matching code. Fill a ppc_linux_features struct and
call ppc_linux_match_description with it. Move comment about ISA
2.05 to ppc-linux-common.c.
* ppc-linux-tdep.c: Include arch/ppc-linux-common.h and
arch/ppc-linux-tdesc.h.
(ppc_linux_core_read_description): Remove target description
matching code. Fill a ppc_linux_features struct and call
ppc_linux_match_description with it.
* ppc-linux-tdep.h (tdesc_powerpc_32l, tdesc_powerpc_64l)
(tdesc_powerpc_altivec32l, tdesc_powerpc_altivec64l)
(tdesc_powerpc_cell32l, tdesc_powerpc_cell64l)
(tdesc_powerpc_vsx32l, tdesc_powerpc_vsx64l)
(tdesc_powerpc_isa205_32l, tdesc_powerpc_isa205_64l)
(tdesc_powerpc_isa205_altivec32l, tdesc_powerpc_isa205_altivec64l)
(tdesc_powerpc_isa205_vsx32l, tdesc_powerpc_isa205_vsx64l)
(tdesc_powerpc_e500l): Remove.
gdb/gdbserver/ChangeLog:
2018-05-22 Pedro Franco de Carvalho <pedromfc@linux.vnet.ibm.com>
* configure.srv (srv_tgtobj): Add arch/ppc-linux-common.o.
* Makefile.in (SFILES): Add arch/ppc-linux-common.c.
* linux-ppc-tdesc.h: Rename to linux-ppc-tdesc-init.h.
* linux-ppc-tdesc-init.h (tdesc_powerpc_32l, tdesc_powerpc_64l)
(tdesc_powerpc_altivec32l, tdesc_powerpc_altivec64l)
(tdesc_powerpc_cell32l, tdesc_powerpc_cell64l)
(tdesc_powerpc_vsx32l, tdesc_powerpc_vsx64l)
(tdesc_powerpc_isa205_32l, tdesc_powerpc_isa205_64l)
(tdesc_powerpc_isa205_altivec32l, tdesc_powerpc_isa205_altivec64l)
(tdesc_powerpc_isa205_vsx32l, tdesc_powerpc_isa205_vsx64l)
(tdesc_powerpc_e500l): Remove.
* linux-ppc-ipa.c: Include arch/ppc-linux-tdesc.h and
linux-ppc-tdesc-init.h. Don't include linux-ppc-tdesc.h.
* linux-ppc-low.c: Include arch/ppc-linux-common.h,
arch/ppc-linux-tdesc.h, and linux-ppc-tdesc-init.h. Don't include
linux-ppc-tdesc.h.
(ppc_arch_setup): Remove target description matching code. Fill a
ppc_linux_features struct and call ppc_linux_match_description
with it.
On the MIPS target DSP ASE registers can only be accessed with the
PTRACE_PEEKUSR and PTRACE_POKEUSR `ptrace' requests. With the n32 ABI
these requests only pass 32-bit data quantities, which are narrower than
the width of DSP accumulator registers, which are 64-bit.
Generic code is prepared to transfer registers wider than the `ptrace'
data type by offsetting into the USR address space, by the data width
transferred. That however does not work with the MIPS target, because
of how the API has been defined, where USR register addresses are
actually indices rather than offsets. Consequently given address `a'
using `a + 4' accesses the fourth next register rather than the upper
half of the original register.
With native debugging this causes clobbered register contents, as well
as access failures as locations beyond the available USR space are
addressed:
(gdb) info registers
zero at v0 v1
R0 0000000000000000 0000000000000001 0000000000000001 0000000000000000
a0 a1 a2 a3
R4 0000000010019158 0000000000000000 0000000000000011 0000000010019160
a4 a5 a6 a7
R8 0000000010019160 fffffffffff00000 fffffffffffffff8 0000000000000000
t0 t1 t2 t3
R12 0000000010019150 0000000000000001 0000000000000001 000000000000000f
s0 s1 s2 s3
R16 0000000077ee6f20 0000000010007bb0 0000000000000000 0000000000000000
s4 s5 s6 s7
R20 000000000052e668 000000000052f008 0000000000000000 0000000000000000
t8 t9 k0 k1
R24 0000000000000001 0000000010019010 0000000000000000 0000000000000000
gp sp s8 ra
R28 0000000010020280 000000007fff4c10 000000007fff4c10 0000000010004f48
status lo hi badvaddr
0000000000109cf3 0000000000943efe 000000000000000e 000000001001900c
cause pc
0000000000800024 0000000010004f48
fcsr fir hi1 lo1
0e800000 00f30000 0000000004040404 0101010105050505
hi2 lo2 hi3 lo3
0202020255aa33cc Couldn't read register (#75): Input/output error.
(gdb)
With `gdbserver' this makes debugging impossible due to a fatal failure:
(gdb) target remote :2346
Remote debugging using :2346
Reading symbols from .../sysroot/mips-r2-hard/lib32/ld.so.1...done.
0x77fc3d50 in __start () from .../sysroot/mips-r2-hard/lib32/ld.so.1
(gdb) continue
Continuing.
warning: Remote failure reply: E01
Remote communication error. Target disconnected.: Connection reset by peer.
(gdb)
Correct the problem by marking any register in the MIPS backend whose
width exceeds the width of the `ptrace' data type unavailable for the
purpose of PTRACE_PEEKUSR and PTRACE_POKEUSR requests:
(gdb) info registers
zero at v0 v1
R0 0000000000000000 0000000000000001 0000000000000001 0000000000000000
a0 a1 a2 a3
R4 0000000010019158 0000000000000000 0000000000000011 0000000010019160
a4 a5 a6 a7
R8 0000000010019160 fffffffffff00000 fffffffffffffff8 0000000000000000
t0 t1 t2 t3
R12 0000000010019150 0000000000000001 0000000000000001 000000000000000f
s0 s1 s2 s3
R16 0000000077ee6f20 0000000010007bb0 0000000000000000 0000000000000000
s4 s5 s6 s7
R20 000000000052e5c8 000000000052f008 0000000000000000 0000000000000000
t8 t9 k0 k1
R24 0000000000000001 0000000010019010 0000000000000000 0000000000000000
gp sp s8 ra
R28 0000000010020280 000000007fff4be0 000000007fff4be0 0000000010004f48
status lo hi badvaddr
0000000000109cf3 0000000000943efe 000000000000000e 000000001001900c
cause pc
0000000000800024 0000000010004f48
fcsr fir hi1 lo1
0e800000 00f30000 <unavailable> <unavailable>
hi2 lo2 hi3 lo3
<unavailable> <unavailable> <unavailable> <unavailable>
dspctl restart
55aa33cc 0000000000000000
(gdb)
as there is no way to access full contents of these registers with the
limited API available anyway.
This obviously does not affect general-purpose registers (which use the
PTRACE_GETREGS and PTRACE_SETREGS requests for access) or floating-point
general registers (which use PTRACE_GETFPREGS and PTRACE_SETFPREGS).
And $dspctl, being 32-bit, remains accessible too, which is important
for BPOSGE32 branch decoding in single-stepping.
For DSP accumulator access with the n32 ABI a new `ptrace' API is required
on the kernel side.
gdb/
* mips-linux-nat.c (mips64_linux_register_addr): Return -1 if
the width of the requested register exceeds the width of the
`ptrace' data type.
gdb/gdbserver/
* linux-mips-low.c (mips_cannot_fetch_register): Return 1 if the
width of the requested register exceeds the width of the
`ptrace' data type.
(mips_cannot_store_register): Likewise.
Consistently supply hardwired $zero as a zeroed register, correcting
issues with the PTRACE_GETREGS path that currently copies the value of
$restart into $zero as illustrated by this program:
$ cat read.c
int
main (void)
{
char buf[1024];
ssize_t size;
size = read (0, buf, sizeof (buf));
return size;
}
$
and this corresponding debug session:
(gdb) break main
Breakpoint 1 at 0x120000970: file read.c, line 9.
(gdb) target remote :2346
Remote debugging using :2346
Reading symbols from .../sysroot/mips-r2-hard/lib64/ld.so.1...done.
0x000000fff7fca5a0 in __start ()
from .../sysroot/mips-r2-hard/lib64/ld.so.1
(gdb) continue
Continuing.
Breakpoint 1, main () at read.c:9
9 size = read (0, buf, sizeof (buf));
(gdb) info registers
zero at v0 v1
R0 0000000000000000 0000000000000001 000000fff7ffe710 0000000000000000
a0 a1 a2 a3
R4 0000000000000001 000000ffffffeb88 000000ffffffeb98 0000000000000000
a4 a5 a6 a7
R8 000000fff7fc8800 000000fff7fc38f0 000000ffffffeb80 2f2f2f2f2f2f2f2f
t0 t1 t2 t3
R12 0000000000000437 0000000000000002 000000fff7ffd000 0000000120000a00
s0 s1 s2 s3
R16 000000fff7fc7068 0000000120000b90 0000000000000000 0000000000000000
s4 s5 s6 s7
R20 0000000000521d88 0000000000522608 0000000000000000 0000000000000000
t8 t9 k0 k1
R24 0000000000000000 0000000120000970 0000000000000000 0000000000000000
gp sp s8 ra
R28 000000fff7fc8800 000000ffffffea50 0000000000000000 000000fff7e4088c
status lo hi badvaddr
0000000000109cf3 0000000000005ea5 0000000000000211 000000fff7eadf00
cause pc
0000000000800024 0000000120000970
fcsr fir restart
00000000 00f30000 0000000000000000
(gdb) continue
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x000000fff7f084ac in __GI___libc_read (fd=0, buf=0xffffffe640, nbytes=1024)
at ../sysdeps/unix/sysv/linux/read.c:27
27 return SYSCALL_CANCEL (read, fd, buf, nbytes);
(gdb) info registers
zero at v0 v1
R0 0000000000001388 0000000000000001 0000000000000200 000000fff7ffe710
a0 a1 a2 a3
R4 0000000000000000 000000ffffffe640 0000000000000400 0000000000000001
a4 a5 a6 a7
R8 000000fff7fc8800 000000fff7fc38f0 000000ffffffeb80 2f2f2f2f2f2f2f2f
t0 t1 t2 t3
R12 00000000000005e3 0000000000000002 000000fff7ffd000 000000012000099c
s0 s1 s2 s3
R16 000000fff7fc7068 0000000120000b90 0000000000000000 0000000000000000
s4 s5 s6 s7
R20 0000000000521d88 0000000000522608 0000000000000000 0000000000000000
t8 t9 k0 k1
R24 0000000000000000 000000fff7f2da20 0000000000000000 0000000000000000
gp sp s8 ra
R28 000000fff7fc8800 000000ffffffe600 0000000000000000 000000012000099c
status lo hi badvaddr
0000000000109cf3 00000000000001e6 00000000000000be 000000fff7f08470
cause pc
0000000000800020 000000fff7f084ac
fcsr fir restart
00000000 00f30000 0000000000001388
(gdb)
and with the PTRACE_PEEKUSR path that does not supply this register at
all, causing issues analogous to ones addressed for the native MIPS
backend with commit 4e6ff0e1b8 ("MIPS/Linux/native: Supply $zero for
the !PTRACE_GETREGS case"):
(gdb) info registers
zero at v0 v1
R0 <unavailable> 0000000000000001 0000000000000001 0000000000000000
a0 a1 a2 a3
R4 00000001200212b0 0000000000000000 0000000000000021 000000012001a260
a4 a5 a6 a7
R8 000000012001a260 0000000000000004 800000010cab1680 fffffffffffffff8
t0 t1 t2 t3
R12 0000000000000000 000000fff7edab68 0000000000000001 0000000000000000
s0 s1 s2 s3
R16 000000fff7ee2068 0000000120008b80 0000000000000000 0000000000000000
s4 s5 s6 s7
R20 000000000052e5c8 000000000052f008 0000000000000000 0000000000000000
t8 t9 k0 k1
R24 0000000000000000 00000001200027c0 0000000000000000 0000000000000000
gp sp s8 ra
R28 00000001200212b0 000000ffffffc880 000000ffffffc880 0000000120005ee8
status lo hi badvaddr
<unavailable> 0000000000943efe 000000000000000e 000000012001a008
cause pc
0000000000800024 0000000120005ee8
fcsr fir restart
0e800000 00f30000 0000000000000000
(gdb)
and (under certain circumstances):
(gdb) next
Register 0 is not available
(gdb)
The problem with PTRACE_GETREGS happens because `mips_store_gregset'
supplies the contents of register slot #0, occupied by $restart, to
$zero. The problem with PTRACE_PEEKUSR happens because for $zero
`mips_cannot_fetch_register' returns one, and no alternative way to
supply that register has been defined.
Correct `mips_store_gregset' then for the PTRACE_GETREGS case and add
`mips_fetch_register' for the PTRACE_PEEKUSR case.
gdb/gdbserver/
* linux-mips-low.c (mips_fetch_register): New function. Update
preceding comment.
(mips_store_gregset): Supply 0 rather than $restart for $zero.
(the_low_target): Wire `mips_fetch_register'.
The floating point context structure on x86 LynxOS-178 is not
the same as on LynxOS 5.x. As a consequence, trying to print
the return value of a function returning a float, for instance,
yields incorrect results.
This patch fixes the issue by providing an updated definition
for LynxOS-178 (the reason why we cannot access the actual definition
provided by the system still remains true).
gdb/gdbserver/ChangeLog:
* lynx-i386-low.c (LYNXOS_178): New macro.
[LYNXOS_178] (usr_fcontext_t): Provide a definition that matches
the layout on LynxOS-178.
(lynx_i386_fill_fpregset, lynx_i386_store_fpregset): Do not
handle floating point registers that are not supported by
LynxOS-178.
Simon pointed out that gdb would not build with clang, due to the
addition of -Wimplicit-fallthrough. This patch fixes the problem by
using -Wimplicit-fallthrough=3 -- this does not work with clang,
bypassing the issue.
Tested by rebuilding with both gcc and clang; and also by verifying
that -Wimplicit-fallthrough=3 is used in the gcc build.
I will file a follow-up bug to convert the fall-through comments to a
form that can be used by both clang and gcc.
gdb/ChangeLog
2018-05-10 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* warning.m4 (AM_GDB_WARNINGS): Use -Wimplicit-fallthrough=3.
gdb/gdbserver/ChangeLog
2018-05-10 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
On Windows, starting a new process with GDBserver seems to work,
in the sense that the program does get started, and GDBserver
confirms that it is listening for GDB to connect. However, as soon as
GDB establishes the connection with GDBserver, and starts discussing
with it, GDBserver crashes, with a SEGV.
This SEGV occurs in remote-utils.c::prepare_resume_reply...
| regp = current_target_desc ()->expedite_regs;
| [...]
| while (*regp)
... because, in our case, REGP is NULL.
This patches fixes the issues by adding a parameter to init_target_desc,
in order to make sure that we always provide the list of registers when
we initialize a target description.
gdb/ChangeLog:
PR server/23158:
* regformats/regdat.sh: Adjust script, following the addition
of the new expedite_regs parameter to init_target_desc.
gdb/gdbserver/ChangeLog:
PR server/23158:
* tdesc.h (init_target_desc) <expedite_regs>: New parameter.
* tdesc.c (init_target_desc) <expedite_regs>: New parameter.
Use it to set the expedite_regs field in the given tdesc.
* x86-tdesc.h: New file.
* linux-aarch64-tdesc.c (aarch64_linux_read_description):
Adjust following the addition of the new expedite_regs parameter
to init_target_desc.
* linux-tic6x-low.c (tic6x_read_description): Likewise.
* linux-x86-tdesc.c: #include "x86-tdesc.h".
(i386_linux_read_description, amd64_linux_read_description):
Adjust following the addition of the new expedite_regs parameter
to init_target_desc.
* lynx-i386-low.c: #include "x86-tdesc.h".
(lynx_i386_arch_setup): Adjust following the addition of the new
expedite_regs parameter to init_target_desc.
* nto-x86-low.c: #include "x86-tdesc.h".
(nto_x86_arch_setup): Adjust following the addition of the new
expedite_regs parameter to init_target_desc.
* win32-i386-low.c: #include "x86-tdesc.h".
(i386_arch_setup): Adjust following the addition of the new
expedite_regs parameter to init_target_desc.
Trying to start a program with GDBserver on Windows yields
the following error:
$ gdbserver.exe --once :4444 simple_main.exe
Killing process(es): 5008
No program to debug
Exiting
The error itself comes from the following code shortly after
create_inferior gets called (in server.c::main):
/* Wait till we are at first instruction in program. */
create_inferior (program_path.get (), program_args);
[...]
if (last_status.kind == TARGET_WAITKIND_EXITED
|| last_status.kind == TARGET_WAITKIND_SIGNALLED)
was_running = 0;
else
was_running = 1;
if (!was_running && !multi_mode)
error ("No program to debug");
What happens is that the "last_status" global starts initialized
as zeroes, which means last_status.kind == TARGET_WAITKIND_EXITED,
and we expect create_inferior to be waiting for the inferior to
start until reaching the SIGTRAP, and to set the "last_status"
global to match that last event we received.
I suspect this is an unintended side-effect of the following change...
commit 2090129c36
Date: Thu Dec 22 21:11:11 2016 -0500
Subject: Share fork_inferior et al with gdbserver
... which removes some code in server.c that was responsible for
starting the inferior in a functin that was named start_inferior,
and looked like this:
signal_pid = create_inferior (new_argv[0], &new_argv[0]);
[...]
/* Wait till we are at 1st instruction in program, return new pid
(assuming success). */
last_ptid = mywait (pid_to_ptid (signal_pid), &last_status, 0, 0);
The code has been transitioned to using fork_inferior, but sadly,
only for the targets that support it. On Windows, the calls to wait
setting "last_status" simply disappeared.
This patch adds it back in the Windows-specific implementation of
create_inferior.
gdb/gdbserver/ChangeLog:
PR server/23158:
* win32-low.c (win32_create_inferior): Add call to my_wait
setting last_status global.
Trying to start GDBserver on Windows currently yields the following
error...
$ gdbserver.exe --once :4444 simple_main.exe
glob could not process pattern '(null)'.
Exiting
... after which GDB terminates with a nonzero status.
This is because create_process in win32-low.c calls gdb_tilde_expand
with the result of a call to get_inferior_cwd without verifying that
the returned directory is not NULL:
| static BOOL
| create_process (const char *program, char *args,
| DWORD flags, PROCESS_INFORMATION *pi)
| {
| const char *inferior_cwd = get_inferior_cwd ();
| std::string expanded_infcwd = gdb_tilde_expand (inferior_cwd);
This patch avoids this by only calling gdb_tilde_expand when
INFERIOR_CWD is not NULL, which is similar to what is done on
GNU/Linux for instance.
gdb/gdbserver/ChangeLog:
PR server/23158:
* win32-low.c (create_process): Only call gdb_tilde_expand if
inferior_cwd is not NULL.
For GNU/Linux on x86-64, if the target is using the xsave format for
passing the floating-point information from the inferior then there
currently exists a bug relating to the x87 control registers, and the
mxcsr register.
The xsave format allows different floating-point features to be lazily
enabled, a bit in the xsave format tells GDB which floating-point
features have been enabled, and which have not.
Currently in GDB, when reading the floating point state, we check the
xsave bit flags, if the feature is enabled then we read the feature
from the xsave buffer, and if the feature is not enabled, then we
supply the default value from within GDB.
Within GDB, when writing the floating point state, we first fetch the
xsave state from the target and then, for any feature that is not yet
enabled, we write the default values into the xsave buffer. Next we
compare the regcache value with the value in the xsave buffer, and, if
the value has changed we update the value in the xsave buffer, and
mark the feature enabled in the xsave bit flags.
The problem then, is that the x87 control registers were not following
this pattern. We assumed that these registers were always written out
by the kernel, and we always wrote them out to the xsave buffer (but
didn't enabled the feature). The result of this is that if the kernel
had not yet enabled the x87 feature then within GDB we would see
random values for the x87 floating point control registers, and if the
user tried to modify one of these register, that modification would be
lost.
Finally, the mxcsr register was also broken in the same way as the x87
control registers. The added complexity with this case is that the
mxcsr register is part of both the avx and sse floating point feature
set. When reading or writing this register we need to check that at
least one of these features is enabled.
This bug was present in native GDB, and within gdbserver. Both are
fixed with this commit.
gdb/ChangeLog:
* common/x86-xstate.h (I387_FCTRL_INIT_VAL): New constant.
(I387_MXCSR_INIT_VAL): New constant.
* amd64-tdep.c (amd64_supply_xsave): Only read state from xsave
buffer if it was supplied by the inferior.
* i387-tdep.c (i387_supply_fsave): Use I387_MXCSR_INIT_VAL.
(i387_xsave_get_clear_bv): New function.
(i387_supply_xsave): Only read x87 control registers from the
xsave buffer if the feature is enabled, and the state will have
been written, otherwise, provide a suitable default.
(i387_collect_xsave): Pre-clear all registers in xsave buffer,
including x87 control registers. Update control registers if they
have changed from the default value, and mark features as enabled
as required.
* i387-tdep.h (i387_xsave_get_clear_bv): Declare.
gdb/gdbserver/ChangeLog:
* i387-fp.c (i387_cache_to_xsave): Only write x87 control
registers to the cache if their values have changed.
(i387_xsave_to_cache): Provide default values for x87 control
registers when these features are available, but disabled.
* regcache.c (supply_register_by_name_zeroed): New function.
* regcache.h (supply_register_by_name_zeroed): Declare new
function.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-init-x87-values.S: New file.
* gdb.arch/amd64-init-x87-values.exp: New file.
This adds -Wduplicated-cond to warnings.m4. This caught one bug.
I tried adding -Wduplicated-branches as well, but it results in some
spurious failures from code like this in cgen.h:
#define CGEN_ATTR_TYPE(n) \
struct { unsigned int bool_; \
CGEN_ATTR_VALUE_TYPE nonbool[(n) ? (n) : 1]; }
This will trigger a warning if passed n==1, which seems like a
perfectly valid thing to do; and there were other issues like this as
well.
ChangeLog
2018-05-07 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* warning.m4 (AM_GDB_WARNINGS): Add -Wduplicated-cond.
gdbserver/ChangeLog
2018-05-07 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
This adds -Wimplicit-fallthrough to the set of default warnings.
2018-05-04 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* warning.m4 (AM_GDB_WARNINGS): Add -Wimplicit-fallthrough.
gdbserver/ChangeLog
2018-05-04 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
Some unaligned watchpoints were currently missed.
On old kernels as specified in
kernel RFE: aarch64: ptrace: BAS: Support any contiguous range (edit)
https://sourceware.org/bugzilla/show_bug.cgi?id=20207
after this patch some other unaligned watchpoints will get reported as false
positives.
With new kernels all the watchpoints should work exactly.
There may be a regresion that it now less merges watchpoints so that with
multiple overlapping watchpoints it may run out of the 4 hardware watchpoint
registers. But as discussed in the original thread GDB needs some generic
watchpoints merging framework to be used by all the target specific code.
Even current FSF GDB code does not merge it perfectly. Also with the more
precise watchpoints one can technically merge them less. And I do not think
it matters too much to improve mergeability only for old kernels.
Still even on new kernels some better merging logic would make sense.
There remains one issue:
kernel-4.15.14-300.fc27.armv7hl
FAIL: gdb.base/watchpoint-unaligned.exp: continue
FAIL: gdb.base/watchpoint-unaligned.exp: continue
(gdb) continue
Continuing.
Unexpected error setting watchpoint: Invalid argument.
(gdb) FAIL: gdb.base/watchpoint-unaligned.exp: continue
But that looks as a kernel bug to me.
(1) It is not a regression by this patch.
(2) It is unrelated to this patch.
gdb/ChangeLog
2018-05-04 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
PR breakpoints/19806 and support for PR external/20207.
* NEWS: Mention Aarch64 watchpoint improvements.
* aarch64-linux-nat.c (aarch64_linux_stopped_data_address): Fix missed
watchpoints and PR external/20207 watchpoints.
* nat/aarch64-linux-hw-point.c
(kernel_supports_any_contiguous_range): New.
(aarch64_watchpoint_offset): New.
(aarch64_watchpoint_length): Support PR external/20207 watchpoints.
(aarch64_point_encode_ctrl_reg): New parameter offset, new asserts.
(aarch64_point_is_aligned): Support PR external/20207 watchpoints.
(aarch64_align_watchpoint): New parameters aligned_offset_p and
next_addr_orig_p. Support PR external/20207 watchpoints.
(aarch64_downgrade_regs): New.
(aarch64_dr_state_insert_one_point): New parameters offset and
addr_orig.
(aarch64_dr_state_remove_one_point): Likewise.
(aarch64_handle_breakpoint): Update caller.
(aarch64_handle_aligned_watchpoint): Likewise.
(aarch64_handle_unaligned_watchpoint): Support addr_orig and
aligned_offset.
(aarch64_linux_set_debug_regs): Remove const from state. Call
aarch64_downgrade_regs.
(aarch64_show_debug_reg_state): Print also dr_addr_orig_wp.
* nat/aarch64-linux-hw-point.h (DR_CONTROL_LENGTH): Rename to ...
(DR_CONTROL_MASK): ... this.
(struct aarch64_debug_reg_state): New field dr_addr_orig_wp.
(unsigned int aarch64_watchpoint_offset): New prototype.
(aarch64_linux_set_debug_regs): Remove const from state.
* utils.c (align_up, align_down): Move to ...
* common/common-utils.c (align_up, align_down): ... here.
* utils.h (align_up, align_down): Move to ...
* common/common-utils.h (align_up, align_down): ... here.
gdb/gdbserver/ChangeLog
2018-05-04 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
* linux-aarch64-low.c (aarch64_stopped_data_address):
Likewise.
gdb/testsuite/ChangeLog
2018-05-04 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
PR breakpoints/19806 and support for PR external/20207.
* gdb.base/watchpoint-unaligned.c: New file.
* gdb.base/watchpoint-unaligned.exp: New file.
I noticed the existence of -Wsuggest-override and so this patch
enables it for gdb. It found a few spots that could use "override".
Also I went ahead and removed all uses of the "OVERRIDE" macro.
Using override is beneficial because it makes it harder to change a
base class and then forget to change a derived class.
Tested by the buildbot.
ChangeLog
2018-04-27 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* warning.m4 (AM_GDB_WARNINGS): Add -Wsuggest-override.
* dwarf2loc.c (class dwarf_evaluate_loc_desc): Use "override", not
"OVERRIDE".
(class symbol_needs_eval_context): Likewise.
* dwarf2read.c (mock_mapped_index::symbol_name_count)
(mock_mapped_index::symbol_name_at): Use "override". Remove
"virtual".
* dwarf2-frame.c (dwarf_expr_executor::get_addr_index): Use
"override".
(class dwarf_expr_executor): Use "override", not "OVERRIDE".
* aarch64-tdep.c (instruction_reader::read): Use "override".
(instruction_reader_test::read): Likewise.
* arm-tdep.c (instruction_reader::read): Use "override".
(instruction_reader_thumb::read): Likewise.
gdbserver/ChangeLog
2018-04-27 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
Pedro pointed out that gdb/configure and gdbserver/configure weren't
updated after some recent *.m4 changes.
This patch rebuilds those files. Tested by rebuilding. Pedro
approved this in the thread where he raised this issue, so I'm pushing
it in.
ChangeLog
2018-04-23 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
gdbserver/ChangeLog
2018-04-23 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
The dependency tracking (the thing that knows which source file included
which other source file during last build to know what to rebuild when
an included file changes) is broken for gdbserver subdirectories (arch
and common).
The dependency tracking files are created in the form
arch/.deps/i386.Po
but we try to include
.deps/arch/i386.Po
An easy smoke test is too "touch" the gdb/features/i386/32bit-core.c
file in the source directory and try to rebuild gdbserver. This file is
included by gdb/arch/i386.c, so it should cause
gdb/gdbserver/arch/i386.o in the build directory to be rebuilt. It
currently isn't rebuilt, but is with this patch applied.
This patch copies the technique used in GDB to transform the dep file
paths to the proper form.
Also, while testing using the depcomp method of dependency tracking (by
just hacking the condition), I noticed that depcomp was not found. The
path to depcomp seems to be missing a "..".
gdb/gdbserver/ChangeLog:
* Makefile.in (depcomp): Add "..".
(all_deps_files): New and use it.
For ports which use new target descriptions, remove
the xml files from being built into gdbserver.
gdbserver/
* configure.srv (aarch64*-*-linux*): Don't include xml.
(i[34567]86-*-cygwin*): Likewise.
(i[34567]86-*-linux*): Likewise.
(i[34567]86-*-lynxos*): Likewise.
(i[34567]86-*-mingw32ce*): Likewise.
(i[34567]86-*-mingw*): Likewise.
(i[34567]86-*-nto*): Likewise.
(tic6x-*-uclinux): Likewise.
(x86_64-*-linux*): Likewise.
(x86_64-*-mingw*): Likewise.
(x86_64-*-cygwin*): Likewise.
Add a print_xml_feature visitor class which turns a
target description into xml. Both gdb and gdbserver can do this.
gdb/
* common/tdesc.c (print_xml_feature::visit_pre): Add xml parsing.
(print_xml_feature::visit_post): Likewise.
(print_xml_feature::visit): Likewise.
* common/tdesc.h (tdesc_get_features_xml): Use const tdesc.
(print_xml_feature): Add new class.
* regformats/regdat.sh: Null xmltarget on feature targets.
* target-descriptions.c (struct target_desc): Add xmltarget.
(maintenance_check_tdesc_xml_convert): Add unittest function.
(tdesc_get_features_xml): Add function to get xml.
(maintenance_check_xml_descriptions): Test xml generation.
* xml-tdesc.c (string_read_description_xml): Add function.
* xml-tdesc.h (string_read_description_xml): Add declaration.
gdbserver/
* gdb/gdbserver/server.c (get_features_xml): Remove cast.
* tdesc.c (void target_desc::accept): Fill in function.
(tdesc_get_features_xml): Remove old xml creation.
(print_xml_feature::visit_pre): Add xml vistor.
* tdesc.h (struct target_desc): Make xmltarget mutable.
(tdesc_get_features_xml): Remove declaration.