Export various helper variables for debuggers.

[jhb]

Summary

Export various helper variables describing the layout and size of
certain kernel structures for use by debuggers. This mostly aids
in examining cores from a kernel without debug symbols as a debugger
can infer these values if debug symbols are available.

One set of variables describes the layout of 'struct linker_file' to
walk the list of loaded kernel modules.

A second set of variables describes the layout of 'struct proc' and
'struct thread' to walk the list of processes in the kernel and the
threads in each process.

The 'pcb_size' variable is used to index into the stoppcbs[] array.

The 'vm_maxuser_address' is used to distinguish kernel virtual addresses
from user addresses. This doesn't have to be perfect, and
'vm_maxuser_address' is a cheap and simple way to differentiate kernel
pointers from simple values like TIDs and PIDs.

Test Plan

• These are used in the port of kgdb to gdb7 and I have tested examining a crash from a kernel without debug symbols.

[kib]

How are the variables are used ? Do you examine the dynamic symbol table of the kernel to find the variables ? Why sizeof of struct pcb is exported as sysctl as well ?

[jhb]

In D3773#77985, @kib wrote:

How are the variables are used ? Do you examine the dynamic symbol table of the kernel to find the variables ? Why sizeof of struct pcb is exported as sysctl as well ?

I assume the symbol table is used? gdb is able to find them. This is the same thing that the thread libraries due to export similar information to their corresponding backends in libthread_db.

I only exported a sysctl for the pcb size to be consistent with the surrounding code in kern_mib.c. I don't currently have a use for it, but I've also never used the sizeof(vnode) node either.

[kib]

Perhaps add a note to the comment blocks that the vars must not be marked static.

Also, as a side note, gdb probably should not use pcb size to index into array, but assert that the compiled in size is equal to the one read from kernel.

[jhb]

In D3773#78048, @kib wrote:

Perhaps add a note to the comment blocks that the vars must not be marked static.

Ok.

Also, as a side note, gdb probably should not use pcb size to index into array, but assert that the compiled in size is equal to the one read from kernel.

It doesn't use a compiled in size at all if it can read it from the kernel. The code to set the size that is run each time a kernel is opened looks like this:

	/*
	 * Lookup symbols needed for stoppcbs[] handling, but don't
	 * fail if they aren't present.
	 */
	stoppcbs = kgdb_lookup("stoppcbs");
	TRY {
		pcb_size = parse_and_eval_long("pcb_size");
	} CATCH(e, RETURN_MASK_ERROR) {
		TRY {
			pcb_size = parse_and_eval_long("sizeof(struct pcb)");
		} CATCH(e, RETURN_MASK_ERROR) {
#ifdef HAVE_KVM_OPEN2
			if (kvm_native(nkvm))
				pcb_size = sizeof(struct pcb);
			else
				pcb_size = 0;
#else
			pcb_size = sizeof(struct pcb);
#endif
		} END_CATCH
	} END_CATCH

So it prefers the 'pcb_size' variable if that exists and is exported. If not it falls back to relying on debug symbols to evaluate sizeof(). If that fails it will use a compiled in size for native kernels only.

Later when it goes to locate a PCB for stoppcbs[] it does this:

CORE_ADDR
kgdb_trgt_stop_pcb(u_int cpuid)
{

	if (stoppcbs == 0 || pcb_size == 0)
		return 0;

	return (stoppcbs + pcb_size * cpuid);
}

[kib]

In D3773#78055, @jhb wrote:

It doesn't use a compiled in size at all if it can read it from the kernel. The code to set the size that is run each time a kernel is opened looks like this:

My point is that pcb has an unknown layout if the compiled-in and read from core sizes are not equal.

[jhb]

This is true. The assumption is that while the pcb may grow or shrink, the layout of the register fields we care about are static. This is true in practice I believe and will allow us to add new fields to the pcb without requiring as tight a binding between the debugger and the running kernel. We currently have this sort of situation with 'struct reg'.

Alternatively I suppose we could export a raft of helper variables for offsets in struct pcb?

[kib]

In D3773#78067, @jhb wrote:

This is true. The assumption is that while the pcb may grow or shrink, the layout of the register fields we care about are static. This is true in practice I believe and will allow us to add new fields to the pcb without requiring as tight a binding between the debugger and the running kernel. We currently have this sort of situation with 'struct reg'.

Alternatively I suppose we could export a raft of helper variables for offsets in struct pcb?

Exporting full layout by offsets seems to be excessive. IMO it would be enough to have a comment line in struct pcb delineating layout-stable part vs. the rest.

[emaste]

ping?

[jhb]

• Rebase.
• Note fields used by kgdb.

[jhb]

I retested this today (had to fix a bug in kgdb that prevented kld's from working on a kernel without debug symbols). I have only annotated the pcb structures on amd64 and i386 for now since those are the only platforms kgdb currently supports for cross-debugging of vmcores. As other platforms are added to kgdb (or klldb in the future) I will annotate other pcb structures.