| Main index | Section 4 | Options |
A
netgdb
session is started by using the
netgdb
At this point, the server proxies traffic back and forth between netgdb and the ordinary GDB client, speaking the ordinary GDB remote protocol. The netgdb session is identical to any other kernel GDB sesssion from the perspective of the GDB debugger.
Unlike netdump(4), the initial HERALD port is 20025. Additionally, the proxy server sends responses to the source port of the client's initial HERALD, rather than a separate reserved port. netgdb message and acknowledgements are bidirectional. The sequence number and acknowledgement protocol is otherwise identical to the unidirectional version used by netdump; it just runs in both directions. Acknowledgements are sent to and from the same addresses and ports as regular messages.
The first version of the netgdb protocol uses the protocol number '0x2515f095' in the 32-bit aux2 parameter of the initial HERALD message.
The list of supported network drivers and protocol families is identical to that of netdump(4).
| debug.gdb.netgdb.debug | |
| Control debug message verbosity. Debug messages are disabled by default. They may be enabled by setting the variable to a non-zero value. | |
| NETGDB (4) | November 10, 2022 |
| Main index | Section 4 | Options |
Please direct any comments about this manual page service to Ben Bullock. Privacy policy.
| “ | This philosophy, in the hands of amateurs, leads to inexplicably mind-numbing botches like the existence of two programs, “head” and “tail,” which print the first part or the last part of a file, depending. Even though their operations are duals of one another, “head” and “tail” are different programs, written by different authors, and take different options! | ” |
| — The Unix Haters' handbook | ||