dlsym() stopped working for ELF executables?See the FreeBSD Architecture Handbook.
Additionally, much general UNIX® knowledge is directly applicable to FreeBSD.
Please see the article on Contributing to FreeBSD for specific advice on how to do this. Assistance is more than welcome!
There are currently four active/semi-active branches in the FreeBSD Subversion Repository. (Earlier branches are only changed very rarely, which is why there are only four active branches of development):
RELENG_7 AKA 7-STABLE
RELENG_8 AKA 8-STABLE
RELENG_9 AKA 9-STABLE
HEAD AKA -CURRENT AKA 10-CURRENT
HEAD is not an actual branch tag, like the others; it is simply a symbolic constant for “the current, non-branched development stream” which we simply refer to as -CURRENT.
Right now, -CURRENT is the
10.X development stream; the 9-STABLE branch, RELENG_9, forked off from -CURRENT in September 2011 and the 8-STABLE branch, RELENG_8, forked off from -CURRENT in August 2009.
Yes, you can do this without downloading the whole source tree by using the CTM facility.
Please take a look at the article on Contributing to FreeBSD to learn how to submit code.
And thanks for the thought!
Here is typical kernel panic:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x40
fault code = supervisor read, page not present
instruction pointer = 0x8:0xf014a7e5
stack pointer = 0x10:0xf4ed6f24
frame pointer = 0x10:0xf4ed6f28
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 80 (mount)
interrupt mask =
trap number = 12
panic: page fault
When you see a message like this, it is not enough to just reproduce it and send it in. The instruction pointer value is important; unfortunately, it is also configuration dependent. In other words, the value varies depending on the exact kernel image that you are using. If you are using a GENERIC kernel image from one of the snapshots, then it is possible for somebody else to track down the offending function, but if you are running a custom kernel then only you can tell us where the fault occurred.
What you should do is this:
Write down the instruction pointer value. Note that the 0x8: part at the beginning is not significant in this case: it is the 0xf0xxxxxx part that we want.
When the system reboots, do the following:
% nm -n kernel.that.caused.the.panic | grep f0xxxxxx
where f0xxxxxx is the instruction pointer value. The odds are you will not get an exact match since the symbols in the kernel symbol table are for the entry points of functions and the instruction pointer address will be somewhere inside a function, not at the start. If you do not get an exact match, omit the last digit from the instruction pointer value and try again, i.e.:
% nm -n kernel.that.caused.the.panic | grep f0xxxxx
If that does not yield any results, chop off another digit. Repeat until you get some sort of output. The result will be a possible list of functions which caused the panic. This is a less than exact mechanism for tracking down the point of failure, but it is better than nothing.
However, the best way to track down the cause of a panic is by capturing a crash dump, then using kgdb(1) to generate a stack trace on the crash dump.
In any case, the method is this:
Make sure that the following line is included in your kernel configuration file (/usr/src/sys/arch/conf/MYKERNEL):
makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols
Change to the /usr/src directory:
# cd /usr/src
Compile the kernel:
# make buildkernel KERNCONF=MYKERNEL
Wait for make(1) to finish compiling.
# make installkernel KERNCONF=MYKERNEL
Reboot.
Note: If you do not use the KERNCONF make variable a GENERIC kernel will be built and installed.
The make(1) process will have built two kernels. /usr/obj/usr/src/sys/MYKERNEL/kernel and /usr/obj/usr/src/sys/MYKERNEL/kernel.debug. kernel was installed as /boot/kernel/kernel, while kernel.debug can be used as the source of debugging symbols for kgdb(1).
To make sure you capture a crash dump, you need edit /etc/rc.conf and set dumpdev to point to your swap partition (or AUTO). This will cause the rc(8) scripts to use the dumpon(8) command to enable crash dumps. You can also run dumpon(8) manually. After a panic, the crash dump can be recovered using savecore(8); if dumpdev is set in /etc/rc.conf, the rc(8) scripts will run savecore(8) automatically and put the crash dump in /var/crash.
Note: FreeBSD crash dumps are usually the same size as the physical RAM size of your machine. That is, if you have 512 MB of RAM, you will get a 512 MB crash dump. Therefore you must make sure there is enough space in /var/crash to hold the dump. Alternatively, you run savecore(8) manually and have it recover the crash dump to another directory where you have more room. It is possible to limit the size of the crash dump by using options MAXMEM=N where N is the size of kernel's memory usage in KBs. For example, if you have 1 GB of RAM, you can limit the kernel's memory usage to 128 MB by this way, so that your crash dump size will be 128 MB instead of 1 GB.
Once you have recovered the crash dump, you can get a stack trace with kgdb(1) as follows:
% kgdb /usr/obj/usr/src/sys/MYKERNEL/kernel.debug /var/crash/vmcore.0 (kgdb) backtrace
Note that there may be several screens worth of information; ideally you should use script(1) to capture all of them. Using the unstripped kernel image with all the debug symbols should show the exact line of kernel source code where the panic occurred. Usually you have to read the stack trace from the bottom up in order to trace the exact sequence of events that lead to the crash. You can also use kgdb(1) to print out the contents of various variables or structures in order to examine the system state at the time of the crash.
Tip: Now, if you are really insane and have a second computer, you can also configure kgdb(1) to do remote debugging such that you can use kgdb(1) on one system to debug the kernel on another system, including setting breakpoints, single-stepping through the kernel code, just like you can do with a normal user-mode program.
Note: If you have DDB enabled and the kernel drops into the debugger, you can force a panic (and a crash dump) just by typing panic at the ddb prompt. It may stop in the debugger again during the panic phase. If it does, type continue and it will finish the crash dump.
The ELF toolchain does not, by default, make the symbols defined in an
executable visible to the dynamic linker. Consequently dlsym() searches on handles obtained from calls to dlopen(NULL, flags) will fail to find such symbols.
If you want to search, using dlsym(), for symbols
present in the main executable of a process, you need to link the executable
using the --export-dynamic option to the ELF linker (ld(1)).
By default, the kernel address space is 1 GB (2 GB for PAE) for i386. If you run a network-intensive server (e.g., a FTP or HTTP server), or you want to use ZFS, you might find that is not enough.
Add the following line to your kernel configuration file to increase available space and rebuild your kernel:
options KVA_PAGES=N
To find the correct value of N, divide the desired address space size (in megabytes) by four. (For example, it is 512 for 2 GB.)