Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 Oct 2019 15:20:11 -0700
From:      Cy Schubert <Cy.Schubert@cschubert.com>
To:        "Hartmann, O." <ohartmann@walstatt.org>
Cc:        svn-src-head@freebsd.org, Gary Jennejohn <gljennjohn@gmail.com>, src-committers@freebsd.org, svn-src-all@freebsd.org, Conrad Meyer <cem@FreeBSD.org>
Subject:   Re: svn commit: r353700 - in head: share/man/man4 sys/amd64/conf  sys/conf sys/gdb sys/i386/conf sys/kern sys/net sys/sys
Message-ID:  <201910182220.x9IMKBVn032870@slippy.cwsent.com>
In-Reply-To: <201910182216.x9IMG7wO032486@slippy.cwsent.com>
References:  <201910172133.x9HLX1kl071044@repo.freebsd.org>  <20191018122104.389ffb7a@hermann.fritz.box> <20191018140045.31d269b0@ernst.home> <20191018160935.7dda61c4@hermann.fritz.box> <201910181424.x9IEOC9q013885@slippy.cwsent.com> <20191018175406.0ff89bbc@hermann.fritz.box> <ACCC37A4-4E6A-4B08-85C6-D37D658A88B4@cschubert.com> <20191018183718.5e6b3d62@hermann.fritz.box> <201910182216.x9IMG7wO032486@slippy.cwsent.com>

