| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Teach gdb about a new debug architecture version for AArch64 (0x11).
No user-visible changes.
Regression-tested on aarch64-linux Ubuntu 20.04/22.04.
Signed-off-by: Luis Machado <luis.machado@arm.com>
|
|
The Arm Architecture Reference Manual defines debug version 0b1010 for
FEAT_Debugv8p8. This is used to identify valid hardware debug registers.
gdb currently only knows about versions up to FEAT_Debugv8p4. This patch
teaches gdb about this new version.
No visible changes should happen as consequence of this patch, but in the
future gdb will be able to identify debug registers in newer hardware.
Regression-tested on aarch64-linux Ubuntu 20.04/22.04.
|
|
The detection logic for TPIDR2 was implemented incorrectly. Originally
the detection was supposed to be through a ptrace error code, but in reality,
for backwards compatibility, the detection should be based on the size of
the returned iovec.
For instance, if a target supports both TPIDR and TPIDR2, ptrace will return a
iovec size of 16. If a target only supports TPIDR and not TPIDR2, it will
return a iovec size of 8, even if we asked for 16 bytes.
This patch fixes this issue in code that is shared between gdb and gdbserver,
therefore both gdb and gdbserver are fixed.
Tested on AArch64/Linux Ubuntu 20.04.
|
|
I've long wanted to remove 'struct buffer', and thanks to Simon's
earlier patch, I was finally able to do so. My feeling has been that
gdb already has several decent structures available for growing
strings: std::string of course, but also obstack and even objalloc
from BFD and dyn-string from libiberty. The previous patches in this
series removed all the uses of struct buffer, so this one can remove
the code and the remaining #includes.
|
|
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.
|
|
This allows to build GDB even though the default value of
_WIN32_WINNT is lower than the one needed to expose some
new APIs used here, and leave the test for their actual
support to run time.
* gdb/nat/windows-nat.c (EXTENDED_STARTUPINFO_PRESENT): Define if
not defined.
(create_process_wrapper): Use 'gdb_lpproc_thread_attribute_list'
instead of 'PPROC_THREAD_ATTRIBUTE_LIST' (which might not be defined
at compile time). This fixes compilation error using mingw.org's
MinGW.
|
|
Replace the use of struct buffer in linux-osdata.c with std::string.
There is no change in the logic, so there should be no user-visible
change.
Change-Id: I27f53165d401650bbd0bebe8ed88221e25545b3f
Approved-By: Pedro Alves <pedro@palves.net>
|
|
With the AArch64 Scalable Matrix Extension we have a new TPIDR2 register, and
it will be added to the existing NT_ARM_TLS register set. Kernel patches are
being reviewed here:
https://lore.kernel.org/linux-arm-kernel/20220818170111.351889-1-broonie@kernel.org/
From GDB's perspective, we handle it in a similar way to the existing TPIDR
register. But we need to consider cases of systems that only have TPIDR and
systems that have both TPIDR and TPIDR2.
With that in mind, the following patch adds the required code to support
TPIDR2 and turns the org.gnu.gdb.aarch64.tls feature into a
dynamically-generated target description as opposed to a static target
description containing only TPIDR.
That means we can remove the gdb/features/aarch64-tls.xml file and replace the
existing gdb/features/aarch64-tls.c auto-generated file with a new file that
dynamically generates the target description containing either TPIDR alone or
TPIDR and TPIDR2.
In the future, when *BSD's start to support this register, they can just
enable it as is being done for the AArch64 Linux target.
The core file read/write code has been updated to support TPIDR2 as well.
On GDBserver's side, there is a small change to the find_regno function to
expose a non-throwing version of it.
It always seemed strange to me how find_regno causes the whole operation to
abort if it doesn't find a particular register name. The patch moves code
from find_regno into find_regno_no_throw and makes find_regno call
find_regno_no_throw instead.
This allows us to do register name lookups to find a particular register
number without risking erroring out if nothing is found.
The patch also adjusts the feature detection code for aarch64-fbsd, since
the infrastructure is shared amongst all aarch64 targets. I haven't added
code to support TPIDR2 in aarch64-fbsd though, as I'm not sure when/if
that will happen.
|
|
I get this test failure on my CI;
FAIL: gdb.base/info-os.exp: get process list
The particularity of this setup is that builds are done in containers
who are allocated 4 CPUs on a machine that has 40. The code in
nat/linux-osdata.c fails to properly fetch the core number for each
task.
linux_xfer_osdata_processes uses `sysconf (_SC_NPROCESSORS_ONLN)`, which
returns 4, so it allocates an array of 4 integers. However, the core
numbers read from /proc/pid/task/tid/stat, by function
linux_common_core_of_thread, returns a value anywhere between 0 and 39.
The core numbers above 3 are therefore ignored, many processes end up
with no core value, and the regexp in the test doesn't match (it
requires an integer as the core field).
The way this the CPUs are exposed to the container is that the container
sees 40 CPUs "present" and "possible", but only 4 arbitrary CPUs
actually online:
root@ci-node-jammy-amd64-04-08:~# cat /sys/devices/system/cpu/present
0-39
root@ci-node-jammy-amd64-04-08:~# cat /sys/devices/system/cpu/online
5,11,24,31
root@ci-node-jammy-amd64-04-08:~# cat /sys/devices/system/cpu/possible
0-39
The solution proposed in this patch is to find out the number of
possible CPUs using /sys/devices/system/cpu/possible. In practice, this
will probably always contain `0-N`, where N is the number of CPUs, minus
one. But the documentation [1] doesn't such guarantee, so I'll assume
that it can contain a more complex range list such as `2,4-31,32-63`,
like the other files in that directory can have. The solution is to
iterate over these numbers to find the highest possible CPU id, and
use that that value plus one as the size of the array to allocate.
[1] https://www.kernel.org/doc/Documentation/admin-guide/cputopology.rst
Change-Id: I7abce2e43b000c1327fa94cd7b99d46e49d7ccf3
|
|
linux_common_core_of_thread
I would like to add more code to nat/linux-osdata.c that reads an entire
file from /proc or /sys and processes it as a string afterwards. I
would like to avoid duplicating the somewhat error-prone code that reads
an entire file to a buffer. I think we should have a utility function
that does that.
Add read_file_to_string to gdbsupport/filestuff.{c,h}, and make
linux_common_core_of_thread use it. I want to make the new function
return an std::string, and because strtok doesn't play well with
std::string (it requires a `char *`, std::string::c_str returns a `const
char *`), change linux_common_core_of_thread to use std::string methods
instead.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I1793fda72a82969c28b944a84acb953f74c9230a
|
|
Absent _UNICODE being defined (which gdb's Makefile doesn't do),
windows.h will always define STARTUPINFO is as STARTUPINFOA, so this
cast isn't correct when create_process expects a STARTUPINFOW
parameter (i.e. in a Cygwin build).
Instead write this as &info_ex.StartupInfo (which is always of the
correct type).
|
|
In gdb/nat/linux-btrace.c:btrace_this_cpu() we initialize the cpu
structure given to the libipt btrace decoder.
We only consider the extended model field for family 0x6 and forget about
family 0xf and we don't consider the extended family field. Fix it.
|
|
Currently, every internal_error call must be passed __FILE__/__LINE__
explicitly, like:
internal_error (__FILE__, __LINE__, "foo %d", var);
The need to pass in explicit __FILE__/__LINE__ is there probably
because the function predates widespread and portable variadic macros
availability. We can use variadic macros nowadays, and in fact, we
already use them in several places, including the related
gdb_assert_not_reached.
So this patch renames the internal_error function to something else,
and then reimplements internal_error as a variadic macro that expands
__FILE__/__LINE__ itself.
The result is that we now should call internal_error like so:
internal_error ("foo %d", var);
Likewise for internal_warning.
The patch adjusts all calls sites. 99% of the adjustments were done
with a perl/sed script.
The non-mechanical changes are in gdbsupport/errors.h,
gdbsupport/gdb_assert.h, and gdb/gdbarch.py.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Ia6f372c11550ca876829e8fd85048f4502bdcf06
|
|
When working on windows-nat.c, it's useful to see an error message in
addition to the error number given by GetLastError. This patch moves
strwinerror from gdbserver to gdbsupport, and then updates
windows-nat.c to use it. A couple of minor changes to strwinerror
(constify the return type and use the ARRAY_SIZE macro) are also
included.
|
|
On a machine with gcc 12, I get this warning:
CXX nat/linux-btrace.o
In function ‘btrace_error linux_read_bts(btrace_data_bts*, btrace_target_info*, btrace_read_type)’,
inlined from ‘btrace_error linux_read_btrace(btrace_data*, btrace_target_info*, btrace_read_type)’ at ../gdb/nat/linux-btrace.c:935:29:
../gdb/nat/linux-btrace.c:865:21: warning: ‘data_head’ may be used uninitialized [-Wmaybe-uninitialized]
865 | pevent->last_head = data_head;
| ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
../gdb/nat/linux-btrace.c: In function ‘btrace_error linux_read_btrace(btrace_data*, btrace_target_info*, btrace_read_type)’:
../gdb/nat/linux-btrace.c:792:9: note: ‘data_head’ was declared here
792 | __u64 data_head, data_tail;
| ^~~~~~~~~
Fix this by initializing the 'data_head' variable.
Tested by rebuilding on x86_64 openSUSE Tumbleweed with gcc 12.
|
|
* Remove a stray semicolon
* Restore dropped nullptr program argument in use of create_process() under CYGWIN
|
|
Prior to c6ca3dab dropping support for Cygwin 1.5, cygwin_buf_t was
defined as char for Cygwin 1.5. After that, it's always wchar_t, so
just use that.
|
|
This changes windows_process_info to use virtual methods for its
callbacks, and then changes the two clients of this code to subclass
this class to implement the methods.
I considered using CRTP here, but that would require making the new
structures visible to the compilation of of nat/windows-nat.c. This
seemed like a bit of a pain, so I didn't do it.
This change then lets us change all the per-inferior globals to be
members of the new subclass. Note that there can still only be a
single inferior -- currently there's a single global of the new type.
This is just another step toward possibly implementing multi-inferior
for Windows.
It's possible this could be cleaned up further... ideally I'd like to
move more of the data into the base class. However, because gdb
supports Cygwin and gdbserver does not, and because I don't have a way
to build or test Cygwin, larger refactorings are difficult.
|
|
On Windows, it is possible to disable ASLR when creating a process.
This patch adds code to do this, and hooks it up to gdb's existing
disable-randomization feature. Because the Windows documentation
cautions that this isn't available on all versions of Windows, the
CreateProcess wrapper function is updated to make the attempt, and
then fall back to the current approach if it fails.
|
|
This is a small refactoring that introduces a wrapper for the Windows
CreateProcess function. This is done to make the next patch a bit
simpler.
|
|
Fix Cygwin build after 0578e87f ("Remove some globals from
nat/windows-nat.c"). Update code under ifdef __CYGWIN__ for globals
moved to members of struct windows_process_info.
|
|
Fix Cygwin build after fcab5839 ("Implement pid_to_exec_file for Windows
in gdbserver"). That change moves code from gdb/windows-nat.c to
gdb/nat/windows-nat.c, but doesn't add the required typedefs and
includes for parts of that code under ifdef __CYGWIN__.
|
|
I noticed that gdbserver did not implement pid_to_exec_file for
Windows, while gdb did implement it. This patch moves the code to
nat/windows-nat.c, so that it can be shared. This makes the gdbserver
implementation trivial.
|
|
I noticed that windows_process_info::id is only used by gdbserver, and
not really necessary. This patch removes it.
|
|
This changes target_pid_to_exec_file and target_ops::pid_to_exec_file
to return a "const char *". I couldn't build many of these targets,
but did examine the code by hand -- also, as this only affects the
return type, it's normally pretty safe. This brings gdb and gdbserver
a bit closer, and allows for the removal of a const_cast as well.
|
|
I noticed a few spots in GDB that use "typedef enum". However, in C++
this isn't as useful, as the tag is automatically entered as a
typedef. This patch removes most uses of "typedef enum" -- the
exceptions being in some nat-* code I can't compile, and
glibc_thread_db.h, which I think is more or less a copy of some C code
from elsewhere.
Tested by rebuilding.
|
|
Internally at AdaCore, we noticed that the new Windows thread name
code could fail. First, it might return a zero-length string, but in
gdb conventions it should return nullptr instead. Second, an encoding
failure could wind up showing replacement characters to the user; this
is confusing and not useful; it's better to recognize such errors and
simply discard the name. This patch makes both of these changes.
|
|
Windows 10 introduced SetThreadDescription and GetThreadDescription, a
simpler way to set a thread's name. This changes gdb and gdbserver to
use this convention when it is available.
This is part of PR win32/29050.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29050
|
|
Currently, gdb's native Windows target implements the exception-based
approach for setting thread names, but gdbserver does not. This patch
moves handle_ms_vc_exception to the shared nat/windows-nat.c code, as
preparation for adding this support to gdbserver.
|
|
I noticed that nat/windows-nat.c checks __USEWIDE, but nothing sets it
there -- I forgot to copy over the definition when making this file.
This patch tries to fix the problem. I don't have a Cygwin setup, so
I don't know whether this is sufficient, but it's probably necessary.
|
|
Internally at AdaCore, we recently started testing a 64-bit gdb
debugging 32-bit processes. This failed with gdb head, but not with
gdb 11.
The tests fail like this:
Starting program: [...].exe
warning: Could not load shared library symbols for WOW64_IMAGE_SECTION.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for WOW64_IMAGE_SECTION.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need "set solib-search-path" or "set sysroot"?
After some debugging and bisecting, to my surprise the bug was
introduced by commit 183be222 ("gdb, gdbserver: make target_waitstatus
safe").
The problem occurs in handle_exception. Previously the code did:
- ourstatus->kind = TARGET_WAITKIND_STOPPED;
[...]
case EXCEPTION_BREAKPOINT:
[...]
- ourstatus->kind = TARGET_WAITKIND_SPURIOUS;
[...]
/* FALLTHROUGH */
case STATUS_WX86_BREAKPOINT:
DEBUG_EXCEPTION_SIMPLE ("EXCEPTION_BREAKPOINT");
- ourstatus->value.sig = GDB_SIGNAL_TRAP;
[...]
- last_sig = ourstatus->value.sig;
However, in the new code, the fallthrough case does:
+ ourstatus->set_stopped (GDB_SIGNAL_TRAP);
... which changes the 'kind' in 'ourstatus' after falling through.
This patch rearranges the 'last_sig' setting to more closely match
what was done before (this is probably not strictly needed but also
seemed harmless), and removes the fall-through in the
'ignore_first_breakpoint' case when __x86_64__ is defined.
|
|
nat/windows-nat.c has a number of globals that it uses to communicate
with its clients (gdb and gdbserver). However, if we ever want the
Windows ports to be multi-inferior, globals won't work.
This patch takes a step toward that by moving most nat/windows-nat.c
globals into a new struct windows_process_info. Many functions are
converted to be methods on this object.
A couple of globals remain, as they are needed to truly be global due
to the way that the Windows debugging APIs work.
The clients still have a global for the current process. That is,
this patch is a step toward the end goal, but doesn't implement the
goal itself.
|
|
windows_thread_info declares and defines a destructor, but this
doesn't need to be explicit.
|
|
Move non-Linux-specific support for hardware break/watchpoints from
nat/aarch64-linux-hw-point.c to nat/aarch64-hw-point.c. Changes
beyond a simple split of the code are:
- aarch64_linux_region_ok_for_watchpoint and
aarch64_linux_any_set_debug_regs_state renamed to drop linux_ as
they are not platform specific.
- Platforms must implement the aarch64_notify_debug_reg_change
function which is invoked from the platform-independent code when a
debug register changes for a given debug register state. This does
not use the indirection of a 'low' structure as is done for x86.
- The handling for kernel_supports_any_contiguous_range is not
pristine. For non-Linux it is simply defined to true. Some uses of
this could perhaps be implemented as new 'low' routines for the
various places that check it instead?
- Pass down ptid into aarch64_handle_breakpoint and
aarch64_handle_watchpoint rather than using current_lwp_ptid which
is only defined on Linux. In addition, pass the ptid on to
aarch64_notify_debug_reg_change instead of the unused state
argument.
|
|
clone, sysgood
I think it's safe to remove checking support for these ptrace features,
they have all been added in what is now ancient times (around the
beginning of Linux 2.6). This allows removing a bit of complexity in
linux-nat.c and nat/linux-ptrace.c.
It also allows saving one extra fork every time we start debugging on
Linux: linux_check_ptrace_features forks a child process to test if some
ptrace features are supported. That child process forks a grand-child,
to test whether ptrace reports an event for the fork by the child. This
is no longer needed, if we assume the kernel supports reporting forks.
PTRACE_O_TRACEVFORKDONE was introduced in Linux in this change, in 2003:
https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=45c1a159b85b3b30afd26a77b4be312226bba416
PTRACE_O_TRACESYSGOOD was supported at least as of this change, in 2002:
https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=acc7088569c8eef04eeed0eff51d23bb5bcff964
PTRACE_O_TRACEFORK, PTRACE_O_TRACEVFORK, PTRACE_O_TRACEEXEC and
PTRACE_O_TRACECLONE were introduced in this change, in 2002:
https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=a0691b116f6a4473f0fa264210ab9b95771a2b46
Change-Id: Iffb906549a89cc6b619427f976ec044706ab1e8d
|
|
When trying to use 'record btrace' on a system that does not support it,
the error message isn't as clear as it could be. See
https://sourceware.org/pipermail/gdb/2022-January/049870.html.
Improve the error message in a few cases.
Reported-by: Simon Sobisch <simonsobisch@gnu.org>
|
|
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.
|
|
Fix mispelling of PROT_ME to PROT_MTE in the error messages.
|
|
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 d3d7d1ba3bb "[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
|
|
Just like my previoius patch for ARMv8.1 and v8.2 (49ecef2a7da2ee9df4),
this adds ARMv8.4 debug arch as being compatible for hw watchpoint
and breakpoints.
|
|
(aarch64_linux_get_debug_reg_capacity)
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.
|
