7 Commits

Author SHA1 Message Date
Andrew Burgess
424646edf4 gdbserver: handle all eval_result_type values in tracepoint.cc
It was pointed out[1] that after this commit:

  commit 3812b38d8de5804ad3eadd6c7a5d532402ddabab
  Date:   Thu Oct 20 11:14:33 2022 +0100

      gdbserver: allow agent expressions to fail with invalid memory access

Now that agent expressions might fail with the error
expr_eval_invalid_memory_access, we might overflow the
eval_result_names array in tracepoint.cc.  This is because the
eval_result_names array does not include a string for either
expr_eval_invalid_goto or expr_eval_invalid_memory_access.

I don't know if having expr_eval_invalid_goto missing is also a
problem, but it feels like eval_result_names should just include a
string for every possible error.

I could just add two more strings into the array, but I figure that a
more robust solution will be to move all of the error types, and their
associated strings, into a new ax-result-types.def file, and to then
include this file in both ax.h and tracepoint.cc in order to build
the enum eval_result_type and the eval_result_names string array.
Doing this means it is impossible to have a missing error string in
the future.

[1] https://inbox.sourceware.org/gdb-patches/01059f8a-0e59-55b5-f530-190c26df5ba3@palves.net/

Approved-By: Pedro Alves <pedro@palves.net>
2023-07-10 14:42:54 +01:00
Andrew Burgess
3812b38d8d gdbserver: allow agent expressions to fail with invalid memory access
This commit extends gdbserver to take account of a failed memory
access from agent_mem_read, and to return a new eval_result_type
expr_eval_invalid_memory_access.

I have only updated the agent_mem_read calls related directly to
reading memory, I have not updated any of the calls related to
tracepoint data collection.  This is just because I'm not familiar
with that area of gdb/gdbserver, and I don't want to break anything,
so leaving the existing behaviour untouched seems like the safest
approach.

I've then updated gdb.base/bp-cond-failure.exp to test evaluating the
breakpoints on the target, and have also extended the test so that it
checks for different sizes of memory access.
2023-04-03 14:46:32 +01:00
Joel Brobecker
213516ef31 Update copyright year range in header of all files managed by GDB
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
2023-01-01 17:01:16 +04:00
Joel Brobecker
4a94e36819 Automatic Copyright Year update after running gdb/copyright.py
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.

For the avoidance of doubt, all changes in this commits were
performed by the script.
2022-01-01 19:13:23 +04:00
Joel Brobecker
3666a04883 Update copyright year range in all GDB files
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...

gdb/ChangeLog

        Update copyright year range in copyright header of all GDB files.
2021-01-01 12:12:21 +04:00
Tom de Vries
f638ed7301 [gdbserver] Add missing include of gdbsupport/agent.h
The file gdbserver/ax.h contains:
...
 #ifdef IN_PROCESS_AGENT
 #define debug_threads debug_agent
 #endif
...
but does not declare debug_agent.

Fix this by adding an include of gdbsupport/agent.h.

[ If this fix would have been in place before commit 8118159c69 "[gdbserver] Fix
Wlto-type-mismatch for debug_agent", we would have simply run into this build
breaker with a regular, non-lto build:
...
src/gdbserver/ax.cc:28:5: error: conflicting declaration 'int debug_agent'
 int debug_agent = 0;
     ^~~~~~~~~~~
In file included from src/gdbserver/ax.h:25:0,
                 from src/gdbserver/ax.cc:20:
src/gdbsupport/agent.h:47:13: note: previous declaration as 'bool debug_agent'
 extern bool debug_agent;
             ^~~~~~~~~~~
... ]

Tested on x86_64-linux.

gdbserver/ChangeLog:

2020-06-29  Tom de Vries  <tdevries@suse.de>

	* ax.h: Include gdbsupport/debug_agent.h.
2020-06-29 12:14:10 +02:00
Tom Tromey
919adfe840 Move gdbserver to top level
This patch moves gdbserver to the top level.

This patch is as close to a pure move as possible -- gdbserver still
builds its own variant of gnulib and gdbsupport.  Changing this will
be done in a separate patch.

[v2] Note that, per Simon's review comment, this patch changes the
tree so that gdbserver is not built for or1k or score.  This makes
sense, because there is apparently not actually a gdbserver port here.

[v3] This version of the patch also splits out some configury into a
new file, gdbserver/configure.host, so that the top-level configure
script can simply rely on it in order to decide whether gdbserver
should be built.

[v4] This version adds documentation and removes some unnecessary
top-level dependencies.

[v5] Update docs to mention "make all-gdbserver" and change how
top-level configure decides whether to build gdbserver, switching to a
single, shared script.

Tested by the buildbot.

ChangeLog
2020-02-07  Tom Tromey  <tom@tromey.com>
	    Pedro Alves  <palves@redhat.com>

	* src-release.sh (GDB_SUPPORT_DIRS): Add gdbserver.
	* gdbserver: New directory, moved from gdb/gdbserver.
	* configure.ac (host_tools): Add gdbserver.
	Only build gdbserver on certain systems.
	* Makefile.in, configure: Rebuild.
	* Makefile.def (host_modules, dependencies): Add gdbserver.
	* MAINTAINERS: Add gdbserver.

gdb/ChangeLog
2020-02-07  Tom Tromey  <tom@tromey.com>

	* README: Update gdbserver documentation.
	* gdbserver: Move to top level.
	* configure.tgt (build_gdbserver): Remove.
	* configure.ac: Remove --enable-gdbserver.
	* configure: Rebuild.
	* Makefile.in (distclean): Don't mention gdbserver.

Change-Id: I826b7565b54604711dc7a11edea0499cd51ff39e
2020-02-07 08:42:25 -07:00