next in thread | previous in thread | raw e-mail | index | archive | help
In message <201910182216.x9IMG7wO032486@slippy.cwsent.com>, Cy Schubert 
writes:
> In message <20191018183718.5e6b3d62@hermann.fritz.box>, "Hartmann, O." 
> writes:
> > --Sig_/icZw9PmU7w9Aj=UqDZhZj.c
> > Content-Type: text/plain; charset=US-ASCII
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Fri, 18 Oct 2019 09:26:51 -0700
> > Cy Schubert <Cy.Schubert@cschubert.com> wrote:
> >
> > > On October 18, 2019 8:54:06 AM PDT, "Hartmann, O."
> > > <ohartmann@walstatt.org> wrote:
> > > >On Fri, 18 Oct 2019 07:24:12 -0700
> > > >Cy Schubert <Cy.Schubert@cschubert.com> wrote:
> > > > =20
> > > >> In message <20191018160935.7dda61c4@hermann.fritz.box>, "Hartmann,
> > > >> O." writes: =20
> > > >> > --Sig_/QDD9BZgeMM6.TJkOIciNb32
> > > >> > Content-Type: text/plain; charset=3DUS-ASCII
> > > >> > Content-Transfer-Encoding: quoted-printable
> > > >> >
> > > >> > On Fri, 18 Oct 2019 14:00:45 +0200
> > > >> > Gary Jennejohn <gljennjohn@gmail.com> wrote:
> > > >> >   =20
> > > >> > > On Fri, 18 Oct 2019 12:21:04 +0200
> > > >> > > "Hartmann, O." <ohartmann@walstatt.org> wrote:
> > > >> > >=3D20   =20
> > > >> > > > On Thu, 17 Oct 2019 21:33:01 +0000 (UTC)
> > > >> > > > Conrad Meyer <cem@FreeBSD.org> wrote:
> > > >> > > >  =3D20   =20
> > > >> > > > > Author: cem
> > > >> > > > > Date: Thu Oct 17 21:33:01 2019
> > > >> > > > > New Revision: 353700
> > > >> > > > > URL: https://svnweb.freebsd.org/changeset/base/353700
> > > >> > > > >=3D20
> > > >> > > > > Log:
> > > >> > > > >   Implement NetGDB(4)
> > > >> > > > >  =3D20
> > > >> > > > >   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.
> > > >> > > > >  =3D20
> > > >> > > > >   There are three pieces in the complete NetGDB system.
> > > >> > > > >  =3D20
> > > >> > > > >   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.
> > > >> > > > >  =3D20
> > > >> > > > >   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). =3D20
> > > >> > > > >   Finally, the remote (k)gdb(1) uses 'target remote
> > > >> > > > > <proxy>:<port>' (like any other TCP remote) to connect to
> > > >> > > > > the proxy server.=3D20
> > > >> > > > >   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. =3D20
> > > >> > > > >   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
> > > >> > > > >=3D20
> > > >> > > > > Added:
> > > >> > > > >   head/share/man/man4/netgdb.4   (contents, props changed)
> > > >> > > > >   head/sys/gdb/netgdb.c   (contents, props changed)
> > > >> > > > >   head/sys/gdb/netgdb.h   (contents, props changed)
> > > >> > > > > Modified:
> > > >> > > > >   head/share/man/man4/Makefile
> > > >> > > > >   head/share/man/man4/ddb.4
> > > >> > > > >   head/sys/amd64/conf/GENERIC
> > > >> > > > >   head/sys/conf/NOTES
> > > >> > > > >   head/sys/conf/files
> > > >> > > > >   head/sys/conf/options
> > > >> > > > >   head/sys/gdb/gdb.h
> > > >> > > > >   head/sys/gdb/gdb_int.h
> > > >> > > > >   head/sys/gdb/gdb_main.c
> > > >> > > > >   head/sys/gdb/gdb_packet.c
> > > >> > > > >   head/sys/i386/conf/GENERIC
> > > >> > > > >   head/sys/kern/subr_kdb.c
> > > >> > > > >   head/sys/net/debugnet.c
> > > >> > > > >   head/sys/net/debugnet.h
> > > >> > > > >   head/sys/net/debugnet_inet.c
> > > >> > > > >   head/sys/net/debugnet_int.h
> > > >> > > > >   head/sys/sys/kdb.h
> > > >> > > > >   head/sys/sys/param.h
> > > >> > > > >=3D20
> > > >> > > > > Modified: head/share/man/man4/Makefile
> > > >> > > > > =20
> > > >=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=
> > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D
> > > >=20
> > > >> > > > >   =20
> > > >> > =20
> > > >=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=
> > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D
> > > >=20
> > > >> > =20
> > > >=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=
> > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D
> > > >=20
> > > >> > =3D3D=3D3D=3D3D=3D3D=3D3D   =20
> > > >> > > > > --- head/share/man/man4/Makefile	Thu Oct 17 21:25:50
> > > >> > > > > 2019	(r353699) +++ head/share/man/man4/Makefile
> > > >> > > > > Thu Oct 17 21:33:01 2019	(r353700) @@ -307,6 +307,7
> > > >> > > > > @@ MAN=3D3D aac.4 \ net80211.4 \
> > > >> > > > >  	netdump.4 \
> > > >> > > > >  	netfpga10g_nf10bmac.4 \
> > > >> > > > > +	netgdb.4 \
> > > >> > > > >  	netgraph.4 \
> > > >> > > > >  	netintro.4 \
> > > >> > > > >  	netmap.4 \
> > > >> > > > >    =3D20   =20
> > > >> > > > [...]
> > > >> > > >=3D20
> > > >> > > >=3D20
> > > >> > > > Having "nooptions       NETGDB          # netgdb(4) client
> > > >> > > > support" defined in my kernel config file, buildkernel fails
> > > >> > > > with the error shown below.
> > > >> > > >=3D20
> > > >> > > > [...]
> > > >> > > > --- debugnet.o ---
> > > >> > > > /usr/src/sys/net/debugnet.c:662:4: error: implicit
> > > >> > > > declaration of function 'db_printf' is invalid in C99
> > > >> > > > [-Werror,-Wimplicit-function-declaration] db_printf("%s:
> > > >> > > > Could not get route for that server.\n", ^
> > > >> > > > /usr/src/sys/net/debugnet.c:662:4: note: did you mean
> > > >> > > > 'if_printf'? /usr/src/sys/net/if_var.h:679:5: note:
> > > >> > > > 'if_printf' declared here int     if_printf(struct ifnet *,
> > > >> > > > const char *, ...) __printflike(2, 3); ^ 1 error generated.
> > > >> > > > =3D20   =20
> > > >> > >=3D20
> > > >> > > And I also had to add "nooptions NETDUMP" to get the kernel to
> > > >> > > compile and link.
> > > >> > >=3D20   =20
> > > >> >
> > > >> > I already had "nooptions NETDUMP" defined.   =20
> > > >>=20
> > > >>=20
> > > >> This will fix it.
> > > >>=20
> > > >> Index: sys/net/debugnet.c
> > > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > >> --- sys/net/debugnet.c	(revision 353717)
> > > >> +++ sys/net/debugnet.c	(working copy)
> > > >> @@ -659,8 +659,10 @@
> > > >>  		CURVNET_RESTORE();
> > > >> =20
> > > >>  		if (dest_rt =3D=3D NULL) {
> > > >> +#ifdef DDB
> > > >>  			db_printf("%s: Could not get route for
> > > >> that server.\n", __func__);
> > > >> +#endif
> > > >>  			error =3D ENOENT;
> > > >>  			goto cleanup;
> > > >>  		}
> > > >>=20
> > > >>=20
> > > >>  =20
> > > >
> > > >Doesn't work, either.
> > > >The kernel config in question doesn't have any debugging features
> > > >enabled, so nooptions DDB is alos part of the configuration.
> > > >buildkernel still fails. =20
> > >=20
> > > Hmm. Fixed my firewall build. My non-test firewall kernel config has
> > > the same nooption.
> > >=20
> > > What other options/nooptions and patches are applied to your tree?
> > >=20
> > >=20
> >
> > I use the vanilla CURRENT tree without any extra pachtes. There are
> > lots of other nooptions, especially for drivers I do not need and
> > debugging is completely turned off.
> >
> > Having "nooptions DDB" commeted out fixes the build for me.
> > Anticipating the correct portion of my config file, here are those
> > nooptions I deem relevant. The nooptions are kept in a file added to
> > GENERIC afterwards:
> >
> > [... sorry for the line wrap]
> > nooptions       DDB_CTF                 # Kernel ELF linker loads CTF
> > data nooptions       INCLUDE_CONFIG_FILE     # Include this file in
> > kernel #options        RACCT                   # Resource accounting
> > framework #options        RACCT_DEFAULT_TO_DISABLED # Set
> > kern.racct.enable=3D0 by default #options        RCTL
> > # Resource limits
> >
> > # Debugging support.  Always need this:
> > #options        KDB                     # Enable kernel debugger
> > support. #options        KDB_TRACE               # Print a stack trace
> > for a panic. # For full debugger support use (turn off in stable
> > branch): nooptions       BUF_TRACKING            # Track buffer history
> > nooptions       DDB                     # Support DDB.
> > nooptions       FULL_BUF_TRACKING       # Track more buffer history
> > nooptions       GDB                     # Support remote GDB.
> > nooptions       DEADLKRES               # Enable the deadlock resolver
> > nooptions       INVARIANTS              # Enable calls of extra sanity
> > checking nooptions       INVARIANT_SUPPORT       # Extra sanity checks
> > of internal structures, required by INVARIANTS nooptions       WITNESS
> >                # Enable checks to detect deadlocks and cycles nooptions
> >       WITNESS_SKIPSPIN        # Don't run witness on spinlocks for
> > speed nooptions       MALLOC_DEBUG_MAXZONES   # Separate malloc(9)
> > zones nooptions       VERBOSE_SYSINIT # Support debug.verbose_sysinit,
> > off by default
> >
> > # Kernel Sanitizers
> > #options        COVERAGE                # Generic kernel coverage. Used
> > by KCOV #options        KCOV                    # Kernel Coverage
> > Sanitizer # Warning: KUBSAN can result in a kernel too large for loader
> > to load #options        KUBSAN                  # Kernel Undefined
> > Behavior Sanitizer
> >
> > # Kernel dump features.
> > #options        EKCD                    # Support for encrypted kernel
> > dumps #options        GZIO                    # gzip-compressed kernel
> > and user dumps #options        ZSTDIO                  #
> > zstd-compressed kernel and user dumps nooptions       NETDUMP
> >       # netdump(4) client support nooptions               NETGDB
> >           # netgdb(4) client support
> >
> > # Make an SMP-capable kernel by default
> > #options        SMP                     # Symmetric MultiProcessor
> > Kernel #options        EARLY_AP_STARTUP
> >
>
> Similar (but not identical to) my non-test firewall config.
>
> Is the error with the patch the same? The reason I ask is that if DDB is 
> undefined, line 44, which includes ddb/ddb.h and defines db_printf() in 
> line 216 of that file, would solve your problem. The fact it doesn't 
> suggests one of two things: 1) The error now is not the same any more, OR 
> 2) The patch I provided wasn't applied.
>
> Anticipating, can you list the contents of /usr/obj/usr/src/amd64.amd64/sys/
> YOUR_KERNEL/opt_ddb.h, please? Don't use the pathname I provide above. Use 
> the actual pathname on your computer to find that file. Use the find 
> command if you have to.

Update to r353742 or later instead.


-- 
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201910182220.x9IMKBVn032870>