#
e24a6552 |
| 29-Jul-2024 |
Mark Johnston <markj@FreeBSD.org> |
thread: Remove kernel stack swapping support, part 4
- Remove the IS_SWAPPED thread inhibitor state. - Remove all uses of TD_IS_SWAPPED() in the kernel. - Remove the TDF_CANSWAP flag. - Remove the P
thread: Remove kernel stack swapping support, part 4
- Remove the IS_SWAPPED thread inhibitor state. - Remove all uses of TD_IS_SWAPPED() in the kernel. - Remove the TDF_CANSWAP flag. - Remove the P_SWAPPINGOUT and P_SWAPPINGIN flags.
Tested by: pho Reviewed by: alc, imp, kib Differential Revision: https://reviews.freebsd.org/D46115
show more ...
|
Revision tags: release/14.1.0 |
|
#
0adc959a |
| 14-Mar-2024 |
Andrew Turner <andrew@FreeBSD.org> |
sys/gdb: Support hardware breakpoints
Support the use of hardware breakpoints in the kernel gdb stub.
Reviewed by: jhb (earlier version) Sponsored by: Arm Ltd Differential Revision: https://reviews
sys/gdb: Support hardware breakpoints
Support the use of hardware breakpoints in the kernel gdb stub.
Reviewed by: jhb (earlier version) Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D44354
show more ...
|
Revision tags: release/13.3.0 |
|
#
fdafd315 |
| 24-Nov-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Automated cleanup of cdefs and other formatting
Apply the following automated changes to try to eliminate no-longer-needed sys/cdefs.h includes as well as now-empty blank lines in a row.
Remov
sys: Automated cleanup of cdefs and other formatting
Apply the following automated changes to try to eliminate no-longer-needed sys/cdefs.h includes as well as now-empty blank lines in a row.
Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/ Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/ Remove /\n+#if.*\n#endif.*\n+/ Remove /^#if.*\n#endif.*\n/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/
Sponsored by: Netflix
show more ...
|
Revision tags: release/14.0.0 |
|
#
685dc743 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c pattern
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
#
4d846d26 |
| 10-May-2023 |
Warner Losh <imp@FreeBSD.org> |
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg MFC After: 3 days Sponsored by: Netflix
show more ...
|
Revision tags: release/13.2.0, release/12.4.0, release/13.1.0, release/12.3.0, release/13.0.0 |
|
#
7446b088 |
| 08-Mar-2021 |
Mitchell Horne <mhorne@FreeBSD.org> |
gdb: report specific stop reason for watchpoints
The remote protocol allows for implementations to report more specific reasons for the break in execution back to the client [1]. This is entirely op
gdb: report specific stop reason for watchpoints
The remote protocol allows for implementations to report more specific reasons for the break in execution back to the client [1]. This is entirely optional, so it is only implemented for amd64, arm64, and i386 at the moment.
[1] https://sourceware.org/gdb/current/onlinedocs/gdb/Stop-Reply-Packets.html
Reviewed by: jhb MFC after: 3 weeks Sponsored by: NetApp, Inc. Sponsored by: Klara, Inc. NetApp PR: 51 Differential Revision: https://reviews.freebsd.org/D29174
show more ...
|
#
4beb3858 |
| 08-Mar-2021 |
Mitchell Horne <mhorne@FreeBSD.org> |
gdb: allow setting/removing hardware watchpoints
Handle the 'z' and 'Z' remote packets for manipulating hardware watchpoints.
This could be expanded quite easily to support hardware or software bre
gdb: allow setting/removing hardware watchpoints
Handle the 'z' and 'Z' remote packets for manipulating hardware watchpoints.
This could be expanded quite easily to support hardware or software breakpoints as well.
https://sourceware.org/gdb/onlinedocs/gdb/Packets.html
Reviewed by: cem, markj MFC after: 3 weeks Sponsored by: NetApp, Inc. Sponsored by: Klara, Inc. NetApp PR: 51 Differential Revision: https://reviews.freebsd.org/D29173
show more ...
|
#
fa2528ac |
| 18-Feb-2021 |
Alex Richardson <arichardson@FreeBSD.org> |
Use atomic loads/stores when updating td->td_state
KCSAN complains about racy accesses in the locking code. Those races are fine since they are inside a TD_SET_RUNNING() loop that expects the value
Use atomic loads/stores when updating td->td_state
KCSAN complains about racy accesses in the locking code. Those races are fine since they are inside a TD_SET_RUNNING() loop that expects the value to be changed by another CPU.
Use relaxed atomic stores/loads to indicate that this variable can be written/read by multiple CPUs at the same time. This will also prevent the compiler from doing unexpected re-ordering.
Reported by: GENERIC-KCSAN Test Plan: KCSAN no longer complains, kernel still runs fine. Reviewed By: markj, mjg (earlier version) Differential Revision: https://reviews.freebsd.org/D28569
show more ...
|
#
3f3cc995 |
| 23-Dec-2020 |
Mitchell Horne <mhorne@FreeBSD.org> |
gdb(4): allow bulk write of registers
Add support for the remote 'G' packet. This is not widely used by gdb when 'P' is supported, but is technically required by any remote gdb stub implementation [
gdb(4): allow bulk write of registers
Add support for the remote 'G' packet. This is not widely used by gdb when 'P' is supported, but is technically required by any remote gdb stub implementation [1].
[1] https://sourceware.org/gdb/current/onlinedocs/gdb/Overview.html
Reviewed by: cem MFC after: 1 week Sponsored by: NetApp, Inc. Sponsored by: Klara, Inc. NetApp PR: 44 Differential Revision: https://reviews.freebsd.org/D27644
show more ...
|
#
fd29833d |
| 23-Dec-2020 |
Mitchell Horne <mhorne@FreeBSD.org> |
gdb(4): handle single register read packets
We support bulk reads of the register set, but not reading specific registers via the 'p' packet. This is useful at least for the 'call' command in gdb.
gdb(4): handle single register read packets
We support bulk reads of the register set, but not reading specific registers via the 'p' packet. This is useful at least for the 'call' command in gdb.
Reviewed by: cem MFC after: 1 week Sponsored by: NetApp, Inc. Sponsored by: Klara, Inc. NetApp PR: 44 Differential Revision: https://reviews.freebsd.org/D27644
show more ...
|
Revision tags: release/12.2.0 |
|
#
a91812f6 |
| 30-Sep-2020 |
Conrad Meyer <cem@FreeBSD.org> |
gdb(4): Don't escape GDB special characters at application layer
In r351368, we introduced this XML- and GDB-encoded data. The protocol 'offset' should reflex the logical XML data offset, but unfor
gdb(4): Don't escape GDB special characters at application layer
In r351368, we introduced this XML- and GDB-encoded data. The protocol 'offset' should reflex the logical XML data offset, but unfortunately we counted the GDB escapes as well.
In fact, we cannot safely do GDB character escaping at this layer at all, because we don't know what will be flushed in a packet. It is bogus to send only the first character of a two-character escape sequence.
This patch "corrects" the problem by squashing these characters in the transmitted XML document. It would be nice to transmit the characters faithfully, but that is a more complicated change. Thread names are a nice convenience feature for the GDB client, but one can always inspect td_name or p_comm directly to find the true name.
Reported by: Ka Ho Ng <khng300 AT gmail.com> Tested by: Ka Ho Ng Reviewed by: emaste, markj, rlibby Differential Revision: https://reviews.freebsd.org/D26599
show more ...
|
#
e2515283 |
| 27-Aug-2020 |
Glen Barber <gjb@FreeBSD.org> |
MFH
Sponsored by: Rubicon Communications, LLC (netgate.com)
|
#
5af88677 |
| 18-Aug-2020 |
Conrad Meyer <cem@FreeBSD.org> |
gdb(4): Support empty qSupported queries
Technically a client may send a qSupported query without specifying any client features. We should respond with our supported list in that case instead of b
gdb(4): Support empty qSupported queries
Technically a client may send a qSupported query without specifying any client features. We should respond with our supported list in that case instead of bailing with error.
Reported by: rlibby Reviewed by: emaste, rlibby, vangyzen Sponsored by: Isilon Differential Revision: https://reviews.freebsd.org/D26115
show more ...
|
Revision tags: release/11.4.0 |
|
#
75dfc66c |
| 27-Feb-2020 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r358269 through r358399.
|
#
7029da5c |
| 26-Feb-2020 |
Pawel Biernacki <kaktus@FreeBSD.org> |
Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (17 of many)
r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are still not MPSAFE (or already are but aren’t properly mark
Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (17 of many)
r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are still not MPSAFE (or already are but aren’t properly marked). Use it in preparation for a general review of all nodes.
This is non-functional change that adds annotations to SYSCTL_NODE and SYSCTL_PROC nodes using one of the soon-to-be-required flags.
Mark all obvious cases as MPSAFE. All entries that haven't been marked as MPSAFE before are by default marked as NEEDGIANT
Approved by: kib (mentor, blanket) Commented by: kib, gallatin, melifaro Differential Revision: https://reviews.freebsd.org/D23718
show more ...
|
#
fa76c6f9 |
| 16-Dec-2019 |
Leandro Lupori <luporl@FreeBSD.org> |
[PPC] Handle qOffsets packet
On PowerPC, this is needed in order for the debugger to find out the memory offset where the kernel image was loaded on the remote target.
This fixes symbol resolution
[PPC] Handle qOffsets packet
On PowerPC, this is needed in order for the debugger to find out the memory offset where the kernel image was loaded on the remote target.
This fixes symbol resolution when remote debugging a PowerPC kernel.
Reviewed by: cem Differential Revision: https://reviews.freebsd.org/D22767
show more ...
|
Revision tags: release/12.1.0 |
|
#
6310546d |
| 18-Oct-2019 |
Conrad Meyer <cem@FreeBSD.org> |
gdb(4): Implement support for NoAckMode
When the underlying debugport transport is reliable, GDB's additional checksums and acknowledgements are redundant. NoAckMode eliminates the the acks and all
gdb(4): Implement support for NoAckMode
When the underlying debugport transport is reliable, GDB's additional checksums and acknowledgements are redundant. NoAckMode eliminates the the acks and allows us to skip checking RX checksums. The GDB packet framing does not change, so unfortunately (valid) checksums are still included as message trailers.
The gdb(4) stub in FreeBSD advertises support for the feature in response to the client's 'qSupported' request IFF the current debugport has the gdb_dbfeatures flag GDB_DBGP_FEAT_RELIABLE set. Currently, only netgdb(4) supports this feature.
If the remote GDB client supports the feature and does not have it disabled via a GDB configuration knob, it may instruct our gdb(4) stub to enter NoAckMode. Unless and until it issues that command, we must continue to transmit acks as usual (and for now, we continue to wait until we receive them as well, even if we know the debugport is on a reliable transport).
In the kernel sources, the sense of the flag representing the state of the feature is reversed from that of the GDB command. (I.e., it is 'gdb_ackmode', not 'gdb_noackmode.') This is to avoid confusing double- negative conditions.
For reference, see: * https://sourceware.org/gdb/onlinedocs/gdb/Packet-Acknowledgment.html * https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#QStartNoAckMode
Reviewed by: jhb, markj (both earlier version) Differential Revision: https://reviews.freebsd.org/D21761
show more ...
|
#
dda17b36 |
| 17-Oct-2019 |
Conrad Meyer <cem@FreeBSD.org> |
Implement NetGDB(4)
NetGDB(4) is a component of a system using a panic-time network stack to remotely debug crashed FreeBSD kernels over the network, instead of traditional serial interfaces.
There
Implement NetGDB(4)
NetGDB(4) is a component of a system using a panic-time network stack to remotely debug crashed FreeBSD kernels over the network, instead of traditional serial interfaces.
There are three pieces in the complete NetGDB system.
First, a dedicated proxy server must be running to accept connections from both NetGDB and gdb(1), and pass bidirectional traffic between the two protocols.
Second, the NetGDB client is activated much like ordinary 'gdb' and similarly to 'netdump' in ddb(4) after a panic. Like other debugnet(4) clients (netdump(4)), the network interface on the route to the proxy server must be online and support debugnet(4).
Finally, the remote (k)gdb(1) uses 'target remote <proxy>:<port>' (like any other TCP remote) to connect to the proxy server.
The NetGDB v1 protocol speaks the literal GDB remote serial protocol, and uses a 1:1 relationship between GDB packets and sequences of debugnet packets (fragmented by MTU). There is no encryption utilized to keep debugging sessions private, so this is only appropriate for local segments or trusted networks.
Submitted by: John Reimer <john.reimer AT emc.com> (earlier version) Discussed some with: emaste, markj Relnotes: sure Differential Revision: https://reviews.freebsd.org/D21568
show more ...
|
#
f993ed2f |
| 09-Sep-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r351732 through r352104.
|
#
10f6c05c |
| 09-Sep-2019 |
Conrad Meyer <cem@FreeBSD.org> |
gdb(4): Root a sysctl tree at 'debug.gdb.'
Like debug.ddb and debug.kdb. Rename 'debug.gdbcons' to 'debug.gdb.cons,' but leave the old name as a compatibility alias.
|
#
c5c3ba6b |
| 03-Sep-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r351317 through r351731.
|
#
acef7371 |
| 22-Aug-2019 |
Conrad Meyer <cem@FreeBSD.org> |
Fix i386 build after r351368
Reported by: cy Submitted by: cy
|
#
5df6fa43 |
| 22-Aug-2019 |
Conrad Meyer <cem@FreeBSD.org> |
gdb(4): Style
No functional change.
I was surprised to find that no sys/ header already defines the -1 EOF convention anywhere, so defined one locally.
|
#
5555afa1 |
| 22-Aug-2019 |
Conrad Meyer <cem@FreeBSD.org> |
gdb(4): Implement qXfer:threads:read
This streams out an XML document over several GDB packets describing all threads in the system; their ids, name, and any loosely defined "extra info" we feel lik
gdb(4): Implement qXfer:threads:read
This streams out an XML document over several GDB packets describing all threads in the system; their ids, name, and any loosely defined "extra info" we feel like including. For now, I have included a string version of the run state, similar to some of the DDB logic to stringify thread state.
The benefit of supporting this in addition to the qfThreadInfo/qsThreadInfo packing is that in this mode, the host gdb does not ask for every thread's "qThreadExtraInfo," saving per-thread round-trips on "info threads."
To use this feature, (k)gdb needs to be built with the --with-expat option. I would encourage enabling this option by default in our GDB port, if it is not already.
Finally, there is another optional attribute you can specify per-thread called a "handle." Handles are arbitrarily long sequences of bytes, represented in the XML as hexadecimal. It is unclear to me how or if GDB actually uses handles for anything. So I have left them out.
show more ...
|
#
c4fbbfaa |
| 22-Aug-2019 |
Conrad Meyer <cem@FreeBSD.org> |
gdb(4): Add basic 'qSupported' support
This is where the host GDB tells us what features it supports, and we respond with the list we support. For now, just report PacketSize.
|