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.
A build error on x86_64 with x32 abi was reported here (
https://sourceware.org/pipermail/gdb/2021-November/049787.html ):
...
gdb/nat/amd64-linux-siginfo.c:280:42: error: \
'struct compat_x32_siginfo_t::<unnamed union>::<unnamed>' has no member \
named 'si_addr_bnd'
280 | #define cpt_si_lower _sifields._sigfault.si_addr_bnd._lower
| ^~~~~~~~~~~
gdb/nat/amd64-linux-siginfo.c:337:38: note: in expansion of macro 'cpt_si_lower'
337 | to->cpt_si_lower = from_ptrace.cpt_si_lower;
| ^~~~~~~~~~~~
...
The problem is that code added in commit d3d7d1ba3b "[gdb/tdep] Handle
si_addr_bnd in compat_siginfo_from_siginfo" doesn't compile on an x86_64 x32
setup, because compat_x32_siginfo_t doesn't have the si_addr_bnd fields.
Fix this conservatively by disabling the code for x32.
Tested on x86_64-linux.
On gcc-12 build fails as:
../../gdbserver/../gdb/nat/linux-osdata.c: In function 'void linux_xfer_osdata_processes(buffer*)':
../../gdbserver/../gdb/nat/linux-osdata.c:330:39: error:
'__builtin___sprintf_chk' may write a terminating nul past the end of the destination [-Werror=format-overflow=]
330 | sprintf (core_str, "%d", i);
| ^
It's an off-by-one case in an infeasible scenario for negative
huge core count. The change switches to std::string for memory
handling.
Tested by running 'info os processes' and checking CPU cores column.
The rhES5 build failed due to an upstream import a while back. The
bug here is that, while the 'personality' function exists,
ADDR_NO_RANDOMIZE is only defined in <linux/personality.h>, not
<sys/personality.h>.
However, <linux/personality.h> does not declare the 'personality'
function, and <sys/personality.h> and <linux/personality.h> cannot
both be included.
This patch restores one of the removed configure checks and updates
the code to check it.
We had this as a local patch at AdaCore, because it seemed like there
was no interest upstream. However, now it turns out that this fixes
PR build/28555, so I'm sending it now.
I stumbled on a bug caused by the fact that a code path read
target_waitstatus::value::sig (expecting it to contain a gdb_signal
value) while target_waitstatus::kind was TARGET_WAITKIND_FORKED. This
meant that the active union field was in fact
target_waitstatus::value::related_pid, and contained a ptid. The read
signal value was therefore garbage, and that caused GDB to crash soon
after. Or, since that GDB was built with ubsan, this nice error
message:
/home/simark/src/binutils-gdb/gdb/linux-nat.c:1271:12: runtime error: load of value 2686365, which is not a valid value for type 'gdb_signal'
Despite being a large-ish change, I think it would be nice to make
target_waitstatus safe against that kind of bug. As already done
elsewhere (e.g. dynamic_prop), validate that the type of value read from
the union matches what is supposed to be the active field.
- Make the kind and value of target_waitstatus private.
- Make the kind initialized to TARGET_WAITKIND_IGNORE on
target_waitstatus construction. This is what most users appear to do
explicitly.
- Add setters, one for each kind. Each setter takes as a parameter the
data associated to that kind, if any. This makes it impossible to
forget to attach the associated data.
- Add getters, one for each associated data type. Each getter
validates that the data type fetched by the user matches the wait
status kind.
- Change "integer" to "exit_status", "related_pid" to "child_ptid",
just because that's more precise terminology.
- Fix all users.
That last point is semi-mechanical. There are a lot of obvious changes,
but some less obvious ones. For example, it's not possible to set the
kind at some point and the associated data later, as some users did.
But in any case, the intent of the code should not change in this patch.
This was tested on x86-64 Linux (unix, native-gdbserver and
native-extended-gdbserver boards). It was built-tested on x86-64
FreeBSD, NetBSD, MinGW and macOS. The rest of the changes to native
files was done as a best effort. If I forgot any place to update in
these files, it should be easy to fix (unless the change happens to
reveal an actual bug).
Change-Id: I0ae967df1ff6e28de78abbe3ac9b4b2ff4ad03b7
Since the two locations which check the debug arch are the same code currently, it is
a good idea to factor it out to a new function and just use that function from
aarch64_linux_get_debug_reg_capacity. This is also the first step to support
ARMv8.4 debug arch.
Make gdb_open_cloexec return a scoped_fd, to encourage using automatic
management of the file descriptor closing. Except in the most trivial
cases, I changed the callers to just release the fd, which retains their
existing behavior. That will allow the transition to using scoped_fd
more to go gradually, one caller at a time.
Change-Id: Ife022b403f96e71d5ebb4f1056ef6251b30fe554
I wanted to find, and potentially modify, all the spots where the
'tid' parameter to the ptid_t constructor was used. So, I temporarily
removed this parameter and then rebuilt.
In order to make it simpler to search through the "real" (nonzero)
uses of this parameter, something I knew I'd have to do multiple
times, I removed any ", 0" from constructor calls.
Co-Authored-By: John Baldwin <jhb@FreeBSD.org>
On a Windows build locally, watchpoints started failing. I tracked
this down to x86_dr_low_get_addr returning an 'unsigned long'... in
this particular build, this is a 32-bit type, but the inferior is a
64-bit program.
This patch fixes the problem by changing the return type. No other
change is required, because this matches the function pointer in
struct x86_dr_low_type.
Same idea as the previous patch, but for m_cwd.
To keep things consistent across the board, change get_inferior_cwd as
well, which is shared with GDBserver. So update the related GDBserver
code too.
Change-Id: Ia2c047fda738d45f3d18bc999eb67ceb8400ce4e
I'm debugging why GDB crashes on OpenBSD/amd64, turns out it's because
x86_dr_low.get_status is nullptr. It would have been useful to be able
to break on x86_dr_low_get_status, so I thought it would be a good
reason to convert these function-like macros into functions.
Change-Id: Ic200b50ef8455b4697bc518da0fa2bb704cf4721
Since GDB is written in C++ now, we don't need struct/union typedefs
any more. Remove them from nat/amd64-linux-siginfo.c.
gdb/ChangeLog:
yyyy-mm-dd Pedro Alves <pedro@palves.net>
* nat/amd64-linux-siginfo.c (union nat_sigval): Rename to ...
(nat_sigval_t): ... this and remove typedef of same name.
(struct nat_siginfo): Rename to ...
(nat_siginfo_t): ... this and remove typedef of same name.
(struct compat_sigval): Rename to ...
(compat_sigval_t): ... this and remove typedef of same name.
(struct compat_siginfo): Rename to ...
(compat_siginfo_t): ... this and remove typedef of same name.
(struct compat_x32_siginfo): Rename to ...
(compat_x32_siginfo_t): ... this and remove typedef of same name.
(amd64_linux_siginfo_fixup_common): Adjust.
Compiling GDB with current git Clang (future 13) fails with (among
other problems), this issue:
$ make nat/amd64-linux-siginfo.o
CXX nat/amd64-linux-siginfo.o
src/gdb/nat/amd64-linux-siginfo.c:590:35: warning: passing 4-byte aligned argument to 8-byte aligned parameter 1 of 'compat_x32_siginfo_from_siginfo' may result in an unaligned pointer access [-Walign-mismatch]
compat_x32_siginfo_from_siginfo ((struct compat_x32_siginfo *) inf,
^
1 warning generated.
The problem is that:
- The flagged code is casting to "struct compat_x32_siginfo" pointer
directly instead of to a pointer to the compat_x32_siginfo_t
typedef. The called function is declared with a
compat_x32_siginfo_t typedef pointer parameter.
- Only the typedef has the __aligned__ attribute.
Fix this by moving the attribute to the struct, so both struct and
typedef have the same alignment.
The next patch removes the typedefs.
gdb/ChangeLog:
yyyy-mm-dd Pedro Alves <pedro@palves.net>
* nat/amd64-linux-siginfo.c (compat_x32_siginfo_t): Move
__attribute__ __aligned__ from the typedef to the struct.
I spotted some indentation issues where we had some spaces followed by
tabs at beginning of line, that I wanted to fix. So while at it, I did
a quick grep to find and fix all I could find.
gdb/ChangeLog:
* Fix tab after space indentation issues throughout.
Change-Id: I1acb414dd9c593b474ae2b8667496584df4316fd
I wrote a small script to spot a pattern of indentation mistakes I saw
happened in breakpoint.c. And while at it I ran it on all files and
fixed what I found. No behavior changes intended, just indentation and
addition / removal of curly braces.
gdb/ChangeLog:
* Fix some indentation mistakes throughout.
gdbserver/ChangeLog:
* Fix some indentation mistakes throughout.
Change-Id: Ia01990c26c38e83a243d8f33da1d494f16315c6e
I tried a build using the undefined behavior sanitizer, and gcc gave
this error:
In file included from /usr/include/string.h:495,
from ../gnulib/import/string.h:41,
from ../../binutils-gdb/gdb/../gdbsupport/common-defs.h:95,
from ../../binutils-gdb/gdb/nat/linux-osdata.c:20:
In function 'char* strncpy(char*, const char*, size_t)',
inlined from 'void time_from_time_t(char*, int, TIME_T)' at ../../binutils-gdb/gdb/nat/linux-osdata.c:923:15,
inlined from 'void time_from_time_t(char*, int, TIME_T)' at ../../binutils-gdb/gdb/nat/linux-osdata.c:911:1,
inlined from 'void linux_xfer_osdata_sem(buffer*)' at ../../binutils-gdb/gdb/nat/linux-osdata.c:1082:22:
/usr/include/bits/string_fortified.h:106:34: error: 'char* __builtin_strncpy(char*, const char*, long unsigned int)' specified bound 32 equals destination size [-Werror=stringop-truncation]
This patch fixes the problem by subtracting one from the length
parameter to strncpy.
I changed a couple of other similar functions -- gcc does not warn
about these, but I didn't see any substantial difference between the
different cases, and I think these are just latent warnings, to be
triggered in the future by a change to inlining heuristics.
gdb/ChangeLog
2021-05-17 Tom Tromey <tromey@adacore.com>
* nat/linux-osdata.c (user_from_uid, time_from_time_t)
(group_from_gid): Subtract one from strncpy length.
I was looking at some "set debug lin-lwp" logs, and saw that a thread
received the "Child exited" signal. It took me a moment to realize that
this was SIGCHLD. I then thought that it would be nice for
status_to_str to show the signal name (SIGCHLD) in addition to the
description "Child exited", since people are much more used to referring
to signals using their names.
Fortunately, libiberty contains a handy function to get the signal name
from the signal number, strsigno, use that.
The output of "set debug lin-lwp" now looks like:
[linux-nat] linux_nat_wait_1: waitpid 1209631 received SIGTRAP - Trace/breakpoint trap (stopped)
gdb/ChangeLog:
* nat/linux-waitpid.c (status_to_str): Show signal name.
Change-Id: I8ad9b1e744dd64461fd87b08d5c29f9ef97c4691
Instead of using a static buffer. This is safer, and we don't really
mind about any extra dynamic allocation here, since it's only used for
debug purposes.
gdb/ChangeLog:
* nat/linux-waitpid.c (status_to_str): Return std::string.
* nat/linux-waitpid.h (status_to_str): Likewise.
* linux-nat.c (linux_nat_post_attach_wait): Adjust.
(linux_nat_target::attach): Adjust.
(linux_handle_extended_wait): Adjust.
(wait_lwp): Adjust.
(stop_wait_callback): Adjust.
(linux_nat_filter_event): Adjust.
(linux_nat_wait_1): Adjust.
* nat/linux-waitpid.c (status_to_str): Adjust.
* nat/linux-waitpid.h (status_to_str): Adjust.
gdbserver/ChangeLog:
* linux-low.cc (linux_process_target::wait_for_event_filtered):
Adjust to status_to_str returning std::string.
Change-Id: Ia8aead70270438a5690f243e6faafff6c38ff757
Currently, in order to tell whether support for disabling address
space randomization on Linux is available, GDB checks if the
personality syscall works, at configure time. I.e., it does a run
test, instead of a compile/link test:
AC_RUN_IFELSE([PERSONALITY_TEST],
[have_personality=true],
[have_personality=false],
This is a bit bogus, because the machine the build is done on may not
(and is when you consider distro gdbs) be the machine that eventually
runs gdb. It would be better if this were a compile/link test
instead, and then at runtime, GDB coped with the personality syscall
failing. Actually, GDB already copes.
One environment where this is problematic is building GDB in a Docker
container -- by default, Docker runs the container with seccomp, with
a profile that disables the personality syscall. You can tell Docker
to use a less restricted seccomp profile, but I think we should just
fix it in GDB.
"man 2 personality" says:
This system call first appeared in Linux 1.1.20 (and thus first
in a stable kernel release with Linux 1.2.0); library support
was added in glibc 2.3.
...
ADDR_NO_RANDOMIZE (since Linux 2.6.12)
With this flag set, disable address-space-layout randomization.
glibc 2.3 was released in 2002.
Linux 2.6.12 was released in 2005.
The original patch that added the configure checks was submitted in
2008. The first version of the patch that was submitted to the list
called personality from common code:
https://sourceware.org/pipermail/gdb-patches/2008-June/058204.html
and then was moved to Linux-specific code:
https://sourceware.org/pipermail/gdb-patches/2008-June/058209.html
Since HAVE_PERSONALITY is only checked in Linux code, and
ADDR_NO_RANDOMIZE exists for over 15 years, I propose just completely
removing the configure checks.
If for some odd reason, some remotely modern system still needs a
configure check, then we can revert this commit but drop the
AC_RUN_IFELSE in favor of always doing the AC_LINK_IFELSE
cross-compile fallback.
gdb/ChangeLog:
* linux-nat.c (linux_nat_target::supports_disable_randomization):
Remove references to HAVE_PERSONALITY.
* nat/linux-personality.c: Remove references to HAVE_PERSONALITY.
(maybe_disable_address_space_randomization)
(~maybe_disable_address_space_randomizatio): Remove references to
HAVE_PERSONALITY.
* config.in, configure: Regenerate.
gdbserver/ChangeLog:
* linux-low.cc:
(linux_process_target::supports_disable_randomization): Remove
reference to HAVE_PERSONALITY.
* config.in, configure: Regenerate.
gdbsupport/ChangeLog:
* common.m4 (personality test): Remove.
The only callers of get_image_name are nat/windows-nat.c, so make it
static.
gdb/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* nat/windows-nat.h (get_image_name): Don't declare.
* nat/windows-nat.c (get_image_name): Now static.
This moves the new DLL-loading code into nat/windows-nat.c, and
changes both gdb and gdbserver to use the shared code. One
client-provided callback, handle_load_dll, is changed to allow the
code to be shared. This callback was actually never called from
nat/windows-nat.c; maybe I had planned to share more here and then
didn't finish... I'm not sure.
gdb/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* windows-nat.c (windows_nat::handle_load_dll): Update.
(windows_nat_target::get_windows_debug_event): Call
dll_loaded_event.
(windows_add_all_dlls, windows_add_dll): Move to
nat/windows-nat.c.
* nat/windows-nat.h (handle_load_dll): Change parameters.
(dll_loaded_event, windows_add_all_dlls): Declare.
* nat/windows-nat.c (windows_add_dll, windows_add_all_dlls): Move
from windows-nat.c.
(dll_loaded_event): New function.
gdbserver/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* win32-low.cc (do_initial_child_stuff): Update.
(windows_nat::handle_load_dll): Rename from win32_add_one_solib.
Change parameter type.
(win32_add_dll, win32_add_all_dlls)
(windows_nat::handle_load_dll): Remove.
(get_child_debug_event): Call dll_loaded_event.
This changes gdbserver to use the function indirection code that was
just moved into nat/windows-nat.[ch]. One additional function is used
by gdbserver that was not used by gdb.
gdb/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* nat/windows-nat.h (GenerateConsoleCtrlEvent): New define.
(GenerateConsoleCtrlEvent_ftype, GenerateConsoleCtrlEvent):
Declare.
* nat/windows-nat.c (GenerateConsoleCtrlEvent): Define.
(initialize_loadable): Initialize GenerateConsoleCtrlEvent.
gdbserver/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* win32-low.cc (GETPROCADDRESS): Remove.
(winapi_DebugActiveProcessStop, winapi_DebugSetProcessKillOnExit)
(winapi_DebugBreakProcess, winapi_GenerateConsoleCtrlEvent)
(winapi_Wow64SetThreadContext, win32_Wow64GetThreadContext)
(win32_Wow64SetThreadContext): Remove.
(win32_set_thread_context, do_initial_child_stuff)
(win32_process_target::attach, win32_process_target::detach):
Update.
(winapi_EnumProcessModules, winapi_EnumProcessModulesEx)
(winapi_GetModuleInformation, winapi_GetModuleInformationA):
Remove.
(win32_EnumProcessModules, win32_EnumProcessModulesEx)
(win32_GetModuleInformation, win32_GetModuleInformationA):
Remove.
(load_psapi): Remove.
(win32_add_dll, win32_process_target::request_interrupt): Update.
(initialize_low): Call initialize_loadable.
gdb and gdbserver both look for functions in some Windows DLLs at
runtime. This patch moves this code out of gdb and into
nat/windows-nat, so it can be shared by both programs.
gdb/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* windows-nat.c: Move code to nat/windows-nat.[ch].
(_initialize_windows_nat): Call initialize_loadable.
* nat/windows-nat.h (AdjustTokenPrivileges)
(DebugActiveProcessStop, DebugBreakProcess)
(DebugSetProcessKillOnExit, EnumProcessModules)
(EnumProcessModulesEx, GetModuleInformation)
(GetModuleFileNameExA, GetModuleFileNameExW)
(LookupPrivilegeValueA, OpenProcessToken, GetConsoleFontSize)
(GetCurrentConsoleFont, Wow64SuspendThread)
(Wow64GetThreadContext, Wow64SetThreadContext)
(Wow64GetThreadSelectorEntry): Move from windows-nat.c.
(AdjustTokenPrivileges_ftype)
(DebugActiveProcessStop_ftype, DebugBreakProcess_ftype)
(DebugSetProcessKillOnExit_ftype, EnumProcessModules_ftype)
(EnumProcessModulesEx_ftype, GetModuleInformation_ftype)
(GetModuleFileNameExA_ftype, GetModuleFileNameExW_ftype)
(LookupPrivilegeValueA_ftype, OpenProcessToken_ftype)
(GetConsoleFontSize_ftype)
(GetCurrentConsoleFont_ftype, Wow64SuspendThread_ftype)
(Wow64GetThreadContext_ftype, Wow64SetThreadContext_ftype)
(Wow64GetThreadSelectorEntry_ftype): Likewise.
(initialize_loadable): Declare.
* nat/windows-nat.c (AdjustTokenPrivileges)
(DebugActiveProcessStop, DebugBreakProcess)
(DebugSetProcessKillOnExit, EnumProcessModules)
(EnumProcessModulesEx, GetModuleInformation, GetModuleFileNameExA)
(GetModuleFileNameExW, LookupPrivilegeValueA, OpenProcessToken)
(GetCurrentConsoleFont, GetConsoleFontSize, Wow64SuspendThread)
(Wow64GetThreadContext, Wow64SetThreadContext)
(Wow64GetThreadSelectorEntry): Define.
(bad, bad_GetCurrentConsoleFont, bad_GetConsoleFontSize): Move
from windows-nat.c.
(initialize_loadable): Likewise, and rename.
The support for WinCE was removed with commit 84b300de36 ("gdbserver:
remove support for ARM/WinCE"). There is some leftover code for WinCE
support, guarded by the _WIN32_WCE macro, which I didn't know of at the
time.
I didn't remove the _WIN32_WCE references in the tests, because in
theory we still support the WinCE architecture in GDB (when debugging
remotely). So someone could run a test with that (although I'd be
really surprised).
gdb/ChangeLog:
* nat/windows-nat.c: Remove all code guarded by _WIN32_WCE.
* nat/windows-nat.h: Likewise.
gdbserver/ChangeLog:
* win32-low.cc: Remove all code guarded by _WIN32_WCE.
* win32-low.h: Likewise.
Change-Id: I7a871b897e2135dc195b10690bff2a01d9fac05a
Similarly to commit 665af52ec2, fix a build
failure seen with an updated glibc, due to the enum/constant mismatch.
The old include file order eventually makes asm/ptrace.h get included before
sys/ptrace.h.
This patch fixes it. Seems fairly obvious and I'll push it shortly.
gdb/ChangeLog:
2021-04-09 Luis Machado <luis.machado@linaro.org>
* nat/aarch64-mte-linux-ptrace.c: Update include file order.
The patch implements the memory tagging target hooks for AArch64, so we
can handle MTE.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* Makefile.in (ALL_64_TARGET_OBS): Add arch/aarch64-mte-linux.o.
(HFILES_NO_SRCDIR): Add arch/aarch64-mte-linux.h and
nat/aarch64-mte-linux-ptrace.h.
* aarch64-linux-nat.c: Include nat/aarch64-mte-linux-ptrace.h.
(aarch64_linux_nat_target) <supports_memory_tagging>: New method
override.
<fetch_memtags>: New method override.
<store_memtags>: New method override.
(aarch64_linux_nat_target::supports_memory_tagging): New method.
(aarch64_linux_nat_target::fetch_memtags): New method.
(aarch64_linux_nat_target::store_memtags): New method.
* arch/aarch64-mte-linux.c: New file.
* arch/aarch64-mte-linux.h: Include gdbsupport/common-defs.h.
(AARCH64_MTE_GRANULE_SIZE): Define.
(aarch64_memtag_type): New enum.
(aarch64_mte_get_tag_granules): New prototype.
* configure.nat (NATDEPFILES): Add nat/aarch64-mte-linux-ptrace.o.
* configure.tgt (aarch64*-*-linux*): Add arch/aarch64-mte-linux.o.
* nat/aarch64-mte-linux-ptrace.c: New file.
* nat/aarch64-mte-linux-ptrace.h: New file.
This patch adds the required ptrace request definitions into a new include
file that will be used by the next patches.
They are PTRACE_PEEKMTETAGS and PTRACE_POKEMTETAGS.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* Makefile.in (HFILES_NO_SRCDIR): Add nat/aarch64-mte-linux-ptrace.h.
* nat/aarch64-mte-linux-ptrace.h: New file.
I added the same comment for nat/aarch64-linux-hw-point.c yesterday.
Christian suggested adding the comment for the other file that I had
identified as including both <sys/ptrace.h> and <asm/ptrace.h>.
I searched the sources in gdb/, but found no other files which include
both of these headers.
If possible, I would prefer to see us use <sys/ptrace.h> when possible,
however, from past experience, I've found that this file does not always
contain all of the constants, etc. required by the particular source
file.
gdb/ChangeLog:
* nat/aarch64-sve-linux-ptrace.h: Add comment regarding include
order for <sys/ptrace.h> and <asm/ptrace.h>.
Due to a recent glibc header file change, the file
nat/aarch64-linux-hw-point.c no longer builds on Fedora rawhide.
An enum for PTRACE_SYSEMU is now provided by <sys/ptrace.h>. In the
past, PTRACE_SYSEMU was defined only in <asm/ptrace.h>. This is
what it looks like...
In <asm/ptrace.h>:
#define PTRACE_SYSEMU 31
In <sys/ptrace.h>:
enum __ptrace_request
{
...
PTRACE_SYSEMU = 31,
#define PT_SYSEMU PTRACE_SYSEMU
...
}
When <asm/ptrace.h> and <sys/ptrace.h> are both included in a source
file, we run into the following build problem when the former is
included before the latter:
In file included from nat/aarch64-linux-hw-point.c:26:
/usr/include/sys/ptrace.h:86:3: error: expected identifier before numeric constant
86 | PTRACE_SYSEMU = 31,
| ^~~~~~~~~~~~~
(There are more errors after this one too.)
The file builds without error when <asm/ptrace.h> is included after
<sys/ptrace.h>. I found that this is already done in
nat/aarch64-sve-linux-ptrace.h (which is included by
nat/aarch64-linux-ptrace.c).
I've tested this change on Fedora rawhide and Fedora 33, both
running on an aarch64 machine.
gdb/ChangeLog:
* nat/aarch64-linux-hw-point.c: Include <asm/ptrace.h> after
<sys/ptrace.h>.
On Fedora rawhide, after updating to glibc-2.33, I'm seeing the
following build failure:
CXX nat/amd64-linux-siginfo.o
In file included from /usr/include/bits/sigstksz.h:24,
from /usr/include/signal.h:315,
from ../gnulib/import/signal.h:52,
from /ironwood1/sourceware-git/rawhide-gnulib/bld/../../worktree-gnulib/gdbserver/../gdb/nat/amd64-linux-siginfo.c:20:
../gnulib/import/unistd.h:663:3: error: #error "Please include config.h first."
663 | #error "Please include config.h first."
| ^~~~~
glibc-2.33 has changed signal.h to now include <bits/sigstksz.h> which,
in turn, includes <unistd.h>. For a gdb build, this causes the gnulib
version of unistd.h to be pulled in first. The build failure shown
above happens because gnulib's config.h has not been included before
the include of <signal.h>.
The fix is simple - we just rearrange the order of the header file
includes to make sure that gdbsupport/commondefs.h is included before
attempting to include signal.h. Note that gdbsupport/commondefs.h
includes <gnulib/config.h>.
Build and regression tested on Fedora 33. On Fedora rawhide, GDB
builds again.
gdb/ChangeLog:
* nat/amd64-linux-siginfo.c: Include "gdbsupport/common-defs.h"
(which in turn includes <gnulib/config.h>) before include
of <signal.h>.
This changes windows-nat.c and nat/windows-nat.c to use the new
debug_prefixed_printf_cond facility. I tried this out on a Windows
build and I think it makes the output look a little nicer.
2021-01-26 Tom Tromey <tromey@adacore.com>
* windows-nat.c (DEBUG_EXEC, DEBUG_EVENTS, DEBUG_MEM)
(DEBUG_EXCEPT): Use debug_prefixed_printf_cond.
(windows_init_thread_list, windows_nat::handle_load_dll)
(windows_nat::handle_unload_dll, windows_nat_target::resume)
(windows_nat_target::resume)
(windows_nat_target::get_windows_debug_event)
(windows_nat_target::interrupt, windows_xfer_memory)
(windows_nat_target::close): Update.
* nat/windows-nat.c (DEBUG_EVENTS): Use
debug_prefixed_printf_cond.
(matching_pending_stop, fetch_pending_stop)
(continue_last_debug_event): Update.
When running test-case gdb.arch/i386-mpx-sigsegv.exp with target board
unix/-m32, we run into:
...
(gdb) continue^M
Continuing.^M
Saw a #BR! status 1 at 0x8048c2d^M
^M
Program received signal SIGSEGV, Segmentation fault^M
Upper bound violation while accessing address 0x0804c15c^M
Bounds: [lower = 0x00000000, upper = 0x00000000].^M
0x08048a4f in lower (p=0x804c160, a=0x804c180, b=0x804c1a0, c=0x804c1c0, \
d=0x804c1e0, len=1) at i386-mpx-sigsegv.c:79^M
79 value = *(p - len);^M
(gdb) FAIL: gdb.arch/i386-mpx-sigsegv.exp: MPX signal segv Lower: 0
...
The problem is that lower and upper in the Bounds message are 0x0, which is
caused by $_siginfo._sifields._sigfault._addr_bnd.{_lower,_upper} evaluating
to 0x0.
Fix this by copying the si_lower/si_upper fields in
compat_siginfo_from_siginfo.
Tested on x86_64-linux, with target board unix/-m32.
gdb/ChangeLog:
2021-01-18 Tom de Vries <tdevries@suse.de>
PR tdep/27172
* nat/amd64-linux-siginfo.c (cpt_si_lower, cpt_si_upper, SEGV_BNDERR):
New macro.
(compat_siginfo_from_siginfo): Copy cpt_si_lower and cpt_si_upper
for SEGV_BNDERR.
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.
The FPSIMD dump in signal frames and ptrace FPSIMD dump in the SVE context
structure follows the target endianness, whereas the SVE dumps are
endianness-independent (LE).
Therefore, when the system is in BE mode, we need to reverse the bytes
for the FPSIMD data.
Given the V registers are larger than 64-bit, I've added a way for value
bytes to be set, as opposed to passing a 64-bit fixed quantity. This fits
nicely with the unwinding *_got_bytes function and makes the trad-frame
more flexible and capable of saving larger registers.
The memory for the bytes is allocated via the frame obstack, so it gets freed
after we're done inspecting the frame.
gdb/ChangeLog:
2020-12-10 Luis Machado <luis.machado@linaro.org>
* aarch64-linux-tdep.c (aarch64_linux_restore_vreg) New function.
(aarch64_linux_sigframe_init): Call aarch64_linux_restore_vreg.
* aarch64-tdep.h (V_REGISTER_SIZE): Move to ...
* arch/aarch64.h: ... here.
* nat/aarch64-sve-linux-ptrace.c: Include endian.h.
(aarch64_maybe_swab128): New function.
(aarch64_sve_regs_copy_to_reg_buf)
(aarch64_sve_regs_copy_from_reg_buf): Adjust FPSIMD entries.
* trad-frame.c (trad_frame_reset_saved_regs): Initialize
the data field.
(TF_REG_VALUE_BYTES): New enum value.
(trad_frame_value_bytes_p): New function.
(trad_frame_set_value_bytes): New function.
(trad_frame_set_reg_value_bytes): New function.
(trad_frame_get_prev_register): Handle register values saved as bytes.
* trad-frame.h (trad_frame_set_reg_value_bytes): New prototype.
(struct trad_frame_saved_reg) <data>: New field.
(trad_frame_set_value_bytes): New prototype.
(trad_frame_value_bytes_p): New prototype.
This eliminates the need to specify the return type when using
handle_eintr. We let the compiler deduce it for us.
Also, use lowercase for function parameter names. Uppercase should
only be used on template parameters.
gdb/ChangeLog:
* nat/linux-waitpid.c: Include "gdbsupport/eintr.h".
(my_waitpid): Use gdb::handle_eintr.
gdbserver/ChangeLog:
* netbsd-low.cc (netbsd_waitpid, netbsd_process_target::kill)
(netbsd_qxfer_libraries_svr4): Use gdb::handle_eintr without
explicit type.
gdbsupport/ChangeLog:
* eintr.h (handle_eintr): Replace Ret template parameter with
ErrorValType. Use it as type of the failure value. Deduce the
function's return type using decltype. Use lowercase for function
parameter names.
In case of repeated ptrace PT_IO call and returning the value of
transferred bytes equal to 0, do not return without setting
xfered_len.
gdb/ChangeLog:
* nat/netbsd-nat.c (write_memory, read_memory): Update.
Instead of sharing the native-only code with all BSDs with slightly
different semantics of the kernels, share the NetBSD-only behavior beteen
the NetBSD native and gdbserver setup.
NetBSD does not differentiate the address space I and D in the
operations (contrary to OpenBSD). NetBSD handles EACCES that integrates
with NetBSD specific PaX MPROTECT error handling.
Add a verbose message in the native client that an operation could be
cancelled due to PaX MPROTECT setup.
gdb/ChangeLog:
* nat/netbsd-nat.c (write_memory, read_memory): Add.
* nat/netbsd-nat.h (write_memory, read_memory): Likewise.
* nbsd-nat.c (nbsd_nat_target::xfer_partial): Update.
gdbserver/ChangeLog:
* netbsd-low.cc (netbsd_process_target::read_memory)
(netbsd_process_target::write_memory): Update.
When a WOW64 process triggers a breakpoint exception in 64bit code (which
happens when a 64bit gdb calls DebugBreakProcess for a 32bit target),
gdb ignores the breakpoint (because Wow64GetThreadContext can only report
the pc of 32bit code, and there is not int3 at this location).
But if these 64bit breakpoint exceptions are handled as SIGINT, gdb
doesn't check for int3, and always stops the target.
gdb/ChangeLog:
2020-09-23 Hannes Domani <ssbssa@yahoo.de>
* nat/windows-nat.c (handle_exception): Handle 64bit breakpoints
in WOW64 processes as SIGINT.
* nat/windows-nat.h: Make wow64_process a shared variable.
* windows-nat.c: Remove static wow64_process variable.
gdbserver/ChangeLog:
2020-09-23 Hannes Domani <ssbssa@yahoo.de>
* win32-low.cc: Remove local wow64_process variable.
* win32-low.h: Remove local wow64_process variable.
Do not free the last execd pathname as it will be used in
prepare_resume_reply(), after attaching a client side.
gdb/ChangeLog:
* fork-inferior.c (startup_inferior): Avoid double free.
Add generic function to enable debugger events in a process.
gdb/ChangeLog:
* netbsd-nat.h (netbsd_nat::enable_proc_events): Add.
* netbsd-nat.c: Include <sys/ptrace.h>.
* (netbsd_nat::enable_proc_events): Add.
The kernel has fixed this here:
https://lore.kernel.org/patchwork/patch/1029011/
We should do the same for GDB, which is still carrying an incorrect
definition of the macro. As stated in the kernel patch thread, this doesn't
actually change things because, luckily, the structs are of the same size.
gdb/ChangeLog:
2020-08-10 Luis Machado <luis.machado@linaro.org>
* nat/aarch64-sve-linux-sigcontext.h (SVE_PT_REGS_OFFSET): Use
struct user_sve_header instead of struct sve_context.
