In short, we are already in a good state with the existing ptrace(2) interfaces, as most necessary functions in LLDB are representable by existing NetBSD specific interfaces. We can fully implement core LLDB functionality without further extensions in ptrace(2). During this project dozen of bugs were investigated & fixed and several hundreds of ATF tests added. The major addition is newly added support for hardware assisted watchpoints API for ptrace(2) on amd64 and preliminary code for i386 and XEN.

What has been done

1. Verified basic ptrace(2) functionality:

• debugger cannot attach to PID0 (as root and user)
• debugger cannot attach to PID1 (as user)
• debugger cannot attach to PID1 with sercurelevel >= 1 (as root and user)
• debugger cannot attach to self
• debugger cannot attach to another process unless the process's root directory is at or below the tracing process's root

2. Verified the full matrix of combinations of wait(2) and ptrace(2) in the following test-cases

• tracee can emit PT_TRACE_ME for parent and raise SIGSTOP followed by _exit(2)
• tracee can emit PT_TRACE_ME for parent and raise SIGSTOP followed by _exit(2), with perent sending SIGINT and catching this singal only once with a signal handler and without termination of tracee
• tracee can emit PT_TRACE_ME for parent and raise SIGSTOP, with perent sending SIGINT and terminating the child without signal handler
• tracee can emit PT_TRACE_ME for parent and raise SIGSTOP, with perent sending SIGINT and terminating the child without signal handler
• tracee can emit PT_TRACE_ME for parent and raise SIGCONT, and parent reports it as process stopped
• assert that tracer sees process termination earlier than the parent
• assert that any tracer sees process termination earlier than its parent
• assert that tracer parent can PT_ATTACH to its child
• assert that tracer child can PT_ATTACH to its parent
• assert that tracer sees its parent when attached to tracer (check getppid(2))
• assert that tracer sees its parent when attached to tracer (check sysctl(7) and struct kinfo_proc2)
• assert that tracer sees its parent when attached to tracer (check /proc/curproc/status 3rd column)
• verify that empty EVENT_MASK is preserved
• verify that PTRACE_FORK in EVENT_MASK is preserved
• verify that fork(2) is intercepted by ptrace(2) with EVENT_MASK set to PTRACE_FORK
• verify that fork(2) is not intercepted by ptrace(2) with empty EVENT_MASK
• verify that vfork(2) is intercepted by ptrace(2) with EVENT_MASK set to PTRACE_VFORK [currently EVENT_VFORK not implemented]
• verify that vfork(2) is not intercepted by ptrace(2) with empty EVENT_MASK [currently failing as EVENT_VFORK not implemented]
• verify PT_IO with PIOD_READ_D and len = sizeof(uint8_t)
• verify PT_IO with PIOD_READ_D and len = sizeof(uint16_t)
• verify PT_IO with PIOD_READ_D and len = sizeof(uint32_t)
• verify PT_IO with PIOD_READ_D and len = sizeof(uint64_t)
• verify PT_IO with PIOD_WRITE_D and len = sizeof(uint8_t)
• verify PT_IO with PIOD_WRITE_D and len = sizeof(uint16_t)
• verify PT_IO with PIOD_WRITE_D and len = sizeof(uint32_t)
• verify PT_IO with PIOD_WRITE_D and len = sizeof(uint64_t)
• verify PT_READ_D called once
• verify PT_READ_D called twice
• verify PT_READ_D called three times
• verify PT_READ_D called four times
• verify PT_WRITE_D called once
• verify PT_WRITE_D called twice
• verify PT_WRITE_D called three times
• verify PT_WRITE_D called four times
• verify PT_IO with PIOD_READ_D and PIOD_WRITE_D handshake
• verify PT_IO with PIOD_WRITE_D and PIOD_READ_D handshake
• verify PT_READ_D with PT_WRITE_D handshake
• verify PT_WRITE_D with PT_READ_D handshake
• verify PT_IO with PIOD_READ_I and len = sizeof(uint8_t)
• verify PT_IO with PIOD_READ_I and len = sizeof(uint16_t)
• verify PT_IO with PIOD_READ_I and len = sizeof(uint32_t)
• verify PT_IO with PIOD_READ_I and len = sizeof(uint64_t)
• verify PT_READ_I called once
• verify PT_READ_I called twice
• verify PT_READ_I called three times
• verify PT_READ_I called four times
• verify plain PT_GETREGS call without further steps
• verify plain PT_GETREGS call and retrieve PC
• verify plain PT_GETREGS call and retrieve SP
• verify plain PT_GETREGS call and retrieve INTRV
• verify PT_GETREGS and PT_SETREGS calls without changing regs
• verify plain PT_GETFPREGS call without further steps
• verify PT_GETFPREGS and PT_SETFPREGS calls without changing regs
• verify single PT_STEP call
• verify PT_STEP called twice
• verify PT_STEP called three times
• verify PT_STEP called four times
• verify that PT_CONTINUE with SIGKILL terminates child
• verify that PT_KILL terminates child
• verify basic LWPINFO call for single thread (PT_TRACE_ME)
• verify basic LWPINFO call for single thread (PT_ATTACH from tracer)

3. Documentation of ptrace(2)

• documented PT_SET_EVENT_MASK, PT_GET_EVENT_MASK and PT_GET_PROCESS_STATE
• updated and fixed documentation of PT_DUMPCORE
• documented PT_GETXMMREGS and PT_SETXMMREGS (i386 port specific)
• documented PT_GETVECREGS and PT_SETVECREGS (ppc ports specific)
• other tweaks and cleanups in the documentation

4. exect(3) - execve(2) wrapper with tracing capabilities

Researched its usability and added ATF test, it's close to be marked for removal - it's marked as broken as it is on all ports... this call was inherited from BSD4.2 (VAX) and was never useful since the inception as it is enabling singlestepping before calling execve(2) and tracing libc calls before switching to new process image.

5. pthread_dbg(3) - POSIX threads debugging library documentation

• added documentation for the library in man-page
• upstreamed to the mandoc project to recognize the pthread_dbg(3) library
• document td_close(3) close connection to a threaded process
• document td_map_pth2thr(3) convert a pthread_t to a thread handle
• document td_open(3) make connection to a threaded process
• document td_thr_getname(3) get the user-assigned name of a thread
• document td_thr_info(3) get information on a thread
• document td_thr_iter(3) iterate over the threads in the process

6. pthread_dbg(3) - pthread debug library - t_dummy tests

• assert that dummy lookup functions stops td_open(3)
• assert that td_open(3) for basic proc_{read,write,lookup} works
• asserts that calling td_open(3) twice for the same process fails

7. pthread_dbg(3) - pthread debug library - test of features

• assert that td_thr_iter(3) call without extra logic works
• assert that td_thr_iter(3) call is executed for each thread once
• assert that for each td_thr_iter(3) call td_thr_info(3) is valid
• assert that for each td_thr_iter(3) call td_thr_getname(3) is valid
• assert that td_thr_getname(3) handles shorter buffer parameter and the result is properly truncated
• assert that pthread_t can be translated with td_map_pth2thr(3) to td_thread_t -- and assert earlier that td_thr_iter(3) call is valid
• assert that pthread_t can be translated with td_map_pth2thr(3) to td_thread_t -- and assert later that td_thr_iter() call is valid
• assert that pthread_t can be translated with td_map_pth2thr(3) to td_thread_t -- compare thread's name of pthread_t and td_thread_t
• assert that pthread_t can be translated with td_map_pth2thr(3) to td_thread_t -- assert that thread is in the TD_STATE_RUNNING state

8. pthread_dbg(3) - pthread debug library - code fixes

• fix pt_magic (part of pthread_t) read in td_thr_info(3)
• correct pt_magic reads in td_thr_{getname,suspend,resume}(3)
• fix pt_magic read in td_map_pth2thr(3)
• always set trailing '\0' in td_thr_getname(3) to compose valid ASCIIZ string
• kill SA thread states (TD_STATE_*) in pthread_dbg and add TD_STATE_DEAD
• obsolete thread_type in td_thread_info_st in pthread_dbg.h

This library was designed for Scheduler Activation, and this feature was removed in NetBSD 5.0.

9. wait(2) family tests

• test that wait6(2) handled stopped/continued process loop
• test whether wait(2)-family of functions return error and set ECHILD for lack of children
• test whether wait(2)-family of functions return error and set ECHILD for lack of children, with WNOHANG option verifying that error is still signaled and errno set

10. Debug Registers assisted watchpoints:

• fix rdr6() function on amd64
• add accessors for available x86 Debug Registers (DR0-DR3, DR6, DR7)
• switch x86 CPU Debug Register types from vaddr_t to register_t
• torn down KSTACK_CHECK_DR0, i386-only feature to detect stack overflow

12. i386 port tests

• call PT_GETREGS and iterate over General Purpose registers

13. amd64 port tests

• call PT_GETREGS and iterate over General Purpose registers
• call PT_COUNT_WATCHPOINTS and assert four available watchpoints
• call PT_COUNT_WATCHPOINTS and assert four available watchpoints, verify that we can read these watchpoints
• call PT_COUNT_WATCHPOINTS and assert four available watchpoints, verify that we can read and write unmodified these watchpoints
• call PT_COUNT_WATCHPOINTS and test code trap with watchpoint 0
• call PT_COUNT_WATCHPOINTS and test code trap with watchpoint 1
• call PT_COUNT_WATCHPOINTS and test code trap with watchpoint 2
• call PT_COUNT_WATCHPOINTS and test code trap with watchpoint 3
• call PT_COUNT_WATCHPOINTS and test write trap with watchpoint 0
• call PT_COUNT_WATCHPOINTS and test write trap with watchpoint 1
• call PT_COUNT_WATCHPOINTS and test write trap with watchpoint 2
• call PT_COUNT_WATCHPOINTS and test write trap with watchpoint 3
• call PT_COUNT_WATCHPOINTS and test write trap with watchpoint 0
• call PT_COUNT_WATCHPOINTS and test rw trap with watchpoint 0 on data read
• call PT_COUNT_WATCHPOINTS and test rw trap with watchpoint 1 on data read
• call PT_COUNT_WATCHPOINTS and test rw trap with watchpoint 2 on data read
• call PT_COUNT_WATCHPOINTS and test rw trap with watchpoint 3 on data read

14. Other minor improvements

• document in wtf(7) PCB process control block
• fix cpu_switchto(9) prototype in a comment in RICSV

15. Add support for hardware assisted watchpoints/breakpoints API in ptrace(2)

Add new ptrace(2) calls:

1. PT_COUNT_WATCHPOINTS - count the number of available hardware watchpoints
2. PT_READ_WATCHPOINT - read struct ptrace_watchpoint from the kernel state
3. PT_WRITE_WATCHPOINT - write new struct ptrace_watchpoint state, this includes enabling and disabling watchpoints

The ptrace_watchpoint structure contains MI and MD parts:

typedef struct ptrace_watchpoint {
    int     pw_index;   /* HW Watchpoint ID (count from 0) */
    lwpid_t     pw_lwpid;   /* LWP described */
    struct mdpw pw_md;      /* MD fields */
} ptrace_watchpoint_t;

For example amd64 defines MD as follows:

struct mdpw {
    void    *md_address;
    int  md_condition;
    int  md_length;
};

These calls are protected with the __HAVE_PTRACE_WATCHPOINTS guard.

Tested on amd64, initial support added for i386 and XEN.

16. Reported bugs:

• PR kern/51596 (ptrace(2): raising SIGCONT in a child results with WIFCONTINUED and WIFSTOPPED true in the parent)
• PR kern/51600 (Tracer must detect zombie before child's parent)
• PR standards/51603 WIFCONTINUED()=true always implies WIFSTOPPED()=true
• PR standards/51606 wait(2) with WNOHANG does not return errno ECHILD for lack of children
• PR kern/51621: PT_ATTACH from a parent is unreliable [false positive]
• PR kern/51624: Tracee process cannot see its appropriate parent when debugged by a tracer
• PR kern/51630 ptrace(2) command PT_SET_EVENT_MASK: option PTRACE_VFORK unsupported
• PR lib/51633 tests/lib/libpthread_dbg/t_dummy unreliable [false positive]
• PR lib/51635 td_thr_iter in seems broken [false positive]
• PR lib/51636: It's not possible to run under gdb(1) programs using the pthread_dbg library
• PR kern/51649: PRIxREGISTER and PTRACE_REG_* mismatch
• PR kern/51685 (ptrace(2): Signal does not set PL_EVENT_SIGNAL in (struct ptrace_lwpinfo.)pl_event)
• PR port-amd64/51700 exect(3) misdesigned and hangs

.... and several critical ones not reported and fixed directly by the NetBSD team.

Credit for Christos Zoulas and K. Robert Elz for helping with the mentioned bugs.

17. Added doc/TODO.ptrace entries

• verify ppid of core dump generated with PT_DUMPCORE it must point to the real parent, not tracer
• adapt OpenBSD regress test (regress/sys/ptrace/ptrace.c) for the ATF context
• add new ptrace(2) calls to lock (suspend) and unlock LWP within a process
• add PT_DUMPCORE tests in the ATF framework
• add ATF tests for PT_WRITE_I and PIOD_WRITE_I - test mprotect restrictions
• add ATF tests for PIOD_READ_AUXV
• add tests for the procfs interface covering all functions available on the same level as ptrace(2)
• add support for PT_STEP, PT_GETREGS, PT_SETREGS, PT_GETFPREGS, PT_SETFPREGS in all ports
• integrate all ptrace(2) features in gdb
• add ptrace(2) NetBSD support in LLDB
• add support for detecting equivalent events to PTRACE_O_TRACEEXEC, PTRACE_O_TRACECLONE, PTRACE_O_TRACEEXIT from Linux
• exect(3) rething or remove -- maybe PT_TRACE_ME + PTRACE_O_TRACEEXEC?
• refactor pthread_dbg(3) to only query private pthread_t data, otherwise it duplicates ptrace(2) interface and cannot cover all types of threads

Features in ELF, DWARF, CTF, DTrace are out of scope of the above list.

Plan for the coming weeks

My initial goal is to copy the Linux Process Plugin and add minimal functional support for NetBSD in LLDB. It will be followed with running and passing some tests from the lldb-server test-suite.

This is a shift from the original plan about porting FreeBSD Process Plugin to NetBSD, as the FreeBSD one is lacking remote debugging support and it needs to be redone from scratch.

I'm going to fork wip/lldb-git (as for git snapshot from 16 Dec 2016) for the purpose of this task to wip/lldb-netbsd and work there.

Next steps after finishing this task are to sync up with Pavel from the LLDB team after New Year. The NetBSD Process Plugin will be used as a reference to create new Common Process Plugin shared between Linux and (Net)BSD.

This work was sponsored by The NetBSD Foundation.

The NetBSD Foundation is a non-profit organization and welcomes any donations to help us continue to fund projects and services to the open-source community. Please consider visiting the following URL, and chip in what you can:

http://netbsd.org/donations/#how-to-donate

In short, we are already in a good state with the existing ptrace(2) interfaces, as most necessary functions in LLDB are representable by existing NetBSD specific interfaces. We can fully implement core LLDB functionality without further extensions in ptrace(2). During this project dozen of bugs were investigated & fixed and several hundreds of ATF tests added. The major addition is newly added support for hardware assisted watchpoints API for ptrace(2) on amd64 and preliminary code for i386 and XEN.

What has been done

1. Verified basic ptrace(2) functionality:

• debugger cannot attach to PID0 (as root and user)
• debugger cannot attach to PID1 (as user)
• debugger cannot attach to PID1 with sercurelevel >= 1 (as root and user)
• debugger cannot attach to self
• debugger cannot attach to another process unless the process's root directory is at or below the tracing process's root

2. Verified the full matrix of combinations of wait(2) and ptrace(2) in the following test-cases

• tracee can emit PT_TRACE_ME for parent and raise SIGSTOP followed by _exit(2)
• tracee can emit PT_TRACE_ME for parent and raise SIGSTOP followed by _exit(2), with perent sending SIGINT and catching this singal only once with a signal handler and without termination of tracee
• tracee can emit PT_TRACE_ME for parent and raise SIGSTOP, with perent sending SIGINT and terminating the child without signal handler
• tracee can emit PT_TRACE_ME for parent and raise SIGSTOP, with perent sending SIGINT and terminating the child without signal handler
• tracee can emit PT_TRACE_ME for parent and raise SIGCONT, and parent reports it as process stopped
• assert that tracer sees process termination earlier than the parent
• assert that any tracer sees process termination earlier than its parent
• assert that tracer parent can PT_ATTACH to its child
• assert that tracer child can PT_ATTACH to its parent
• assert that tracer sees its parent when attached to tracer (check getppid(2))
• assert that tracer sees its parent when attached to tracer (check sysctl(7) and struct kinfo_proc2)
• assert that tracer sees its parent when attached to tracer (check /proc/curproc/status 3rd column)
• verify that empty EVENT_MASK is preserved
• verify that PTRACE_FORK in EVENT_MASK is preserved
• verify that fork(2) is intercepted by ptrace(2) with EVENT_MASK set to PTRACE_FORK
• verify that fork(2) is not intercepted by ptrace(2) with empty EVENT_MASK
• verify that vfork(2) is intercepted by ptrace(2) with EVENT_MASK set to PTRACE_VFORK [currently EVENT_VFORK not implemented]
• verify that vfork(2) is not intercepted by ptrace(2) with empty EVENT_MASK [currently failing as EVENT_VFORK not implemented]
• verify PT_IO with PIOD_READ_D and len = sizeof(uint8_t)
• verify PT_IO with PIOD_READ_D and len = sizeof(uint16_t)
• verify PT_IO with PIOD_READ_D and len = sizeof(uint32_t)
• verify PT_IO with PIOD_READ_D and len = sizeof(uint64_t)
• verify PT_IO with PIOD_WRITE_D and len = sizeof(uint8_t)
• verify PT_IO with PIOD_WRITE_D and len = sizeof(uint16_t)
• verify PT_IO with PIOD_WRITE_D and len = sizeof(uint32_t)
• verify PT_IO with PIOD_WRITE_D and len = sizeof(uint64_t)
• verify PT_READ_D called once
• verify PT_READ_D called twice
• verify PT_READ_D called three times
• verify PT_READ_D called four times
• verify PT_WRITE_D called once
• verify PT_WRITE_D called twice
• verify PT_WRITE_D called three times
• verify PT_WRITE_D called four times
• verify PT_IO with PIOD_READ_D and PIOD_WRITE_D handshake
• verify PT_IO with PIOD_WRITE_D and PIOD_READ_D handshake
• verify PT_READ_D with PT_WRITE_D handshake
• verify PT_WRITE_D with PT_READ_D handshake
• verify PT_IO with PIOD_READ_I and len = sizeof(uint8_t)
• verify PT_IO with PIOD_READ_I and len = sizeof(uint16_t)
• verify PT_IO with PIOD_READ_I and len = sizeof(uint32_t)
• verify PT_IO with PIOD_READ_I and len = sizeof(uint64_t)
• verify PT_READ_I called once
• verify PT_READ_I called twice
• verify PT_READ_I called three times
• verify PT_READ_I called four times
• verify plain PT_GETREGS call without further steps
• verify plain PT_GETREGS call and retrieve PC
• verify plain PT_GETREGS call and retrieve SP
• verify plain PT_GETREGS call and retrieve INTRV
• verify PT_GETREGS and PT_SETREGS calls without changing regs
• verify plain PT_GETFPREGS call without further steps
• verify PT_GETFPREGS and PT_SETFPREGS calls without changing regs
• verify single PT_STEP call
• verify PT_STEP called twice
• verify PT_STEP called three times
• verify PT_STEP called four times
• verify that PT_CONTINUE with SIGKILL terminates child
• verify that PT_KILL terminates child
• verify basic LWPINFO call for single thread (PT_TRACE_ME)
• verify basic LWPINFO call for single thread (PT_ATTACH from tracer)

3. Documentation of ptrace(2)

• documented PT_SET_EVENT_MASK, PT_GET_EVENT_MASK and PT_GET_PROCESS_STATE
• updated and fixed documentation of PT_DUMPCORE
• documented PT_GETXMMREGS and PT_SETXMMREGS (i386 port specific)
• documented PT_GETVECREGS and PT_SETVECREGS (ppc ports specific)
• other tweaks and cleanups in the documentation

4. exect(3) - execve(2) wrapper with tracing capabilities

Researched its usability and added ATF test, it's close to be marked for removal - it's marked as broken as it is on all ports... this call was inherited from BSD4.2 (VAX) and was never useful since the inception as it is enabling singlestepping before calling execve(2) and tracing libc calls before switching to new process image.

5. pthread_dbg(3) - POSIX threads debugging library documentation

• added documentation for the library in man-page
• upstreamed to the mandoc project to recognize the pthread_dbg(3) library
• document td_close(3) close connection to a threaded process
• document td_map_pth2thr(3) convert a pthread_t to a thread handle
• document td_open(3) make connection to a threaded process
• document td_thr_getname(3) get the user-assigned name of a thread
• document td_thr_info(3) get information on a thread
• document td_thr_iter(3) iterate over the threads in the process

6. pthread_dbg(3) - pthread debug library - t_dummy tests

• assert that dummy lookup functions stops td_open(3)
• assert that td_open(3) for basic proc_{read,write,lookup} works
• asserts that calling td_open(3) twice for the same process fails

7. pthread_dbg(3) - pthread debug library - test of features

• assert that td_thr_iter(3) call without extra logic works
• assert that td_thr_iter(3) call is executed for each thread once
• assert that for each td_thr_iter(3) call td_thr_info(3) is valid
• assert that for each td_thr_iter(3) call td_thr_getname(3) is valid
• assert that td_thr_getname(3) handles shorter buffer parameter and the result is properly truncated
• assert that pthread_t can be translated with td_map_pth2thr(3) to td_thread_t -- and assert earlier that td_thr_iter(3) call is valid
• assert that pthread_t can be translated with td_map_pth2thr(3) to td_thread_t -- and assert later that td_thr_iter() call is valid
• assert that pthread_t can be translated with td_map_pth2thr(3) to td_thread_t -- compare thread's name of pthread_t and td_thread_t
• assert that pthread_t can be translated with td_map_pth2thr(3) to td_thread_t -- assert that thread is in the TD_STATE_RUNNING state

8. pthread_dbg(3) - pthread debug library - code fixes

• fix pt_magic (part of pthread_t) read in td_thr_info(3)
• correct pt_magic reads in td_thr_{getname,suspend,resume}(3)
• fix pt_magic read in td_map_pth2thr(3)
• always set trailing '\0' in td_thr_getname(3) to compose valid ASCIIZ string
• kill SA thread states (TD_STATE_*) in pthread_dbg and add TD_STATE_DEAD
• obsolete thread_type in td_thread_info_st in pthread_dbg.h

This library was designed for Scheduler Activation, and this feature was removed in NetBSD 5.0.

9. wait(2) family tests

• test that wait6(2) handled stopped/continued process loop
• test whether wait(2)-family of functions return error and set ECHILD for lack of children
• test whether wait(2)-family of functions return error and set ECHILD for lack of children, with WNOHANG option verifying that error is still signaled and errno set

10. Debug Registers assisted watchpoints:

• fix rdr6() function on amd64
• add accessors for available x86 Debug Registers (DR0-DR3, DR6, DR7)
• switch x86 CPU Debug Register types from vaddr_t to register_t
• torn down KSTACK_CHECK_DR0, i386-only feature to detect stack overflow

12. i386 port tests

• call PT_GETREGS and iterate over General Purpose registers

13. amd64 port tests

• call PT_GETREGS and iterate over General Purpose registers
• call PT_COUNT_WATCHPOINTS and assert four available watchpoints
• call PT_COUNT_WATCHPOINTS and assert four available watchpoints, verify that we can read these watchpoints
• call PT_COUNT_WATCHPOINTS and assert four available watchpoints, verify that we can read and write unmodified these watchpoints
• call PT_COUNT_WATCHPOINTS and test code trap with watchpoint 0
• call PT_COUNT_WATCHPOINTS and test code trap with watchpoint 1
• call PT_COUNT_WATCHPOINTS and test code trap with watchpoint 2
• call PT_COUNT_WATCHPOINTS and test code trap with watchpoint 3
• call PT_COUNT_WATCHPOINTS and test write trap with watchpoint 0
• call PT_COUNT_WATCHPOINTS and test write trap with watchpoint 1
• call PT_COUNT_WATCHPOINTS and test write trap with watchpoint 2
• call PT_COUNT_WATCHPOINTS and test write trap with watchpoint 3
• call PT_COUNT_WATCHPOINTS and test write trap with watchpoint 0
• call PT_COUNT_WATCHPOINTS and test rw trap with watchpoint 0 on data read
• call PT_COUNT_WATCHPOINTS and test rw trap with watchpoint 1 on data read
• call PT_COUNT_WATCHPOINTS and test rw trap with watchpoint 2 on data read
• call PT_COUNT_WATCHPOINTS and test rw trap with watchpoint 3 on data read

14. Other minor improvements

• document in wtf(7) PCB process control block
• fix cpu_switchto(9) prototype in a comment in RICSV

15. Add support for hardware assisted watchpoints/breakpoints API in ptrace(2)

Add new ptrace(2) calls:

1. PT_COUNT_WATCHPOINTS - count the number of available hardware watchpoints
2. PT_READ_WATCHPOINT - read struct ptrace_watchpoint from the kernel state
3. PT_WRITE_WATCHPOINT - write new struct ptrace_watchpoint state, this includes enabling and disabling watchpoints

The ptrace_watchpoint structure contains MI and MD parts:

typedef struct ptrace_watchpoint {
    int     pw_index;   /* HW Watchpoint ID (count from 0) */
    lwpid_t     pw_lwpid;   /* LWP described */
    struct mdpw pw_md;      /* MD fields */
} ptrace_watchpoint_t;

For example amd64 defines MD as follows:

struct mdpw {
    void    *md_address;
    int  md_condition;
    int  md_length;
};

These calls are protected with the __HAVE_PTRACE_WATCHPOINTS guard.

Tested on amd64, initial support added for i386 and XEN.

16. Reported bugs:

• PR kern/51596 (ptrace(2): raising SIGCONT in a child results with WIFCONTINUED and WIFSTOPPED true in the parent)
• PR kern/51600 (Tracer must detect zombie before child's parent)
• PR standards/51603 WIFCONTINUED()=true always implies WIFSTOPPED()=true
• PR standards/51606 wait(2) with WNOHANG does not return errno ECHILD for lack of children
• PR kern/51621: PT_ATTACH from a parent is unreliable [false positive]
• PR kern/51624: Tracee process cannot see its appropriate parent when debugged by a tracer
• PR kern/51630 ptrace(2) command PT_SET_EVENT_MASK: option PTRACE_VFORK unsupported
• PR lib/51633 tests/lib/libpthread_dbg/t_dummy unreliable [false positive]
• PR lib/51635 td_thr_iter in seems broken [false positive]
• PR lib/51636: It's not possible to run under gdb(1) programs using the pthread_dbg library
• PR kern/51649: PRIxREGISTER and PTRACE_REG_* mismatch
• PR kern/51685 (ptrace(2): Signal does not set PL_EVENT_SIGNAL in (struct ptrace_lwpinfo.)pl_event)
• PR port-amd64/51700 exect(3) misdesigned and hangs

.... and several critical ones not reported and fixed directly by the NetBSD team.

Credit for Christos Zoulas and K. Robert Elz for helping with the mentioned bugs.

17. Added doc/TODO.ptrace entries

• verify ppid of core dump generated with PT_DUMPCORE it must point to the real parent, not tracer
• adapt OpenBSD regress test (regress/sys/ptrace/ptrace.c) for the ATF context
• add new ptrace(2) calls to lock (suspend) and unlock LWP within a process
• add PT_DUMPCORE tests in the ATF framework
• add ATF tests for PT_WRITE_I and PIOD_WRITE_I - test mprotect restrictions
• add ATF tests for PIOD_READ_AUXV
• add tests for the procfs interface covering all functions available on the same level as ptrace(2)
• add support for PT_STEP, PT_GETREGS, PT_SETREGS, PT_GETFPREGS, PT_SETFPREGS in all ports
• integrate all ptrace(2) features in gdb
• add ptrace(2) NetBSD support in LLDB
• add support for detecting equivalent events to PTRACE_O_TRACEEXEC, PTRACE_O_TRACECLONE, PTRACE_O_TRACEEXIT from Linux
• exect(3) rething or remove -- maybe PT_TRACE_ME + PTRACE_O_TRACEEXEC?
• refactor pthread_dbg(3) to only query private pthread_t data, otherwise it duplicates ptrace(2) interface and cannot cover all types of threads

Features in ELF, DWARF, CTF, DTrace are out of scope of the above list.

Plan for the coming weeks

My initial goal is to copy the Linux Process Plugin and add minimal functional support for NetBSD in LLDB. It will be followed with running and passing some tests from the lldb-server test-suite.

This is a shift from the original plan about porting FreeBSD Process Plugin to NetBSD, as the FreeBSD one is lacking remote debugging support and it needs to be redone from scratch.

I'm going to fork wip/lldb-git (as for git snapshot from 16 Dec 2016) for the purpose of this task to wip/lldb-netbsd and work there.

Next steps after finishing this task are to sync up with Pavel from the LLDB team after New Year. The NetBSD Process Plugin will be used as a reference to create new Common Process Plugin shared between Linux and (Net)BSD.

This work was sponsored by The NetBSD Foundation.

The NetBSD Foundation is a non-profit organization and welcomes any donations to help us continue to fund projects and services to the open-source community. Please consider visiting the following URL, and chip in what you can:

http://netbsd.org/donations/#how-to-donate

A cyclic trend in operating systems is moving things in and out of the kernel for better performance. Currently, the pendulum is swinging in the direction of userspace being the locus of high performance. The anykernel architecture of NetBSD ensures that the same kernel drivers work in a monolithic kernel, userspace and beyond. One of those driver stacks is networking. In this article we assume that the NetBSD networking stack is run outside of the monolithic kernel in a rump kernel and survey the open source interface layer options.

There are two sub-aspects to networking. The first facet is supporting network protocols and suites such as IPv6, IPSec and MPLS. The second facet is delivering packets to and from the protocol stack, commonly referred to as the interface layer. While the first facet for rump kernels is unchanged from the networking stack running in a monolithic NetBSD kernel, there is support for a number of interfaces not available in kernel mode.

---

DPDK

The Data Plane Development Kit is meant to be used for high-performance, multiprocessor-aware networking. DPDK offers network access by attaching to hardware and providing a hardware-independent API for sending and receiving packets. The most common runtime environment for DPDK is Linux userspace, where a UIO userspace driver framework kernel module is used to enable access to PCI hardware. The NIC drivers themselves are provided by DPDK and run in application processes.

For high performance, DPDK uses a run-to-completion scheduling model -- the same model is used by rump kernels. This scheduling model means that NIC devices are accessed in polled mode without any interrupts on the fast path. The only interrupts that are used by DPDK are for slow-path operations such as notifications of link status change.

The rump kernel interface driver for DPDK is available here. DPDK itself is described in significant detail in the documents available from the Intel DPDK page.

netmap

Like DPDK, netmap offers user processes access to NIC hardware with a high-performance userspace packet processing intent. Unlike DPDK, netmap reuses NIC drivers from the host kernel and provides memory-mapped buffer rings for accessing the device packet queues. In other words, the device drivers still remain in the host kernel, but low-level and low-overhead access to hardware is made available to userspace processes. In addition to the memory-mapping of buffers, netmap uses other performance optimization methods such as batch processing and buffer reallocation, and can easily saturate a 10GigE with minimum-size frames. Another significant difference to DPDK is that netmap allows also for a blocking mode of operation.

Netmap is coupled with a high-performance software virtual switch called VALE. It can be used to interconnect networks between virtual machines and processes such as rump kernels. The netmap API is used also by VALE, so VALE switching can be used with the rump kernel driver for netmap.

The rump kernel interface driver for netmap is available here. Multiple papers describing netmap and VALE are available from the netmap page.

TAP

A tap device injects packets written into a device node, e.g. /dev/tap, to a tap virtual network interface. Conversely, packets received by the virtual tap network can be read from the device node. The tap network interface can be bridged with other network interfaces to provide further network access. While indirect access to network hardware via the bridge is not maximally efficient, it is not hideously slow either: a rump kernel backed by a tap device can saturate a gigabit Ethernet. The advantage of the tap device is portability, as it is widely available on Unix-type systems. Tap interfaces also virtualize nicely, and most operating systems will allow unprivileged processes to use tap interface as long as the processes have the credentials to access the respective device nodes.

The tap device was the original method for accessing with a rump kernel. In fact, the in-kernel side of the rump kernel network driver was rather short-sightedly named virt back in 2008. The virt driver and the associated hypercalls are available in the NetBSD tree. Fun fact: the tap driver is also the method for packet shovelling when running the NetBSD TCP/IP stack in the Linux kernel; the rationale is provided in a comment here and also by running wc -l.

Xen hypercalls

After a fashion, using Xen hypercalls is a variant of using the TAP device: a virtualized network resource is accessed using high-level hypercalls. However, instead of accessing the network backend from a device node, Xen hypercalls are used. The Xen driver is limited to the Xen environment and is available here.

NetBSD PCI NIC drivers

The previous examples we have discussed use a high-level interface to packet I/O functions. For example, to send a packet, the rump kernel will issue a hypercall which essentially says "transmit these data", and the network backend handles the request. When using NetBSD PCI drivers, the hypercalls work at a low level, and deal with for example reading/writing the PCI configuration space and mapping the device memory space into the rump kernel. As a result, using NetBSD PCI device drivers in a rump kernel work exactly like in a regular kernel: the PCI devices are probed during rump kernel bootstrap, relevant drivers are attached, and packet shovelling works by the drivers fiddling the relevant device registers.

The hypercall interfaces and necessary kernel-side implementations are currently hosted in the repository providing Xen support for rump kernels. Strictly speaking, there is nothing specific to Xen in these bits, and they will most likely be moved out of the Xen repository once PCI device driver support for other planned platforms, such as Linux userspace, is completed. The hypercall implementations, which are Xen specific, are available here.

shmif

For testing networking, it is advantageous to have an interface which can communicate with other networking stacks on the same host without requiring elevated privileges, special kernel features or a priori setup in the form of e.g. a daemon process. These requirements are filled by shmif, which uses file-backed shared memory as a bus for Ethernet frames. Each interface attaches to a pathname, and interfaces attached to the same pathname see the the same traffic.

The shmif driver is available in the NetBSD tree.

---

We presented a total of six open source network backends for networking with rump kernels. These backends represent four different methodologies:

• DPDK and netmap provide high-performance network hardware access using high-level hypercalls.
• TAP and Xen hypercall drivers provide access to virtualized network resources using high-level hypercalls.
• NetBSD PCI drivers access hardware directly using register-level device access to send and receive packets.
• shmif allows for unprivileged testing of the networking stack without relying on any special kernel drivers or global resources.

Choice is a good thing here, as the optimal backend ultimately depends on the characteristics of the application.

New interview with schmonz

Last week I met with about 40 other developers from various projects (mostly Debian, but also Arch Linux, FreeBSD, Guix, Homebrew, MacPorts, Tor and some others) in Athens for a three day conference about reproducible builds, i.e. the task of getting the same binaries from the same source on a particular platform.

The advantages are better verifyability that the source code matches the binaries, thus addressing one of the many steps one has to check before trusting the software one runs.

We discussed various topics during the conference in small groups:

• technical aspects (how to achieve this, how to cooperate over distributions, ...)
• social aspects (how to argue for it with programmers, managers, lay people) financial aspects (how to get funding for such work)
• lots of other stuff

For NetBSD, there are two parts:

Making the base system reproducible: a big part of the work for this has already been done, but there a number of open issues, visible e.g. in Debian's regularly scheduled test builds, up to the fact that this is not the default yet.

Making pkgsrc reproducible: This will be a huge task, since pkgsrc targets so many and diverse platforms. On the other hand, we have a very good framework below that that should help.

For giggles, I've compared the binary packages for png built on 7.99.22 and 7.99.23 (in my chrooted pbulk only though) and found that most differences were indeed only timestamps. So there's probably a lot of low-hanging fruit in this area as well.

If you want to help, here are some ideas:

• fix the MKREPRO bugs (like PRs 48355, 48637, 48638, 50119, 50120, 50122)
• check https://reproducible.debian.net/netbsd/netbsd.html for more issues, or do your own tests
• discuss turning on MKREPRO by default
• starting working on reproducibility in pkgsrc:
  • remove gzip time stamps from binary packages
  • use a fixed time stamp for files inside binary packages (perhaps depending on newest file in sources, or latest change in pkgsrc files for the pkg)
  • identify more of the issues, like how to get symbols ordered reproducible in binaries (look at shells/bash)

Thanks to the NetBSD developers who already worked on this before, and to TNF for funding the travel and the Linux Foundation for funding the accomodation for my participation in the conference, and Holger Levsen for inviting me.

Those following the source-changes mailing list closely may have noticed several evbarm kernels getting "options MULTIPROCESSOR" in the last few days. This is due to those configurations now running properly in SMP mode, thanks to work mostly done by Matt Thomas and Nick Hudson.

The list of supported multiprocessor boards currently is:

• Banana Pi (BPI)
• Cubieboard 2 (CUBIEBOARD)
• Cubietruck (CUBIETRUCK)
• Merrii Hummingbird A31 (HUMMINGBIRD_A31)
• CUBOX-I
• NITROGEN6X

Details how to create bootable media and various other information for the Allwinner boards can be found on the NetBSD/evbarm on Allwinner Technology SoCs wiki page.

The release engineering team is discussing how to bring all those changes into the netbsd-7 branch as well, so that we can call NetBSD 7.0 "the ARM SoC release".

While multicore ARM chips are mostly known for being used in cell phones and tablet devices, there are also some nice "tiny PC" variants out there, like the CubieTruck, which originally comes with a small transparent case that allows piggybacking it onto a 2.5" hard disk:

Image from cubieboard.org under creative commons license.

This is nice to put next to your display, but a bit too tiny and fragile for my test lab - so I reused an old (originally mac68k cartridge) SCSI enclosure for mine:

Image by myself under creative commons license.

This machine is used to run regular tests for big endian arm, the results are gathered here. Running it big-endian is just a way to trigger more bugs.

The last test run logged on the page is already done with an SMP kernel. No regressions were found so far, and the other bugs (sligtly more than 30 failures in the test run is way too much) will be addressed one by one.

Now happy multi-ARM-ing everyone, and I am looking forward to a great NetBSD 7.0 release!

The NetBSD Project is pleased to announce NetBSD 5.1.5, the fifth security/bugfix update of the NetBSD 5.1 release branch, and NetBSD 5.2.3, the third security/bugfix update of the NetBSD 5.2 release branch. They represent a selected subset of fixes deemed important for security or stability reasons, and if you are running a prior release of either branch, we strongly suggest that you update to one of these releases.

For more details, please see the NetBSD 5.1.5 release notes or NetBSD 5.2.3 release notes.

Complete source and binaries for NetBSD are available for download at many sites around the world. A list of download sites providing FTP, AnonCVS, SUP, and other services may be found at http://www.NetBSD.org/mirrors/.

When I found out that Ingenic is giving away some of their MIPS Creator CI20 boards I applied, and to my surprise they sent me one. Of course, the point was to make NetBSD work on it. I just finished the first step.

That is, make it load a kernel, identify / setup the CPU, attach a serial console. This is what it looks like:

U-Boot SPL 2013.10-rc3-g9329ab16a204 (Jun 26 2014 - 09:43:22)
SDRAM H5TQ2G83CFR initialization... done


U-Boot 2013.10-rc3-g9329ab16a204 (Jun 26 2014 - 09:43:22)

Board: ci20 (Ingenic XBurst JZ4780 SoC)
DRAM: 1 GiB
NAND: 8192 MiB
MMC: jz_mmc msc1: 0
In: eserial3
Out: eserial3
Err: eserial3
Net: dm9000
ci20# dhcp
ERROR: resetting DM9000 -> not responding
dm9000 i/o: 0xb6000000, id: 0x90000a46
DM9000: running in 8 bit mode
MAC: d0:31:10:ff:7e:89
operating at 100M full duplex mode
BOOTP broadcast 1
DHCP client bound to address 192.168.0.47
*** Warning: no boot file name; using 'C0A8002F.img'
Using dm9000 device
TFTP from server 192.168.0.44; our IP address is 192.168.0.47
Filename 'C0A8002F.img'.
Load address: 0x88000000
Loading: #################################################################
##############
284.2 KiB/s
done
Bytes transferred = 1146945 (118041 hex)
ci20# bootm
## Booting kernel from Legacy Image at 88000000 ...
Image Name: evbmips 7.99.1 (CI20)
Image Type: MIPS NetBSD Kernel Image (gzip compressed)
Data Size: 1146881 Bytes = 1.1 MiB
Load Address: 80020000
Entry Point: 80020000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
subcommand not supported
ci20# g 80020000
## Starting applicatpmap_steal_memory: seg 0: 0x30c 0x30c 0xffff 0xffff
Loaded initial symtab at 0x802502d4, strtab at 0x80270cb4, # entries 8323
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.

NetBSD 7.99.1 (CI20) #113: Sat Nov 22 09:58:39 EST 2014
ml@blackbush:/home/build/obj_evbmips32/sys/arch/evbmips/compile/CI20
Ingenic XBurst
total memory = 1024 MB
avail memory = 1001 MB
kern.module.path=/stand/evbmips/7.99.1/modules
mainbus0 (root)
cpu0 at mainbus0: 1200.00MHz (hz cycles = 120000, delay divisor = 12)
cpu0: Ingenic XBurst (0x3ee1024f) Rev. 79 with unknown FPC type (0x330000) Rev. 0
cpu0: 32 TLB entries, 16MB max page size
cpu0: 32KB/32B 8-way set-associative L1 instruction cache
cpu0: 32KB/32B 8-way set-associative write-back L1 data cache
com0 at mainbus0: Ingenic UART, working fifo
com0: console

root device:

What works:

• CPU identification and setup
• serial console via UART0
• reset ( by provoking a watchdog timeout )
• basic timers - enough for delay(), since the CPUs don't have MIPS cycle counters
• dropping into ddb and poking around

What doesn't work (yet):

• interrupts
• everything else

Biggest obstacle - believe it or not, the serial port. The on-chip UARTs are mostly 16550 compatible. Mostly. The difference is one bit in the FIFO control register which, if not set, powers down the UART. So throwing data at the UART by hand worked but as soon as the com driver took over the line went dead. It took me a while to find that one.

FOSDEM 2014 will take place on 1–2 February, 2014, in Brussels, Belgium. Just like in the last years, there will be both a BSD booth and a developer's room (on Saturday).

The topics of the devroom include all BSD operating systems. Every talk is welcome, from internal hacker discussion to real-world examples and presentations about new and shiny features. The default duration for talks will be 45 minutes including discussion. Feel free to ask if you want to have a longer or a shorter slot.

If you already submitted a talk last time, please note that the procedure is slightly different.

To submit your proposal, visit

https://penta.fosdem.org/submission/FOSDEM14/

and follow the instructions to create an account and an “event”. Please select “BSD devroom” as the track. (Click on “Show all” in the top right corner to display the full form.)

Please include the following information in your submission:

• The title and subtitle of your talk (please be descriptive, as titles will be listed with ~500 from other projects)
• A short abstract of one paragraph
• A longer description if you wish to do so
• Links to related websites/blogs etc.

The deadline for submissions is December 20, 2013. The talk committee, consisting of Daniel Seuffert, Marius Nünnerich and Benny Siegert, will consider the proposals. If yours has been accepted, you will be informed by e-mail before the end of the year.

The NetBSD Project is pleased to announce NetBSD 7.0, the fifteenth major release of the NetBSD operating system.

This release brings stability improvements, hundreds of bug fixes, and many new features. Some highlights of the NetBSD 7.0 release are:

• DRM/KMS support brings accelerated graphics to x86 systems using modern Intel and Radeon devices.
• Multiprocessor ARM support.
• Support for many new ARM boards:
  • Raspberry Pi 2
  • ODROID-C1
  • BeagleBoard, BeagleBone, BeagleBone Black
  • MiraBox
  • Allwinner A20, A31: Cubieboard2, Cubietruck, Banana Pi, etc.
  • Freescale i.MX50, i.MX51: Kobo Touch, Netwalker
  • Xilinx Zynq: Parallella, ZedBoard
• Major NPF improvements:
  • BPF with just-in-time (JIT) compilation by default.
  • Support for dynamic rules.
  • Support for static (stateless) NAT.
  • Support for IPv6-to-IPv6 Network Prefix Translation (NPTv6) as per RFC 6296.
  • Support for CDB based tables (uses perfect hashing and guarantees lock-free O(1) lookups).
• Multiprocessor support in the USB subsystem.
• blacklistd(8), a new daemon that integrates with packet filters to dynamically protect other network daemons such as ssh, named, and ftpd from network break-in attempts.
• Numerous improvements in the handling of disk wedges (see dkctl(8) for information about wedges).
• GPT support in sysinst via the extended partitioning menu.
• Lua kernel scripting.
• epoc32, a new port which supports Psion EPOC PDAs.
• GCC 4.8.4, which brings support for C++11.
• Optional fully BSD-licensed C/C++ runtime env: compiler_rt, libc++, libcxxrt.

For a more complete list of changes in NetBSD 7.0, see the release notes.

Complete source and binaries for NetBSD 7.0 are available for download at many sites around the world. A list of download sites providing FTP, AnonCVS, and other services may be found at http://www.NetBSD.org/mirrors/.

If NetBSD makes your life better, please consider making a donation to The NetBSD Foundation in order to support the continued development of this fine operating system. As a non-profit organization with no commercial backing, The NetBSD Foundation depends on donations from its users. Your donation helps us fund large development projects, cover operating expenses, and keep the servers alive. For information about donating, visit http://www.NetBSD.org/donations/

In keeping with NetBSD's policy of supporting only the current (7.x) and next most recent (6.x) release majors, the release of NetBSD 7.0 marks the end of life for the 5.x branches. As in the past, a month of overlapping support is being provided in order to ease the migration to newer releases.

On November 9, the following branches will no longer be maintained:

• netbsd-5-2
• netbsd-5-1
• netbsd-5

Furthermore:

• There will be no more pullups to the branches (even for security issues)
• There will be no security advisories made for any of the 5.x releases
• The existing 5.x releases on ftp.NetBSD.org will be moved into /pub/NetBSD-archive/

We hope 7.0 serves you well!

This year the annual EuroBSDcon event took place in Paris (September 21st-24th). There were BSD summits, tutorials and talks, including NetBSD & pkgsrc ones.

Tutorials

I came to Paris on Wednesday in order to participate in tutorials:

• Thursday - DTrace for Developers: no more printfs - by George Neville-Neil
• Friday - How to untangle your threads from a giant lock in a multiprocessor system - by Taylor R. Campbell

The NetBSD Summit

On Friday there was a NetBSD summit that gathered around 15 developers. I have not participated in it myself because of the tutorial on SMP. There were three presentations:

• News from the version control front - by joerg,
• Scripting DDB with Forth - by uwe,
• NetBSD on Google Compute Engine - by bsiegert.

Talks

During Saturday and Sunday there were several NetBSD and pkgsrc related presentations:

• A Modern Replacement for BSD spell(1) - Abhinav Upadhyay
• Portable Hotplugging: NetBSD's uvm_hotplug(9) API development - Cherry G. Mathew
• Hardening pkgsrc - Pierre Pronchery
• Reproducible builds on NetBSD - Christos Zoulas
• The school of hard knocks - PT1 - Sevan Janiyan
• The LLDB Debugger on NetBSD - Kamil Rytarowski
• What's in store for NetBSD 8.0? - Alistair Crooks

During the closing ceremony there was a speech by Alistair Crooks on behalf of The NetBSD Foundation.

LLDB

At the conference I presented my work on "The LLDB Debugger on NetBSD":

• slides
• video

Plan for the next milestone

Resume porting tsan and msan to NetBSD with a plan to switch back to the LLDB porting.

This work was sponsored by The NetBSD Foundation.

The NetBSD Foundation is a non-profit organization and welcomes any donations to help us continue funding projects and services to the open-source community. Please consider visiting the following URL, and chip in what you can:

http://netbsd.org/donations/#how-to-donate

This year the annual EuroBSDcon event took place in Paris (September 21st-24th). There were BSD summits, tutorials and talks, including NetBSD & pkgsrc ones.

Tutorials

I came to Paris on Wednesday in order to participate in tutorials:

• Thursday - DTrace for Developers: no more printfs - by George Neville-Neil
• Friday - How to untangle your threads from a giant lock in a multiprocessor system - by Taylor R. Campbell

The NetBSD Summit

On Friday there was a NetBSD summit that gathered around 15 developers. I have not participated in it myself because of the tutorial on SMP. There were three presentations:

• News from the version control front - by joerg,
• Scripting DDB with Forth - by uwe,
• NetBSD on Google Compute Engine - by bsiegert.

Talks

During Saturday and Sunday there were several NetBSD and pkgsrc related presentations:

• A Modern Replacement for BSD spell(1) - Abhinav Upadhyay
• Portable Hotplugging: NetBSD's uvm_hotplug(9) API development - Cherry G. Mathew
• Hardening pkgsrc - Pierre Pronchery
• Reproducible builds on NetBSD - Christos Zoulas
• The school of hard knocks - PT1 - Sevan Janiyan
• The LLDB Debugger on NetBSD - Kamil Rytarowski
• What's in store for NetBSD 8.0? - Alistair Crooks

During the closing ceremony there was a speech by Alistair Crooks on behalf of The NetBSD Foundation.

LLDB

At the conference I presented my work on "The LLDB Debugger on NetBSD":

• slides
• video

Plan for the next milestone

Resume porting tsan and msan to NetBSD with a plan to switch back to the LLDB porting.

This work was sponsored by The NetBSD Foundation.

The NetBSD Foundation is a non-profit organization and welcomes any donations to help us continue funding projects and services to the open-source community. Please consider visiting the following URL, and chip in what you can:

http://netbsd.org/donations/#how-to-donate

By vote of The NetBSD Foundation Board of Directors, the officers for the 2017 term are:

President: William J. Coldwell <billc>
Vice President: Jeremy C. Reed <reed>
Secretary: Christos Zoulas <christos>
Treasurer: Christos Zoulas <christos>
Assistant Secretary: Thomas Klausner <wiz>
Assistant Treasurer: Taylor R. Campbell <riastradh>

By vote of The NetBSD Foundation Board of Directors, the officers for the 2017 term are:

President: William J. Coldwell <billc>
Vice President: Jeremy C. Reed <reed>
Secretary: Christos Zoulas <christos>
Treasurer: Christos Zoulas <christos>
Assistant Secretary: Thomas Klausner <wiz>
Assistant Treasurer: Taylor R. Campbell <riastradh>

Let me tell you about my experience at EuroBSDcon 2017 in Paris, France. We will see what was presented during the NetBSD developer summit on Friday and then we will give a look to all of the NetBSD and pkgsrc presentations given during the conference session on Saturday and Sunday. Of course, a lot of fun also happened on the "hall track", the several breaks during the conference and the dinners we had together with other *BSD developers and community! This is difficult to describe and I will try to just share some part of that with photographs that we have taken. I can just say that it was a really beautiful experience, I had a great time with others and, after coming back home... ...I miss all of that! So, if you have never been in any BSD conferences I strongly suggest you to go to the next ones, so please stay tuned via NetBSD Events. Being there this is probably the only way to understand these feelings!

Thursday (21/09): NetBSD developers dinner

Arriving in Paris via a night train from Italy I literally sleep-walked through Paris getting lost again and again. After getting in touch with other developers we had a dinner together and went sightseeing for a^Wseveral beers!

Friday (22/09): NetBSD developers summit

On Friday morning we met for the NetBSD developers summit kindly hosted by Arolla.

From left to right: alnsn, sborrill; abhinav; uwe and leot; christos, cherry, ast and bsiegert; martin and khorben.

The devsummit was moderated by Jörg (joerg) and organized by Jean-Yves (jym).

NetBSD on Google Compute Engine -- Benny Siegert (bsiegert)

After a self-presentation the devsummit presentations session started with the talk presented by Benny (bsiegert) about NetBSD on Google Compute Engine.

Benny first introduced Google Compute Engine (GCE) and then started describing how to run NetBSD on it.

At the moment there are no official NetBSD images and so users need to create their own. However, netbsd-gce script completely automatize this process that:

• uses Anita to stage an installation in QEMU
• adjust several tweaks to ensure that networking and storage will work on GCE
• packs the image into a .tar.gz file

The .tar.gz image then just need to be uploaded to a Cloud Storage bucket, create a GCE image from it and then launch VMs based on that image.

He also discussed about GCE instance metadata, several problems founds and how they were fixed (it's better to use NetBSD 8_BETA or -current!) and some future works.

For more information slides (PDF) of the talk are also available.

Scripting DDB with Forth -- Valery Ushakov (uwe)

Valery (uwe) presented a talk about Scripting DDB with Forth. It was based on a long story and actually the first discussion about it appeared on tech-kern@ mailing list in his Scripting DDB in Forth? thread (ddb(4) is the NetBSD in-kernel debugger).

He showed how one can associate forth commands/conditions with ddb breakpoints. He used "pid divisible by 3" as an example of condition for a breakpoint set in getpid(2) system call:

db{0}> forth
ok : field   create , does> @ + ;
ok #300 field lwp>l_proc
ok #120 field proc>p_pid
ok : getpid   curlwp lwp>l_proc @ proc>p_pid @ ;
ok : checkpid   getpid dup ." > PID IS " . cr   3 mod 0= ;
ok bye
-- STACK: <empty>
db{0}> break sys_getpid_with_ppid
db{0}> command . = checkpid
db{0}> c

...and then on a shell:

# (:)
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip 0xc090df89 cs 0x8 eflags 0x246 cr2 0xad8ef2c0 ilevel 0 esp 0xc0157fbd
curlwp 0xc2b5c2c0 pid 798 lid 1 lowest kstack 0xdabb42c0
> PID IS 798
-- STACK:
0xffffffff   -1
Breakpoint in pid 798.1 (ksh) at        netbsd:sys_getpid_with_ppid: pushl %ebp
db{0}> c
# (:)
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip 0xc090df89 cs 0x8 eflags 0x246 cr2 0xad8ef2c0 ilevel 0 esp 0xc0157fbd
curlwp 0xc2b5c2c0 pid 823 lid 1 lowest kstack 0xdabb42c0
> PID IS 823
-- STACK:
0x00000000  0
Command returned 0
# 

If you are more interested in this presentation I strongly suggest to also give a look to uwe's forth Mercurial repository.

News from the version control front -- Jörg Sonnenberger (joerg)

The third presentation of the devsummit was a presentation about the recent work done by Jörg (joerg) in the VCS conversions.

Jörg started the presentation discussing about the infrastructure used for the CVS -> Fossil -> Git conversion and CVS -> Fossil -> Mercurial conversion.

It's worth also noticing that the Mercurial conversion is fully integrated and is regularly pushed to Bitbucket and src repository pushed some scalability limits to Bitbucket!

Mercurial performance were also compared to the Git ones in details for several operations.

A check list that compared the current status of the NetBSD VCS migration to the FreeBSD VCS wiki one was described and then Jörg discussed the pending work and answered several questions in the Q&A.

For more information please give a look to the joerg's presentation slides (HTML). If you would like to help for the VCS migration please also get in touch with him!

Afternoon discussions and dinner

After the lunch we had several non-scheduled discussions, some time for hacking, etc. We then had a nice dinner together (it was in a restaurant with a very nice waiter who always shouted after every order or after accidently dropping and crashing dishes!, yeah! That's probably a bit weird but I liked that attitude! and then did some sightseeing and had a beer together.

From left to right: uwe, bad, ast, leot, martin, abhinav, sborrill, alnsn, spz.

From left to right: uwe, bad, ast, christos, leot, martin, sborrill, alnsn, spz.

Saturday (23/09): First day of conference session and Social Event

A Modern Replacement for BSD spell(1) -- Abhinav Upadhyay (abhinav)

Abhinav (abhinav) presented his work on the new spell(1) implementation he's working (that isn't just a spell replacement but also a library that can be used by other programs!).

He described the current limitations of old spell(1) (to get an idea please give a look to bin/48684), described the project goals of the new spell(1), additions to /usr/share/dict/words, digged a bit in the implementation and discussed several algorithms used and then provided a performance comparison with other popular free software spell checkers (aspell, hunspell and ispell).

He also showed an interactive demo of the new spell(1) in-action integrated with a shell for auto-completion and spell check.

If you would like to try it please give a look to nbspell Git repository that contains the code and dicts for the new spell(1)!

Video recording (YouTube) of the talk and slides (PDF) are also available!

Portable Hotplugging: NetBSD's uvm_hotplug(9) API development -- Cherry G. Mathew (cherry)

Cherry (cherry) presented recent work done with Santhosh N. Raju (fox) about uvm_hotplug(9).

The talk covered most "behind the scenes" work: how TDD (test driven development) was used, how uvm_hotplug(9) was designed and implemented (with comparisons to the old implementation), interesting edge cases during the development and how atf(7) was used to do performance testing.

It was very interesting to learn how Cherry and Santhosh worked on that and on the conclusion Cherry pointed out the importance of using existing Software Engineering techniques in Systems Programming.

Video recording (YouTube) and slides (PDF) of the talk are also available!

Hardening pkgsrc -- Pierre Pronchery (khorben)

Pierre (khorben) presented a talk about recent pkgsrc security features added in the recent months (and most of them also active on the just released pkgsrc-2017Q3!).

He first introduced how security management and releng is handled in pkgsrc, how to use pkg_admin(1) fetch-pkg-vulnerabilities and audit commands, etc.

Then package signatures (generation, installation) and recent hardening features in pkgsrc were discussed in details, first introducing them and then how pkgsrc handles them:

• SSP: Stack Smashing Protection (enabled via PKGSRC_USE_SSP in mk.conf)
• Fortify (enabled via PKGSRC_USE_FORTIFY in mk.conf)
• Stack check (enabled via PKGSRC_USE_STACK_CHECK in mk.conf)
• Position-Independent Executables (PIE) (enabled via PKGSRC_MKPIE in mk.conf)
• RELRO and BIND_NOW (enabled via PKGSRC_USE_RELRO in mk.conf)

Challenges for each hardening features and future works were discussed.

For more information video recording (YouTube) and slides (PDF) of the talk are available. A good introduction and reference for all pkgsrc hardening features is the Hardening packages wiki page.

Reproducible builds on NetBSD -- Christos Zoulas (christos)

Christos (christos) presented the work about reproducible builds on NetBSD.

In his talk he first provided a rationale about reproducible builds (to learn more please give a look to reproducible-builds.org!), he then discussed about the NetBSD (cross) build process, the current status and build variations that are done in the tests.reproducible-builds.org build machines.

Then he provided and described several sources of difference that were present in non-reproducible builds, like file-system timestamps, parallel builds headaches due directory/build order, path normalization, etc. For each of them he also discussed in details how these problems were solved in NetBSD.

In the conclusion the status and possible TODOs were also discussed (please note that both -current and -8 are all built with reproducible flags (-P option of build.sh)!)

Video recording (YouTube) of Christos' talk is available. Apart the resources discussed above a nice introduction to reproducible builds in NetBSD is also the NetBSD fully reproducible builds blog post written by Christos last February!

Social event

The social event on Saturday evening took place on a boat that cruised on the Seine river.

It was a very nice and different way to sightsee Paris, eat and enjoy some drinks and socialize and discuss with other developers and community.

Sunday (24/09): Second day of conference session

The school of hard knocks - PT1 -- Sevan Janiyan (sevan)

Sevan (sevan) presented a talk about several notes and lessons learnt whilst running tutorials to introduce NetBSD at several events (OSHUG #46 and OSHUG #57 and #58) and experiences from past events (Chiphack 2013).

He described problems a user may experience and how NetBSD was introduced, in particular trying to avoid the steep learning curve involved when experimenting with operating systems as a first step, exploring documentation/source code, cross-building, scripting in high-level programming languages (Lua) and directly prototyping and getting pragmatic via rump.

Video recording (YouTube) of Sevan's talk and slides (HTML) are available.

The LLDB Debugger on NetBSD -- Kamil Rytarowski (kamil)

Kamil (kamil) presented a talk about the recent LLDB debugger and a lot of other related debuggers (but also non-strictly-related-to-debugging!) works he's doing in the last months.

He first introduced debugging concepts in general, provided several examples and then he started discussing LLDB porting to NetBSD.

He then discussed about ptrace(2) and other introspection interfaces, the several improvements done and tests added for ptrace(2) in atf(7).

He also discussed about tracking LLDB's trunk (if you are more curious please give a look to wip/llvm-git, wip/clang-git, wip/lldb-git packages in pkgsrc-wip!) and about LLVM sanitizers and their current status in NetBSD.

In the conclusion he also discussed various TODOs in these areas.

Video recording (YouTube) and slides (HTML) of Kamil's talk are available. Kamil also regularly write status update blog posts on blog.NetBSD.org and tech-toolchain@ mailing list, so please stay tuned!

What's in store for NetBSD 8.0? -- Alistair Crooks (agc)

Alistair (agc) presented a talk about what we will see in NetBSD 8.0.

He discussed about new hardware supported (really "new", not new "old" hardware! Of course also support for VAXstation 4000 TURBOchannel USB and GPIO is actually new hardware as well! :)), LLVM/Clang, virtualization, PGP signing, updated utilities in NetBSD, new networking features (e.g. bouyer's sockcan implementation), u-boot, dtrace(1), improvements and new ports testing, reproducible builds, FDT (Flattened Device Tree) and a lot of other news!

The entire presentation was done using the Socratic method (Q&A) and it was very interactive and nice!

Video recording (YouTube) and slides (PDF) of Alistair's talk are available.

Sunday dinner

After the conference we did some sightseeing in Paris, had a dinner together and then enjoyed some beers!

On the left side: abhinav, ast, seb, christos
On the right side: leot, Riastradh, uwe, sevan, agc, sborrill

On the left side: martin, ast, seb, christos
On the right side: leot, Riastradh, uwe, sevan, agc, sborrill

Conclusion

It was a very nice weekend and conference. It is worth to mention that EuroBSDcon 2017 was the biggest BSD conference (more than 300 people attended it!).

I would like to thank the entire EuroBSDcon organising committee (Baptiste Daroussin, Antoine Jacoutot, Jean-Sébastien Pédron and Jean-Yves Migeon), EuroBSDcon programme commitee (Antoine Jacoutot, Lars Engels, Ollivier Robert, Sevan Janiyan, Jörg Sonnenberger, Jasper Lievisse Adriaanse and Janne Johansson) and EuroBSDcon Foundation for organizing such a wonderful conference!

I also would like to thank the speakers for presenting very interesting talks, all developers and community that attended the NetBSD devsummit and conference, in particular Jean-Yves and Jörg, for organizing and moderating the devsummit and Arolla that kindly hosted us for the NetBSD devsummit!

A special thanks also to Abhinav (abhinav) and Martin (martin) for photographs and locals Jean-Yves (jym) and Stoned (seb) for helping us in not get lost in Paris' rues!

Thank you!

Let me tell you about my experience at EuroBSDcon 2017 in Paris, France. We will see what was presented during the NetBSD developer summit on Friday and then we will give a look to all of the NetBSD and pkgsrc presentations given during the conference session on Saturday and Sunday. Of course, a lot of fun also happened on the "hall track", the several breaks during the conference and the dinners we had together with other *BSD developers and community! This is difficult to describe and I will try to just share some part of that with photographs that we have taken. I can just say that it was a really beautiful experience, I had a great time with others and, after coming back home... ...I miss all of that! So, if you have never been in any BSD conferences I strongly suggest you to go to the next ones, so please stay tuned via NetBSD Events. Being there this is probably the only way to understand these feelings!

Thursday (21/09): NetBSD developers dinner

Arriving in Paris via a night train from Italy I literally sleep-walked through Paris getting lost again and again. After getting in touch with other developers we had a dinner together and went sightseeing for a^Wseveral beers!

Friday (22/09): NetBSD developers summit

On Friday morning we met for the NetBSD developers summit kindly hosted by Arolla.

From left to right: alnsn, sborrill; abhinav; uwe and leot; christos, cherry, ast and bsiegert; martin and khorben.

The devsummit was moderated by Jörg (joerg) and organized by Jean-Yves (jym).

NetBSD on Google Compute Engine -- Benny Siegert (bsiegert)

After a self-presentation the devsummit presentations session started with the talk presented by Benny (bsiegert) about NetBSD on Google Compute Engine.

Benny first introduced Google Compute Engine (GCE) and then started describing how to run NetBSD on it.

At the moment there are no official NetBSD images and so users need to create their own. However, netbsd-gce script completely automatize this process that:

• uses Anita to stage an installation in QEMU
• adjust several tweaks to ensure that networking and storage will work on GCE
• packs the image into a .tar.gz file

The .tar.gz image then just need to be uploaded to a Cloud Storage bucket, create a GCE image from it and then launch VMs based on that image.

He also discussed about GCE instance metadata, several problems founds and how they were fixed (it's better to use NetBSD 8_BETA or -current!) and some future works.

For more information slides (PDF) of the talk are also available.

Scripting DDB with Forth -- Valery Ushakov (uwe)

Valery (uwe) presented a talk about Scripting DDB with Forth. It was based on a long story and actually the first discussion about it appeared on tech-kern@ mailing list in his Scripting DDB in Forth? thread (ddb(4) is the NetBSD in-kernel debugger).

He showed how one can associate forth commands/conditions with ddb breakpoints. He used "pid divisible by 3" as an example of condition for a breakpoint set in getpid(2) system call:

db{0}> forth
ok : field   create , does> @ + ;
ok #300 field lwp>l_proc
ok #120 field proc>p_pid
ok : getpid   curlwp lwp>l_proc @ proc>p_pid @ ;
ok : checkpid   getpid dup ." > PID IS " . cr   3 mod 0= ;
ok bye
-- STACK: <empty>
db{0}> break sys_getpid_with_ppid
db{0}> command . = checkpid
db{0}> c

...and then on a shell:

# (:)
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip 0xc090df89 cs 0x8 eflags 0x246 cr2 0xad8ef2c0 ilevel 0 esp 0xc0157fbd
curlwp 0xc2b5c2c0 pid 798 lid 1 lowest kstack 0xdabb42c0
> PID IS 798
-- STACK:
0xffffffff   -1
Breakpoint in pid 798.1 (ksh) at        netbsd:sys_getpid_with_ppid: pushl %ebp
db{0}> c
# (:)
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip 0xc090df89 cs 0x8 eflags 0x246 cr2 0xad8ef2c0 ilevel 0 esp 0xc0157fbd
curlwp 0xc2b5c2c0 pid 823 lid 1 lowest kstack 0xdabb42c0
> PID IS 823
-- STACK:
0x00000000  0
Command returned 0
# 

If you are more interested in this presentation I strongly suggest to also give a look to uwe's forth Mercurial repository.

News from the version control front -- Jörg Sonnenberger (joerg)

The third presentation of the devsummit was a presentation about the recent work done by Jörg (joerg) in the VCS conversions.

Jörg started the presentation discussing about the infrastructure used for the CVS -> Fossil -> Git conversion and CVS -> Fossil -> Mercurial conversion.

It's worth also noticing that the Mercurial conversion is fully integrated and is regularly pushed to Bitbucket and src repository pushed some scalability limits to Bitbucket!

Mercurial performance were also compared to the Git ones in details for several operations.

A check list that compared the current status of the NetBSD VCS migration to the FreeBSD VCS wiki one was described and then Jörg discussed the pending work and answered several questions in the Q&A.

For more information please give a look to the joerg's presentation slides (HTML). If you would like to help for the VCS migration please also get in touch with him!

Afternoon discussions and dinner

After the lunch we had several non-scheduled discussions, some time for hacking, etc. We then had a nice dinner together (it was in a restaurant with a very nice waiter who always shouted after every order or after accidently dropping and crashing dishes!, yeah! That's probably a bit weird but I liked that attitude! and then did some sightseeing and had a beer together.

From left to right: uwe, bad, ast, leot, martin, abhinav, sborrill, alnsn, spz.

From left to right: uwe, bad, ast, christos, leot, martin, sborrill, alnsn, spz.

Saturday (23/09): First day of conference session and Social Event

A Modern Replacement for BSD spell(1) -- Abhinav Upadhyay (abhinav)

Abhinav (abhinav) presented his work on the new spell(1) implementation he's working (that isn't just a spell replacement but also a library that can be used by other programs!).

He described the current limitations of old spell(1) (to get an idea please give a look to bin/48684), described the project goals of the new spell(1), additions to /usr/share/dict/words, digged a bit in the implementation and discussed several algorithms used and then provided a performance comparison with other popular free software spell checkers (aspell, hunspell and ispell).

He also showed an interactive demo of the new spell(1) in-action integrated with a shell for auto-completion and spell check.

If you would like to try it please give a look to nbspell Git repository that contains the code and dicts for the new spell(1)!

Video recording (YouTube) of the talk and slides (PDF) are also available!

Portable Hotplugging: NetBSD's uvm_hotplug(9) API development -- Cherry G. Mathew (cherry)

Cherry (cherry) presented recent work done with Santhosh N. Raju (fox) about uvm_hotplug(9).

The talk covered most "behind the scenes" work: how TDD (test driven development) was used, how uvm_hotplug(9) was designed and implemented (with comparisons to the old implementation), interesting edge cases during the development and how atf(7) was used to do performance testing.

It was very interesting to learn how Cherry and Santhosh worked on that and on the conclusion Cherry pointed out the importance of using existing Software Engineering techniques in Systems Programming.

Video recording (YouTube) and slides (PDF) of the talk are also available!

Hardening pkgsrc -- Pierre Pronchery (khorben)

Pierre (khorben) presented a talk about recent pkgsrc security features added in the recent months (and most of them also active on the just released pkgsrc-2017Q3!).

He first introduced how security management and releng is handled in pkgsrc, how to use pkg_admin(1) fetch-pkg-vulnerabilities and audit commands, etc.

Then package signatures (generation, installation) and recent hardening features in pkgsrc were discussed in details, first introducing them and then how pkgsrc handles them:

• SSP: Stack Smashing Protection (enabled via PKGSRC_USE_SSP in mk.conf)
• Fortify (enabled via PKGSRC_USE_FORTIFY in mk.conf)
• Stack check (enabled via PKGSRC_USE_STACK_CHECK in mk.conf)
• Position-Independent Executables (PIE) (enabled via PKGSRC_MKPIE in mk.conf)
• RELRO and BIND_NOW (enabled via PKGSRC_USE_RELRO in mk.conf)

Challenges for each hardening features and future works were discussed.

For more information video recording (YouTube) and slides (PDF) of the talk are available. A good introduction and reference for all pkgsrc hardening features is the Hardening packages wiki page.

Reproducible builds on NetBSD -- Christos Zoulas (christos)

Christos (christos) presented the work about reproducible builds on NetBSD.

In his talk he first provided a rationale about reproducible builds (to learn more please give a look to reproducible-builds.org!), he then discussed about the NetBSD (cross) build process, the current status and build variations that are done in the tests.reproducible-builds.org build machines.

Then he provided and described several sources of difference that were present in non-reproducible builds, like file-system timestamps, parallel builds headaches due directory/build order, path normalization, etc. For each of them he also discussed in details how these problems were solved in NetBSD.

In the conclusion the status and possible TODOs were also discussed (please note that both -current and -8 are all built with reproducible flags (-P option of build.sh)!)

Video recording (YouTube) of Christos' talk is available. Apart the resources discussed above a nice introduction to reproducible builds in NetBSD is also the NetBSD fully reproducible builds blog post written by Christos last February!

Social event

The social event on Saturday evening took place on a boat that cruised on the Seine river.

It was a very nice and different way to sightsee Paris, eat and enjoy some drinks and socialize and discuss with other developers and community.

Sunday (24/09): Second day of conference session

The school of hard knocks - PT1 -- Sevan Janiyan (sevan)

Sevan (sevan) presented a talk about several notes and lessons learnt whilst running tutorials to introduce NetBSD at several events (OSHUG #46 and OSHUG #57 and #58) and experiences from past events (Chiphack 2013).

He described problems a user may experience and how NetBSD was introduced, in particular trying to avoid the steep learning curve involved when experimenting with operating systems as a first step, exploring documentation/source code, cross-building, scripting in high-level programming languages (Lua) and directly prototyping and getting pragmatic via rump.

Video recording (YouTube) of Sevan's talk and slides (HTML) are available.

The LLDB Debugger on NetBSD -- Kamil Rytarowski (kamil)

Kamil (kamil) presented a talk about the recent LLDB debugger and a lot of other related debuggers (but also non-strictly-related-to-debugging!) works he's doing in the last months.

He first introduced debugging concepts in general, provided several examples and then he started discussing LLDB porting to NetBSD.

He then discussed about ptrace(2) and other introspection interfaces, the several improvements done and tests added for ptrace(2) in atf(7).

He also discussed about tracking LLDB's trunk (if you are more curious please give a look to wip/llvm-git, wip/clang-git, wip/lldb-git packages in pkgsrc-wip!) and about LLVM sanitizers and their current status in NetBSD.

In the conclusion he also discussed various TODOs in these areas.

Video recording (YouTube) and slides (HTML) of Kamil's talk are available. Kamil also regularly write status update blog posts on blog.NetBSD.org and tech-toolchain@ mailing list, so please stay tuned!

What's in store for NetBSD 8.0? -- Alistair Crooks (agc)

Alistair (agc) presented a talk about what we will see in NetBSD 8.0.

He discussed about new hardware supported (really "new", not new "old" hardware! Of course also support for VAXstation 4000 TURBOchannel USB and GPIO is actually new hardware as well! :)), LLVM/Clang, virtualization, PGP signing, updated utilities in NetBSD, new networking features (e.g. bouyer's sockcan implementation), u-boot, dtrace(1), improvements and new ports testing, reproducible builds, FDT (Flattened Device Tree) and a lot of other news!

The entire presentation was done using the Socratic method (Q&A) and it was very interactive and nice!

Video recording (YouTube) and slides (PDF) of Alistair's talk are available.

Sunday dinner

After the conference we did some sightseeing in Paris, had a dinner together and then enjoyed some beers!

On the left side: abhinav, ast, seb, christos
On the right side: leot, Riastradh, uwe, sevan, agc, sborrill

On the left side: martin, ast, seb, christos
On the right side: leot, Riastradh, uwe, sevan, agc, sborrill

Conclusion

It was a very nice weekend and conference. It is worth to mention that EuroBSDcon 2017 was the biggest BSD conference (more than 300 people attended it!).

I would like to thank the entire EuroBSDcon organising committee (Baptiste Daroussin, Antoine Jacoutot, Jean-Sébastien Pédron and Jean-Yves Migeon), EuroBSDcon programme commitee (Antoine Jacoutot, Lars Engels, Ollivier Robert, Sevan Janiyan, Jörg Sonnenberger, Jasper Lievisse Adriaanse and Janne Johansson) and EuroBSDcon Foundation for organizing such a wonderful conference!

I also would like to thank the speakers for presenting very interesting talks, all developers and community that attended the NetBSD devsummit and conference, in particular Jean-Yves and Jörg, for organizing and moderating the devsummit and Arolla that kindly hosted us for the NetBSD devsummit!

A special thanks also to Abhinav (abhinav) and Martin (martin) for photographs and locals Jean-Yves (jym) and Stoned (seb) for helping us in not get lost in Paris' rues!

Thank you!

Recently, I completed a Kernel ASLR implementation for NetBSD-amd64, making NetBSD the first BSD system to support such a feature. Simply said, KASLR is a feature that randomizes the location of the kernel in memory, making it harder to exploit several classes of vulnerabilities, both locally (privilege escalations) and remotely (remote code executions).

Current design

The current design is based on a specialized kernel called the "prekern", which operates between the bootloader and the kernel itself. The kernel is compiled as a raw library with the GENERIC_KASLR configuration file, while the prekern is compiled as a static binary. When the machine boots, the bootloader jumps into the prekern. The prekern relocates the kernel at a random virtual address (VA), and jumps into it. Finally, the kernel performs some cleanup, and executes normally.

Currently, the kernel is randomized as a single block. That is to say, a random VA is chosen, and the kernel text->rodata->data sections are mapped contiguously starting from there. It has several drawbacks, but it's a first shot.

To complete this implementation, work had to be done at three levels: the bootloader, the prekern and the kernel. I committed several of the kernel and bootloader patches discreetly a few months ago, to pave some way for real changes. In the past few weeks, I changed the low-level x86 layer of the kernel and replaced several hard-coded (and sometimes magic) values by variables, in such a way that the kernel can run with a non-static memory layout. Finally, the last step was committing the prekern itself to the source tree.

Future work

• Randomize the kernel sections independently, and intertwine them.
• Modify several kernel entry points not to leak kernel addresses to userland.
• Randomize the kernel heap too (which is still static for now).
• Fix a few other things that need some more work.

How to use

All of the patches are now in NetBSD-current. Instructions on how to install and use this implementation can be found here; they are inlined below, and probably won't change in the future.

Make sure you have a v5.11 bootloader installed. If you don't, build and install a new bootloader:

    $ cd /usr/src/sys/arch/i386/stand/boot
    $ make
    # cp biosboot/boot /

Build and install a KASLR kernel:

    $ cd /usr/src
    $ ./build.sh -u kernel=GENERIC_KASLR
    # cp /usr/obj/sys/arch/amd64/compile/GENERIC_KASLR/netbsd /netbsd_kaslr

Finally, build and install a prekern:

    $ cd /usr/src/sys/arch/amd64/stand/prekern
    $ make
    # cp prekern /prekern

Reboot your machine. In the boot prompt, enter:

    > pkboot netbsd_kaslr

The system will boot with no further user interaction. Should you encounter any regression or unexpected behavior, please report it immediately to tech-kern.

Note that you can still boot a static kernel, by typing as usual:

    > boot netbsd

Availability

This KASLR implementation will be available starting from NetBSD 9. Once it is stabilized, it may be backported to NetBSD 8. Until then, feel free to test it!

Recently, I completed a Kernel ASLR implementation for NetBSD-amd64, making NetBSD the first BSD system to support such a feature. Simply said, KASLR is a feature that randomizes the location of the kernel in memory, making it harder to exploit several classes of vulnerabilities, both locally (privilege escalations) and remotely (remote code executions).

Current design

The current design is based on a specialized kernel called the "prekern", which operates between the bootloader and the kernel itself. The kernel is compiled as a raw library with the GENERIC_KASLR configuration file, while the prekern is compiled as a static binary. When the machine boots, the bootloader jumps into the prekern. The prekern relocates the kernel at a random virtual address (VA), and jumps into it. Finally, the kernel performs some cleanup, and executes normally.

Currently, the kernel is randomized as a single block. That is to say, a random VA is chosen, and the kernel text->rodata->data sections are mapped contiguously starting from there. It has several drawbacks, but it's a first shot.

To complete this implementation, work had to be done at three levels: the bootloader, the prekern and the kernel. I committed several of the kernel and bootloader patches discreetly a few months ago, to pave some way for real changes. In the past few weeks, I changed the low-level x86 layer of the kernel and replaced several hard-coded (and sometimes magic) values by variables, in such a way that the kernel can run with a non-static memory layout. Finally, the last step was committing the prekern itself to the source tree.

Future work

• Randomize the kernel sections independently, and intertwine them.
• Modify several kernel entry points not to leak kernel addresses to userland.
• Randomize the kernel heap too (which is still static for now).
• Fix a few other things that need some more work.

How to use

All of the patches are now in NetBSD-current. Instructions on how to install and use this implementation can be found here; they are inlined below, and probably won't change in the future.

Make sure you have a v5.11 bootloader installed. If you don't, build and install a new bootloader:

    $ cd /usr/src/sys/arch/i386/stand/boot
    $ make
    # cp biosboot/boot /

Build and install a KASLR kernel:

    $ cd /usr/src
    $ ./build.sh -u kernel=GENERIC_KASLR
    # cp /usr/obj/sys/arch/amd64/compile/GENERIC_KASLR/netbsd /netbsd_kaslr

Finally, build and install a prekern:

    $ cd /usr/src/sys/arch/amd64/stand/prekern
    $ make
    # cp prekern /prekern

Reboot your machine. In the boot prompt, enter:

    > pkboot netbsd_kaslr

The system will boot with no further user interaction. Should you encounter any regression or unexpected behavior, please report it immediately to tech-kern.

Note that you can still boot a static kernel, by typing as usual:

    > boot netbsd

Availability

This KASLR implementation will be available starting from NetBSD 9. Once it is stabilized, it may be backported to NetBSD 8. Until then, feel free to test it!

NetBSD participated in the 2017 edition of Google of Summer of Code with 3 students. All of the students finished their projects successfully. The following links report about their activities:

• Leonardo Taccari: Add multi-packages support to pkgsrc
• Maya Rashish: LFS cleanup
• Utkarsh Anand: Make Anita support multiple virtual machine systems

Congratulations to the students for finishing their projects successfully, and thanks to Google for sponsoring!

NetBSD participated in the 2017 edition of Google of Summer of Code with 3 students. All of the students finished their projects successfully. The following links report about their activities:

• Leonardo Taccari: Add multi-packages support to pkgsrc
• Maya Rashish: LFS cleanup
• Utkarsh Anand: Make Anita support multiple virtual machine systems

Congratulations to the students for finishing their projects successfully, and thanks to Google for sponsoring!

Please join us in welcoming the new Directors to the NetBSD Foundation Board:

Michael van Elst, Taylor R. Campbell, Thomas Klausner

We'd like to sincerely thank the departing board members for their service during their term:

Matthew Sporleder, SAITOH Masanobu, Christos Zoulas

Christos will be remaining as Secretary and Treasurer for the Foundation.


Your 2016-2017 Directors of the Foundation are:

Erik Berls
Taylor R. Campbell
William J. Coldwell
Michael van Elst
Thomas Klausner
Jeremy C. Reed
S. P. Zeidler

The current office holders of the Foundation are:

President: William J. Coldwell
Vice President: Jeremy C. Reed
Secretary: Christos Zoulas
Treasurer: Christos Zoulas

Thank you to all of the developers that nominated and voted, the NomCom, the Voting Administrator and Voting Validator.

Respectfully submitted for the Board of Directors,
William J. Coldwell

Please join us in welcoming the new Directors to the NetBSD Foundation Board:

Michael van Elst, Taylor R. Campbell, Thomas Klausner

We'd like to sincerely thank the departing board members for their service during their term:

Matthew Sporleder, SAITOH Masanobu, Christos Zoulas

Christos will be remaining as Secretary and Treasurer for the Foundation.


Your 2016-2017 Directors of the Foundation are:

Erik Berls
Taylor R. Campbell
William J. Coldwell
Michael van Elst
Thomas Klausner
Jeremy C. Reed
S. P. Zeidler

The current office holders of the Foundation are:

President: William J. Coldwell
Vice President: Jeremy C. Reed
Secretary: Christos Zoulas
Treasurer: Christos Zoulas

Thank you to all of the developers that nominated and voted, the NomCom, the Voting Administrator and Voting Validator.

Respectfully submitted for the Board of Directors,
William J. Coldwell

Greetings,


The NetBSD Foundation has initiated a contract with Kamil Rytarowski
 to complete the following during it:

   1.  Add missing interfaces in ptrace(2), mostly sync it with
       the FreeBSD capabilities, add ATF tests, add documentation.

   2.  Develop process plugin in LLDB based on the FreeBSD code in
       LLDB and make it functional (start passing at least some tests).

   3.  Revamp the process plugin in LLDB for new remote debugging
       capabilities (in order to get it accepted and merged upstream),
       pass more tests.

   4.  LLDB x86 support, pass more of the standard LLDB tests
       and import LLDB to the NetBSD base. Add some ATF LLDB basic
       functionality tests to the tree. The original tests are
       unreliable and generate false positives.

   5.  Develop missing features needed for .NET (POSIX robust
       mutexes), add ATF tests.

   6.  Develop missing features for VirtualBox as host, including
       needing sigevent(2) on par with POSIX and SIGEV_KEVENT, and
       other real-time AIO related interfaces as needed.

   7.  Port Apple's Swift programming language. Enhance .NET port to
       validate new interface and correct more issues as needed.

   8.  Improve VirtualBox host support. Make it build first by disabling
       missing features of providing empty facades for them.

   9.  Implement CDROM, floppy, NIC support for NetBSD in VBox as host.

  10.  Make VirtualBox runnable at least with a restricted feature set, ship
        it in pkgsrc, and submit it upstream.


The NetBSD Foundation will continue to work diligently with the
community to fund projects furthering specific key and quality
improvements to the NetBSD projects.  We have a list of projects at
http://wiki.netbsd.org/projects/ as well as welcome other proposals
to move our flag forward to next releases!

Thank you to Kamil for committing to it and we all look forward to it!

The NetBSD Foundation is a non-profit organization and welcomes any
donations to help us continue to fund projects and services to the
open-source community.  Please consider visiting the following URL,
and chip in what you can:

        http://netbsd.org/donations/#how-to-donate





            Submitted for The NetBSD Foundation,
                William J. Coldwell (billc@)
                President, Chairperson

20161012: edited to fix #10 to be the correct wording.

Greetings,


The NetBSD Foundation has initiated a contract with Kamil Rytarowski
 to complete the following during it:

   1.  Add missing interfaces in ptrace(2), mostly sync it with
       the FreeBSD capabilities, add ATF tests, add documentation.

   2.  Develop process plugin in LLDB based on the FreeBSD code in
       LLDB and make it functional (start passing at least some tests).

   3.  Revamp the process plugin in LLDB for new remote debugging
       capabilities (in order to get it accepted and merged upstream),
       pass more tests.

   4.  LLDB x86 support, pass more of the standard LLDB tests
       and import LLDB to the NetBSD base. Add some ATF LLDB basic
       functionality tests to the tree. The original tests are
       unreliable and generate false positives.

   5.  Develop missing features needed for .NET (POSIX robust
       mutexes), add ATF tests.

   6.  Develop missing features for VirtualBox as host, including
       needing sigevent(2) on par with POSIX and SIGEV_KEVENT, and
       other real-time AIO related interfaces as needed.

   7.  Port Apple's Swift programming language. Enhance .NET port to
       validate new interface and correct more issues as needed.

   8.  Improve VirtualBox host support. Make it build first by disabling
       missing features of providing empty facades for them.

   9.  Implement CDROM, floppy, NIC support for NetBSD in VBox as host.

  10.  Make VirtualBox runnable at least with a restricted feature set, ship
        it in pkgsrc, and submit it upstream.


The NetBSD Foundation will continue to work diligently with the
community to fund projects furthering specific key and quality
improvements to the NetBSD projects.  We have a list of projects at
http://wiki.netbsd.org/projects/ as well as welcome other proposals
to move our flag forward to next releases!

Thank you to Kamil for committing to it and we all look forward to it!

The NetBSD Foundation is a non-profit organization and welcomes any
donations to help us continue to fund projects and services to the
open-source community.  Please consider visiting the following URL,
and chip in what you can:

        http://netbsd.org/donations/#how-to-donate





            Submitted for The NetBSD Foundation,
                William J. Coldwell (billc@)
                President, Chairperson

20161012: edited to fix #10 to be the correct wording.

The NetBSD Project is pleased to announce NetBSD 7.0.2, the second security/bugfix update of the NetBSD 7.0 release branch. It represents a selected subset of fixes deemed important for security or stability reasons. If you are running an earlier release of NetBSD, we strongly suggest updating to 7.0.2.

For more details, please see the release notes.

Complete source and binaries for NetBSD are available for download at many sites around the world. A list of download sites providing FTP, AnonCVS, SUP, and other services may be found at http://www.NetBSD.org/mirrors/.

The NetBSD Project is pleased to announce NetBSD 7.0.2, the second security/bugfix update of the NetBSD 7.0 release branch. It represents a selected subset of fixes deemed important for security or stability reasons. If you are running an earlier release of NetBSD, we strongly suggest updating to 7.0.2.

For more details, please see the release notes.

Complete source and binaries for NetBSD are available for download at many sites around the world. A list of download sites providing FTP, AnonCVS, SUP, and other services may be found at http://www.NetBSD.org/mirrors/.

The NetBSD Project is pleased to announce NetBSD 6.1.5, the fifth security/bugfix update of the NetBSD 6.1 release branch, and NetBSD 6.0.6, the sixth security/bugfix update of the NetBSD 6.0 release branch. They represent a selected subset of fixes deemed important for security or stability reasons, and if you are running a prior release of either branch, we strongly suggest that you update to one of these releases.

For more details, please see the NetBSD 6.1.5 release notes or NetBSD 6.0.6 release notes.

Complete source and binaries for NetBSD are available for download at many sites around the world. A list of download sites providing FTP, AnonCVS, SUP, and other services may be found at http://www.NetBSD.org/mirrors/.

The following report is by Manuel Wiesinger:

First of all, I like to thank the NetBSD Foundation for enabling me to successfully complete this Google Summer of Code. It has been a very valuable experience for me.

My project is a defragmentation tool for FFS. I want to point out at the beginning that it is not ready for use yet.

What has been done:

Fragment analysis + reordering. When a file is smaller or equal than the file system's fragment size, it is stored as a fragment. One can think of a fragment as a block. It can happen that there are many small files that occupy a fragment. When the file systems changes over time it can happen that there are many blocks containing fewer fragments than they can hold. The optimization my tool does is to pack all these fragments into fewer blocks. This way the system may get a little more free space.

Directory optimization. When a directory gets deleted, the space for that directory and its name are appended to the previous directory. This can be imagined like a linked list. My tool reads that list and writes all entries sequentially.

Non-contiguous files analysis + reordering strategy. This is what most other operating systems call defragmentation - a reordering of blocks, so that blocks belonging to the same file or directory can be read sequentially.

What did not work as expected

Testing: I thought that it is the most productive and stable to work with unit tests. Strictly test driven development. It was not really effective to play around with rump/atf. Although I always started a new implementation step by generating a file system in a state where it can be optimized. So I wrote the scripts, took a look if they did what I intended (of course, they did not always).

I'm a bit disappointed about the amount of code. But as I said before, the hardest part is to figure out how things work. The amount it does is relatively much, I expected more lines of code to be needed to get where I am now.

Before applying for this project, I took a close look at UFS. But it was not close enough. There were many surprises. E.g. I had no idea that there are gaps in files on purpose, to exploit the rotation of hard disks.

Time management, everything took longer than I expected. Mostly because it was really hard to figure out how things work. Lacking documentation is a huge problem too.

Things I learned

A huge lesson learned in software engineering. It is always different than expected, if you do not have a lot of experience.

I feel more confident to read and patch kernel code. All my previous experiences were not so in-depth. (e.g., I worked with pintos). The (mental) barrier of kernel/system programming is gone. For example I see a chance now to take a look on ACPI, and see if I can write a patch to get suspend working on my notebook.

I got more contact with the NetBSD community, and got a nice overview how things work. The BSD community here is very mixed. There are not many NetBSD people.

CVS is better than most of my friends say.

I learned about pkgsrc, UVM, and other smaller things about NetBSD too, but that's not worth mentioning in detail.

How I intend to continue:

After a sanity break, of the whole project, there are several possibilities.

In the next days I will speak to a supervisor at my university, if I can continue the project as a project thesis (I still need to do one). It may even include online defragmentation, based on snapshots. That's my preferred option.

I definitely want to finish this project, since I spent so much time and effort. It would be a shame otherwise.

What there is to do technically

Once the defragmentation works, given enough space to move a file. I want to find a way where you can defragment it even when there is too little space. This can be achieved by simply moving blocks piece by piece, and use the files' space as 'free space'.

Online defragmentation. I already skimmed hot snapshots work. It should be possible.

Improve the tests.

It should be easy to get this compiling on older releases. Currently it compiles only on -current.

Eventually it's worth it to port the tests to atf/rump on the long run.

Conclusion

I will continue to work, and definitely continue to use and play with NetBSD!

It's a stupid thing that a defrag tool is worth little (nothing?) on SSDs. But since NetBSD is designed to run on (almost) any hardware, this does not bug me a lot.

Thank you NetBSD! Although it was a lot of hard work. It was a lot of fun!

Manuel Wiesinger

This month I've finally finished upstreaming NetBSD support in ASan and UBsan. For better coverage of the sanitizers and on user request I've ported libFuzzer and SafeStack. There are mutual dependencies between the compiler-rt features. NetBSD after sorting out msan and tsan shall get all the remaining ones enabled. This is open topic after finishing LLDB. I have also prepared better ground for the coming work on ptrace(2) enhancements with the removal of the filesystem tracing (/proc/#/ctl).

LLVM

The majority of the work has been done in the LLVM projects.

The developed features are not production ready and they will need productization in the future. There are still issues with paths mismatch ("netbsd" vs "netbsd8.99" vs "netbsd8.99.1") when looking for NetBSD specific support for the compiler-rt features. There is also a need for integration with pkgsrc, as not everything behaves sanely (conflicts with wrappers). The tools are also restricted to be built with the Clang compiler, as GCC support is currently broken. I also noted that the sanitizers behave wrongly in the standalone build (out of the LLVM sources).

I expect to sort out the mentioned problems after finishing LLDB.

LLVM JIT

There is ongoing discussion with the LLVM community about new JIT API that will be compatible with NetBSD PaX MPROTECT. There have been developed and introduced cleanups in the code (like better error handling templates) in order to prepare a draft of new API.

ASAN

All local code for ASan has been merged upstream. This includes NetBSD patches in LLVM, Clang and compiler-rt.

All but two (one on i386 version and the other on amd64) tests (check-asan) pass.

UBSAN

Similarly to ASan, UBsan has been fully upstreamed. All tests (check-ubsan) pass.

SafeStack

SafeStack is a software security hardening technique that creates two stacks: one for data that needs to be kept safe, such as return addresses and function pointers; and an unsafe stack for everything else.

With PaX ASLR (Address Space Layout Randomization) and PaX MPROTECT (mprotect(2) restrictions) SafeStack is an excellent candidate for inclusion in pkgsrc.

Core programs could be hardened as well, but the shortcoming of SafeStack for basesystem utilities is pulling in additional dependencies like libpthread on every executable.

Using SafeStack adds marginal overhead.

libFuzzer

Citing the project page, LibFuzzer is an in-process, coverage-guided, evolutionary fuzzing engine.

LibFuzzer is linked with the library under test, and feeds fuzzed inputs to the library via a specific fuzzing entry point (aka 'target function'); the fuzzer then tracks which areas of the code are reached, and generates mutations on the corpus of input data in order to maximize the code coverage. The code coverage information for libFuzzer is provided by LLVM's SanitizerCoverage instrumentation.

This functionality still requires more sanitizers to get aboard and is now of restricted functionality.

TSAN

Part of the TSan code has been upstreamed. However, a functional port isn't finished yet.

The current issues are: proper process memory map handling and NetBSD specific setjmp(3)-like functions support.

LSAN

I was also working on LSan. This sanitizer already builds and appears to be quite completed, however there is work needed for the implementation of StopTheWorld() function to self-introspect the process and threads. I'm researching a new kernel API for this purpose, but it might wait till the end of LLDB porting.

MSAN

So far I have not been working on the MSan specific bits. The majority of the code has been upstreamed for this sanitizer in the common sanitizer framework, the proper handling of the NetBSD specific process map is still to be done.

PROFILE

The profile library is used to collect coverage information. It already passes most of the tests, however it's not turned on, as upstream requested additional time to be spent on the issues and it's not a priority right now.

NetBSD kernel

I've removed the filesystem tracing feature.

This is a legacy interface from 4.4BSD, and it was introduced to overcome shortcomings of ptrace(2) at that time, which are no longer relevant (performance). Today /proc/#/ctl offers a narrow subset of ptrace(2) commands and is not applicable for modern applications use beyond simplistic tracing scenarios.

This removal simplified kernel internals. Users are still able to use all the other /proc files.

This change doesn't affect other procfs files and Linux compat features within mount_procfs(8). /proc/#/ctl isn't available on Linux.

Plan for the next milestone

This month I will not work on a new development and I will focus on relax and taking part in EuroBSDCon in Paris. I will speak about the LLDB porting to NetBSD.

Long-term goals are finishing the basis sanitizers (msan, tsan) and switching back to LLDB porting. The sanitizers will be used to develop and debug the LLVM debugger. There is also integration with sanitizers in LLDB.

This work was sponsored by The NetBSD Foundation.

The NetBSD Foundation is a non-profit organization and welcomes any donations to help us continue funding projects and services to the open-source community. Please consider visiting the following URL, and chip in what you can:

http://netbsd.org/donations/#how-to-donate

This month I've finally finished upstreaming NetBSD support in ASan and UBsan. For better coverage of the sanitizers and on user request I've ported libFuzzer and SafeStack. There are mutual dependencies between the compiler-rt features. NetBSD after sorting out msan and tsan shall get all the remaining ones enabled. This is open topic after finishing LLDB. I have also prepared better ground for the coming work on ptrace(2) enhancements with the removal of the filesystem tracing (/proc/#/ctl).

LLVM

The majority of the work has been done in the LLVM projects.

The developed features are not production ready and they will need productization in the future. There are still issues with paths mismatch ("netbsd" vs "netbsd8.99" vs "netbsd8.99.1") when looking for NetBSD specific support for the compiler-rt features. There is also a need for integration with pkgsrc, as not everything behaves sanely (conflicts with wrappers). The tools are also restricted to be built with the Clang compiler, as GCC support is currently broken. I also noted that the sanitizers behave wrongly in the standalone build (out of the LLVM sources).

I expect to sort out the mentioned problems after finishing LLDB.

LLVM JIT

There is ongoing discussion with the LLVM community about new JIT API that will be compatible with NetBSD PaX MPROTECT. There have been developed and introduced cleanups in the code (like better error handling templates) in order to prepare a draft of new API.

ASAN

All local code for ASan has been merged upstream. This includes NetBSD patches in LLVM, Clang and compiler-rt.

All but two (one on i386 version and the other on amd64) tests (check-asan) pass.

UBSAN

Similarly to ASan, UBsan has been fully upstreamed. All tests (check-ubsan) pass.

SafeStack

SafeStack is a software security hardening technique that creates two stacks: one for data that needs to be kept safe, such as return addresses and function pointers; and an unsafe stack for everything else.

With PaX ASLR (Address Space Layout Randomization) and PaX MPROTECT (mprotect(2) restrictions) SafeStack is an excellent candidate for inclusion in pkgsrc.

Core programs could be hardened as well, but the shortcoming of SafeStack for basesystem utilities is pulling in additional dependencies like libpthread on every executable.

Using SafeStack adds marginal overhead.

libFuzzer

Citing the project page, LibFuzzer is an in-process, coverage-guided, evolutionary fuzzing engine.

LibFuzzer is linked with the library under test, and feeds fuzzed inputs to the library via a specific fuzzing entry point (aka 'target function'); the fuzzer then tracks which areas of the code are reached, and generates mutations on the corpus of input data in order to maximize the code coverage. The code coverage information for libFuzzer is provided by LLVM's SanitizerCoverage instrumentation.

This functionality still requires more sanitizers to get aboard and is now of restricted functionality.

TSAN

Part of the TSan code has been upstreamed. However, a functional port isn't finished yet.

The current issues are: proper process memory map handling and NetBSD specific setjmp(3)-like functions support.

LSAN

I was also working on LSan. This sanitizer already builds and appears to be quite completed, however there is work needed for the implementation of StopTheWorld() function to self-introspect the process and threads. I'm researching a new kernel API for this purpose, but it might wait till the end of LLDB porting.

MSAN

So far I have not been working on the MSan specific bits. The majority of the code has been upstreamed for this sanitizer in the common sanitizer framework, the proper handling of the NetBSD specific process map is still to be done.

PROFILE

The profile library is used to collect coverage information. It already passes most of the tests, however it's not turned on, as upstream requested additional time to be spent on the issues and it's not a priority right now.

NetBSD kernel

I've removed the filesystem tracing feature.

This is a legacy interface from 4.4BSD, and it was introduced to overcome shortcomings of ptrace(2) at that time, which are no longer relevant (performance). Today /proc/#/ctl offers a narrow subset of ptrace(2) commands and is not applicable for modern applications use beyond simplistic tracing scenarios.

This removal simplified kernel internals. Users are still able to use all the other /proc files.

This change doesn't affect other procfs files and Linux compat features within mount_procfs(8). /proc/#/ctl isn't available on Linux.

Plan for the next milestone

This month I will not work on a new development and I will focus on relax and taking part in EuroBSDCon in Paris. I will speak about the LLDB porting to NetBSD.

Long-term goals are finishing the basis sanitizers (msan, tsan) and switching back to LLDB porting. The sanitizers will be used to develop and debug the LLVM debugger. There is also integration with sanitizers in LLDB.

This work was sponsored by The NetBSD Foundation.

The NetBSD Foundation is a non-profit organization and welcomes any donations to help us continue funding projects and services to the open-source community. Please consider visiting the following URL, and chip in what you can:

http://netbsd.org/donations/#how-to-donate

Joerg Sonnenberger has announced a new set of mirrored repositories.

You can find Mercurial versions of src, pkgsrc and xsrc under

• https://bitbucket.org/netbsd/src
• https://bitbucket.org/netbsd/pkgsrc

and

• https://bitbucket.org/netbsd/xsrc

The same rules as for the fossil and github repositories apply, i.e. there may be occasional glitches and if it becomes too bad, they might be recreated from scratch.

See more information in the posted thread to tech-repository.

Joerg Sonnenberger has announced a new set of mirrored repositories.

You can find Mercurial versions of src, pkgsrc and xsrc under

• https://bitbucket.org/netbsd/src
• https://bitbucket.org/netbsd/pkgsrc

and

• https://bitbucket.org/netbsd/xsrc

The same rules as for the fossil and github repositories apply, i.e. there may be occasional glitches and if it becomes too bad, they might be recreated from scratch.

See more information in the posted thread to tech-repository.

The NetBSD Foundation supports projects that strive to ship the best possible support in developer-oriented software. This is not exclusive to LLVM, but also includes the more traditional GNU toolchain.

Traditionally, developers in distributions like NetBSD merge 3rd party sources upstream once in a while with major release bumps, like switching from GCC 4.8.x to GCC 5.x. The time frame between the releases can be several months or a few years. This appears as a one-time effort from time to time, however with each software revision the code starts to rot on undermaintained targets. This results in local compatibility patches, which are rarely ready or applicable for upstream and thus detached from the development progress. Upstream developers tend to assume that minimal activity from such projects is a result of having no users and not verifying new code on them.

A good way to improve the situation and ensure quality of software that would shorten developers' time and cost, to deepen relations between NetBSD developers and upstream 3rd party software is to attach a build cluster node within the testing infrastructure.

The shortcoming of this approach is that it requires hardware, bandwidth and admin maintenance. The advantage is closer and better support for the NetBSD platform directly from the 3rd party software developers and the immediate detection of regressions, further reducing development time.

After the process of restoration the NetBSD support within the GDB and binutils projects, there is a new member in the GDB's cluster farm that verifies correct build status on NetBSD/amd64. This bot is hosted within The NetBSD Foundation's internal infrastructure.

The immediate follow up is to turn on --enable-targets=all, which will build all the available backends. Only a few more patches are needed to achieve this milestone.

Next steps involve extending this bot to verify other projects within the shared binutils-gdb repository. This includes GNU binutils itself, ld, gold (after adding appropriate platform support), gas, sim and gprof.

The ultimate goal is to enable execution of all tests for each new binutils-gdb commit in the upstream repository. This must be preceded by accomplishing the ongoing contracted task sponsored by The NetBSD Foundation - to port the LLDB debugger to NetBSD, as the LLVM debugger opens a door for new software from the same field.

The NetBSD Foundation supports projects that strive to ship the best possible support in developer-oriented software. This is not exclusive to LLVM, but also includes the more traditional GNU toolchain.

Traditionally, developers in distributions like NetBSD merge 3rd party sources upstream once in a while with major release bumps, like switching from GCC 4.8.x to GCC 5.x. The time frame between the releases can be several months or a few years. This appears as a one-time effort from time to time, however with each software revision the code starts to rot on undermaintained targets. This results in local compatibility patches, which are rarely ready or applicable for upstream and thus detached from the development progress. Upstream developers tend to assume that minimal activity from such projects is a result of having no users and not verifying new code on them.

A good way to improve the situation and ensure quality of software that would shorten developers' time and cost, to deepen relations between NetBSD developers and upstream 3rd party software is to attach a build cluster node within the testing infrastructure.

The shortcoming of this approach is that it requires hardware, bandwidth and admin maintenance. The advantage is closer and better support for the NetBSD platform directly from the 3rd party software developers and the immediate detection of regressions, further reducing development time.

After the process of restoration the NetBSD support within the GDB and binutils projects, there is a new member in the GDB's cluster farm that verifies correct build status on NetBSD/amd64. This bot is hosted within The NetBSD Foundation's internal infrastructure.

The immediate follow up is to turn on --enable-targets=all, which will build all the available backends. Only a few more patches are needed to achieve this milestone.

Next steps involve extending this bot to verify other projects within the shared binutils-gdb repository. This includes GNU binutils itself, ld, gold (after adding appropriate platform support), gas, sim and gprof.

The ultimate goal is to enable execution of all tests for each new binutils-gdb commit in the upstream repository. This must be preceded by accomplishing the ongoing contracted task sponsored by The NetBSD Foundation - to port the LLDB debugger to NetBSD, as the LLVM debugger opens a door for new software from the same field.

The slate of nominees was voted for and accepted by the members of the foundation. We'd like to our team of nomcom, voting coordinator, and voting validator for putting together the slate and managing the election process.

We welcome Pierre Pronchery and Makoto Fujiwara to the 2017 Board of Directors. We look forward to working with you!

We appreciate all of the wonderful work that S.P.Zeidler and Erik Berls have done on the board during their time as directors, and are grateful for their excellent service to the foundation.

Thank you to all members participating by nominating candidates and voting on the slate.



Respectfully submitted for The NetBSD Foundation,
William J. Coldwell
President/Chairperson

The slate of nominees was voted for and accepted by the members of the foundation. We'd like to our team of nomcom, voting coordinator, and voting validator for putting together the slate and managing the election process.

We welcome Pierre Pronchery and Makoto Fujiwara to the 2017 Board of Directors. We look forward to working with you!

We appreciate all of the wonderful work that S.P.Zeidler and Erik Berls have done on the board during their time as directors, and are grateful for their excellent service to the foundation.

Thank you to all members participating by nominating candidates and voting on the slate.



Respectfully submitted for The NetBSD Foundation,
William J. Coldwell
President/Chairperson

Recently my RKM MK68 machine arrived - a few NetBSD developers have got an engineering sample, kindly provided by Rikomagic, arranged by even more kind cooperation by Christophe Prévotaux from the Bitrig Project.

It is a nice, small 8 core 64 bit arm machine:

Rikomagic provided some documentation, and they have been nice and responsive to our questions for more, so full support for this nice piece of hardware should be a matter of time only.

It will require merging some changes for aarch64 that Matt Thomas already made, which also include a switch of mips to the generic pmap implementation - and unfortunately do not yet work on some mips variants.

I plan to use my machine, once it runs NetBSD, to do regular test runs (of course). But there are a lot of other things to do first, starting with soldering the serial console.

However, I am about to leave for EuroBSDCon 2015, so this will have to wait until next week.

P.S.: I am also still hoping for a 64bit tegra k1 based Chromebook (with free enough boot loader to run NetBSD). I need to replace my aging (huge and heavy) amd64 notebook finally!

There are a number of motivations for running applications directly on top of the Xen hypervisor without resorting to a full general-purpose OS. For example, one might want to maximally isolate applications with minimal overhead. Leaving the OS out of the picture decreases overhead, since for example the inter-application protection offered normally by virtual memory is already handled by the Xen hypervisor. However, at the same time problems arise: applications expect and use many services normally provided by the OS, for example files, sockets, event notification and so forth. We were able to set up a production quality environment for running applications as Xen DomU's in a few weeks by reusing hundreds of thousands of lines of unmodified driver and infrastructure code from NetBSD. While the amount of driver code may sound like a lot for running single applications, keep in mind that it involves for example file systems, the TCP/IP stack, stdio, system calls and so forth -- the innocent-looking open() alone accepts over 20 flags which must be properly handled. The remainder of this post looks at the effort in more detail.

I have been on a path to maximize the reuse potential of the NetBSD kernel with a technology called rump kernels. Things started out with running unmodified drivers in userspace on NetBSD, but the ability to host rump kernels has since spread to the userspace of other operating systems, web browsers (when compiled to javascript), and even the Linux kernel. Running rump kernels directly on the Xen hypervisor has been suggested by a number of people over the years. It provides a different sort of challenge, since as opposed to the environments mentioned previously, the Xen hypervisor is a "bare metal" type of environment: the guest is in charge of everything starting from bootstrap and page table management. The conveniently reusable Xen Mini-OS was employed for interfacing with the bare metal environment, and the necessary rump kernel hypercalls were built upon that. The environment for running unmodified NetBSD kernel drivers (e.g. TCP/IP) and system call handlers (e.g. socket()) directly on top of the Xen hypervisor was available after implementing the necessary rump kernel hypercalls (note: link points to the initial revision).

Shortly after I had published the above, I was contacted by Justin Cormack with whom I had collaborated earlier on his ljsyscall project, which provides system call interfaces to Lua programs. He wanted to run the LuaJIT interpreter and his ljsyscall implementation directly on top of Xen. However, in addition to system calls which were already handled by the rump kernel, the LuaJIT interpreter uses interfaces from libc, so we added the NetBSD libc to the mix. While currently the libc sources are hosted on github, we plan to integrate the changes into the upstream NetBSD sources as soon as things settle (see the repo for instructions on how to produce a diff and verify that the changes really are tiny). The same repository hosts the math library libm, but it is there just for convenience reasons so that these early builds deliver everything from a single checkout. It has been verified that you can alternatively use libm from a standard NetBSD binary distribution, as supposedly you could any other user-level library. The resulting architecture is depicted below.

The API and ABI we provide are the same as of a regular NetBSD installation. Apart from some limitations, such as the absense of fork() -- would it duplicate the DomU? -- objects compiled for a regular NetBSD installation can be linked into the DomU image and booted to run directly as standalone applications on top of Xen. As proofs of concept, I created a demo where a Xen DomU configures TCP/IP networking, mounts a file system image, and runs a httpd daemon to serve the contents, and Justin's demo runs the LuaJIT interpreter and executes the self-test suite for ljsyscall. Though there is solid support for running applications, not all of the work is done. Especially the build framework needs to be more flexible, and everyone who has a use case for this technology is welcome to test out their application and contribute ideas and code for improving the framework.

In conclusion, we have shown that it is straightforward to reuse both kernel and library code from an existing real-world operating system in creating an application environment which can run on top of a bare-metal type cloud platform. By being able to use in the order of 99.9% of the code -- that's 1,000 lines written per 1,000,000 used unmodified -- from an existing, real-world proven source, the task was quick to pull off, the result is robust, and the offered application interfaces are complete. Some might call our work a "yet another $fookernel", but we call it a working result and challenge everyone to evaluate it for themselves.

Yesterday I wrote a serious, user-oriented post about running applications directly on the Xen hypervisor. Today I compensate for the seriousness by writing a why-so-serious, happy-buddha type kernel hacker post. This post is about using NetBSD kernel PCI drivers in rump kernels on Xen, with device access courtesy of Xen PCI passthrough.

I do not like hardware. The best thing about hardware is that it gives software developers the perfect excuse to blame something else for their problems. The second best thing about hardware is that most of the time you can fix problems with physical violence. The third best thing about hardware is that it enables running software. Apart from that, the characteristics of hardware are undesirable: you have to possess the hardware, it does not virtualize nicely, it is a black box subject to the whims of whoever documented it, etc. Since rump kernels are targeting reuse and virtualization of kernel drivers in an environment-agnostic fashion, needless to say, there is a long, non-easy truce between hardware drivers and rump kernels.

Many years ago I did work which enabled USB drivers to run in rump kernels. The approach was to use the ugen device node to access the physical device from userspace. In other words, the layers which transported the USB protocol to and from the device remained in the host kernel, while the interpretation of the contents was moved to userspace; a USB host controller driver was written to act as the middleman between these two. While the approach did allow to run USB drivers such as umass and ucom, and it did give me much-needed exercise in the form of having to plug and unplug USB devices while testing, the whole effort was not entirely successful. The lack of success was due to too much of the driver stack, namely the USB host controller and ugen drivers, residing outside of the rump kernel. The first effect was that due to my in-userspace development exercising in-kernel code (via the ugen device) in creative ways, I experienced way too many development host kernel panics. Some of the panics could be fixed, while others were more in the department "well I have no idea why it decided to crash now or how to repeat the problem". The second effect was being able to use USB drivers in rump kernels only on NetBSD hosts, again foiling environment-agnostism (is that even a word?). The positive side-effect of the effort was adding ioconf and pseudo-root support to config(1), thereby allowing modular driver device tree specifications to be written in the autoconf DSL instead of having to be open-coded into the driver in C.

In the years that followed, the question of rump kernels supporting real device drivers which did not half-hide behind the host's skirt became a veritable FAQ. My answer remained the same: "I don't think it's difficult at all, but there's no way I'm going to do it since I hate hardware". While it was possible to run specially crafted drivers in conjuction with rump kernels, e.g. DPDK drivers for PCI NICs, using any NetBSD driver and supported device was not possible. However, after bolting rump kernels to run on top of Xen, the opportunity to investigate Xen's PCI passthrough capabilities presented itself, and I did end up with support for PCI drivers. Conclusion: I cannot be trusted to not do something.

The path to making PCI devices work consisted of taking n small steps. The trick was staying on the path instead of heading toward the light. If you do the "imagine how it could work and then make it work like that" development like I do, you'll no doubt agree that the steps presented below are rather obvious. (The relevant NetBSD man pages are linked in parenthesis. Also note that the implementations of these interfaces are MD in NetBSD, making for a clean cut into the NetBSD kernel architecture)

1. passing PCI config space read and writes to the Xen hypervisor (pci(9))
2. mapping the device memory space into the Xen guest and providing access methods (bus_space(9))
3. mapping Xen events channels to driver interrupt handlers (pci_intr(9))
4. allocating DMA-safe memory and translating memory addresses to and from machine addresses, which are even more physical than physical addresses (bus_dma(9))

On the Xen side of things, the hypercalls for all of these tasks are more or less one-liner calls into the Xen Mini-OS (which, if you read my previous post, is the layer which takes care of the lowest level details of running rump kernels on top of Xen).

And there we have it, NetBSD PCI drivers running on a rump kernel on Xen. The two PCI NIC drivers I tested both even pass the allencompassing ping test (and the can-configure-networking-using-dhcp test too). There's nothing like a dmesg to brighten the day.

Closing thoughts: virtual machine emulators are great, but you lose the ability to kick the hardware.

Just a small update on the previous post about firefox on sparc64: after a bit more work, the brand new version 24 ESR builds straight from pkgsrc (so should be included in the next set of binary pkgs).

All open issues (wrong colours on scaled images, failing https, ...) have been resolved.

Here is a new screeenshot:

The NetBSD Project is pleased to announce NetBSD 5.2.1, the first security/bugfix update of the NetBSD 5.2 release branch, and NetBSD 5.1.3, the third security/bugfix update of the NetBSD 5.1 release branch. They represent a selected subset of fixes deemed important for security or stability reasons, and if you are running a release of NetBSD prior to 5.1.3, you are recommended to update to a supported NetBSD 5.x or NetBSD 6.x version.

For more details, please see the NetBSD 5.2.1 release notes or NetBSD 5.1.3 release notes.

Complete source and binaries for NetBSD 5.2.1 and NetBSD 5.1.3 are available for download at many sites around the world. A list of download sites providing FTP, AnonCVS, SUP, and other services may be found at http://www.NetBSD.org/mirrors/.

Updates to NetBSD 6.x will be coming in the next few days.

The NetBSD Project is pleased to announce NetBSD 6.1.2, the second security/bugfix update of the NetBSD 6.1 release branch, and NetBSD 6.0.3, the third security/bugfix update of the NetBSD 6.0 release branch. They represent a selected subset of fixes deemed important for security or stability reasons, and if you are running a prior release of NetBSD 6.x3, you are recommended to update.

For more details, please see the NetBSD 6.1.2 release notes or NetBSD 6.0.3 release notes.

Complete source and binaries for NetBSD 6.1.2 and NetBSD 6.0.3 are available for download at many sites around the world. A list of download sites providing FTP, AnonCVS, SUP, and other services may be found at http://www.NetBSD.org/mirrors/.

Google Summer of Code 2016 is now over. We have polished the code and documentation and submitted the final term evaluation on 23rd of August 2016. The mentors evaluated us in the following week.

If you are impatient (and this time impatience is definitely a virtue!) please take a look to all The NetBSD Foundation GSoC 2016 projects' code submissions!

Introduction

In part 1 we have learned what happens under the hood when we split debugging symbols: how debugging information is stored/stripped off, the relevant ELF sections involved, various tools to dump that information, etc..

In particular, we have studied what happens on NetBSD when we set the MKDEBUG* flags.

With this background we can finally try to implement this functionality in the pkgsrc infrastructure. In this blog post we will first give a practical look at PKG_DEBUGDATA and then we will analyze the code that I have written in the first mid-term of the GSoC to accomplish that.

PKG_DEBUGDATA in action

Before digging in the implementation of debugdata functionality let's see what it produces!

In part 1 we took as example a very simple program that just prints out the lyrics of Ten Green Bottles song. After packaging it as local/green-bottles let's just build it without any special pkgsrc system variables set:

$ cd pkgsrc/local/green-bottles
$ make install
[...]
$ green-bottles
ten green bottles hanging on the wall
[...]
$ pkg_info -L green-bottles
Information for green-bottles-0:

Files:
/usr/pkg/bin/green-bottles
$ gdb `which green-bottles`
GNU gdb (GDB) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[...]
Reading symbols from /usr/pkg/bin/green-bottles...(no debugging symbols found)...done.
(gdb) quit

That's expected because we did not set any special CFLAGS nor INSTALL_UNSTRIPPED.

Before setting PKG_DEBUGDATA to "yes" let's inspect its documentation via the help target:

$ make help topic=PKG_DEBUGDATA
===> mk/bsd.debugdata.mk (keywords: INSTALL_UNSTRIPPED PKG_DEBUGLEVEL PKG_DEBUGDATA debug):
# This Makefile fragment is included by bsd.pkg.mk and implements the
# logic needed to strip debug symbols off the program/libraries.
#
# User-settable variables:
#
# PKG_DEBUGDATA
#       If "yes", install stripped debug symbols for all programs and shared
#       libraries. Please notice that if it is defined INSTALL_UNSTRIPPED will
#       be also defined internally.
#
# PKG_DEBUGLEVEL
#       Used to control the granularity of the debug information. Can be
#       "small", "default", "detailed".
#       TODO: the name of this variable should be changed because it can be
#       TODO: easily confused with PKG_DEBUG_LEVEL!
#
# See also:
#       INSTALL_UNSTRIPPED
#

Now that we have finally an idea of what PKG_DEBUGDATA does, let's set it and reinstall the green-bottles package:

$ make clean deinstall
[...]
$ PKG_DEBUGDATA=yes make install
[...]
===> Installing for green-bottles-0
[...]
=> Stripping debug symbols
=> Installing debug data
[...]
=> Checking for missing debug data in green-bottles-0
[...]

Apart from the various phases we can see three extra messages that are now printed out: stripping of debug symbols, installing of debug data and a check for missing debug data.

If we inspect the files installed we can now also see green-bottles.debug:

$ pkg_info -L green-bottles
Information for green-bottles-0:

Files:
/usr/pkg/bin/green-bottles.debug
/usr/pkg/bin/green-bottles

Indeed if we now try to run it through gdb(1):

$ gdb `which green-bottles`
GNU gdb (GDB) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
[...]
Reading symbols from /usr/pkg/bin/green-bottles...Reading symbols from /usr/pkg/bin/green-bottles.debug...done.
done.
(gdb) b main
Breakpoint 1 at 0xad0: file green-bottles.c, line 29.
(gdb) run
Starting program: /usr/pkg/bin/green-bottles

Breakpoint 1, main () at green-bottles.c:29
29      {
(gdb)
[...]

green-bottles was installed as usual without requiring any changes from MAINTAINERs, in fact the various .debug files are generated, installed and added to the PLIST dynamically.

A look at mk/bsd.debugdata.mk and mk/check/check-debugdata.mk implementation

All the functionalities that implement stripping of the debug data from installed programs and libraries are implemented entirely in bsd.debugdata.mk.

check/check-debugdata.mk checks that all programs and libraries have the debug data correctly stripped into their corresponding *.debug files.

mk/bsd.debugdata.mk

The first 23 lines of bsd.debugdata.mk contain a comment that is also accessible via the help target. In particular it describes all the user-settable variables:

• PKG_DEBUGDATA: if "yes" it turns on debugdata functionality to generate the *.debug files and then install them as part of the package.
• PKG_DEBUGLEVEL: useful to control the granularity of the debug information, i.e. the -g level flag passed to the compiler. It can be "small", "default" and "detailed".

Then _VARGROUPS and _USER_VARS.<vargroup> are set accordingly. These are used by the show-all target (if you are more curious regarding that please just try make show-all and/or give a look to mk/misc/show.mk).

After various definitions of some used variables (should be self-explainable) _FIND_DEBUGGABLEDATA_ERE is defined as an Extended Regular Expression that is used to match potential files that can be stripped. _FIND_DEBUGGABLEDATA_ERE is then used to limit the file list generated via _FIND_DEBUGGABLEDATA_FILELIST_CMD

Lines 63-86 pass the appropriate debug flags and debug level to the compiler.

Then _PLIST_DEBUGDATA is added to the PLIST_SRC_DFLT variable. PLIST_SRC_DFLT contains all the default PLISTs that usually resides in pkgsrc/category/PLIST* (e.g. PLIST, PLIST.common, PLIST.NetBSD, etc.). If you are more interested in how it works, please give a look to mk/plist/plist.mk. In this way all the *.debug files listed in _PLIST_DEBUGDATA are dynamically appended to the package PLIST.

In lines 90-111 generate-strip-debugdata target is defined. It basically just does the operations we have explored in part 1 with little adjustments for pkgsrc:

• Check if the current file is strippable via objdump(1)
• If the current file is strippable objcopy --only-keep-debug program|library program.debug|library.debug is invoked in order to populate the .debug file.
• If the current file is strippable objcopy --strip-debug -p -R .gnu_debuglink --add-gnu-debuglink=program.debug|library.debug program|library is invoked to delete the debug information from the current file (program or library) and to add the .gnu_debuglink ELF section to it so that the debugger knows where to pick the corresponding .debug file.
• Append the .debug path and filename to the _PLIST_DEBUGDATA file.

To accomplish that RUN is used to run all shell commands without printing them. Please note that when RUN is used all shell commands should be terminated with a semicolon. For more information regarding RUN please take a look at make help topic=RUN.

In lines 113-122 install-strip-debugdata is defined. It just installs all *.debug files via INSTALL_DATA. install-strip-debugdata target will then be invoked after the post-install phase.

mk/check/check-debugdata.mk

First 26 lines of check-debugdata.mk contain a comment for the pkgsrc online documentation. It describes the following user-settable variables:

• CHECK_DEBUGDATA: if "yes" it enables debugdata checks (by default most checks are usually enabled only if PKG_DEVELOPER is "yes")

...and the following package-settable variables:

• CHECK_DEBUGDATA_SKIP: list of shell patterns that should be excluded from the check.
• CHECK_DEBUGDATA_SUPPORTED: whether the check should be enabled for the package or not.

Like what it was done for bsd.debugdata.mk, _VARGROUPS and _{USER,PKG}_VARS.check-debugdata are defined accordingly.

Similarly to what was done for _FIND_DEBUGGABLEDATA_ERE and _FIND_DEBUGGABLEDATA_FILELIST_CMD in bsd.debugdata.mk, _CHECK_DEBUGDATA_ERE and _CHECK_DEBUGDATA_FILELIST_CMD are defined.

In lines 54-103 _check-debugdata target is defined. _check-debugdata performs the following checks, respectively:

• Check that the program/library is readable.
• If the program/library is a file format recognizable by objdump(1) check if it has a .gnu_debuglink ELF section.
• Check that the respective .debug file of the program/library is readable.
• Print a warning message if the .debug file does not contain a .debug_info ELF section.

Other minor changes in mk/*

In order to instruct pkgsrc to pick up bsd.debugdata.mk and checks/check-debugdata.mk, nothing intrusive though:

• Add .include "bsd.debugdata.mk" in bsd.pkg.mk.
• Add TOOLS_PLATFORM.objcopy and TOOLS_PLATFORM.objdump to mk/tools/tools.NetBSD.mk (other OPSYSs will also needed to be adjusted similarly)
• Add CHECK_DEBUGDATA_SUPPORTED to check/bsd.check-vars.mk.
• Add .include "check-debugdata.mk" in check/bsd.check.mk.

Conclusion

In this blog post we have learned what PKG_DEBUGDATA does via a practical example.

Then we have examinated how bsd.debugdata.mk and checks/check-debugdata.mk are implemented.

PKG_DEBUGDATA is completely agnostic if a package uses GNU configure, cmake, etc., and it is expected to work without any changes. I have only tested it with simple packages also containing libraries and the ones that uses libtool but I have still not tested it in the wild and some minor adjustements can be probably needed.

Thanks again to Google for organizing Google Summer of Code, The NetBSD Foundation and in particular my mentors David Maxwell, Jöerg Sonnenberger, Taylor R. Campbell, Thomas Klausner and William J. Coldwell.

References

• The pkgsrc guide, Alistair Crooks, Hubert Feyrer, The pkgsrc Developers
• PMake -- A Tutorial, Adam de Boor (available under /usr/share/doc/ref1/make/ in PS and text format)
• make(1)
• objdump(1)
• objcopy(1)
• gdb(1)
• pkgsrc/mk/misc/show.mk, 1.12
• pkgsrc/mk/plist/plist.mk, 1.49
• pkgsrc/mk/bsd.pkg.mk, 1.2021
• pkgsrc/mk/check/bsd.check-vars.mk 1.8
• pkgsrc/mk/check/bsd.check.mk 1.8

Google Summer of Code 2016 is now over. We have polished the code and documentation and submitted the final term evaluation on 23rd of August 2016. The mentors evaluated us in the following week.

If you are impatient (and this time impatience is definitely a virtue!) please take a look to all The NetBSD Foundation GSoC 2016 projects' code submissions!

Introduction

In part 1 we have learned what happens under the hood when we split debugging symbols: how debugging information is stored/stripped off, the relevant ELF sections involved, various tools to dump that information, etc..

In particular, we have studied what happens on NetBSD when we set the MKDEBUG* flags.

With this background we can finally try to implement this functionality in the pkgsrc infrastructure. In this blog post we will first give a practical look at PKG_DEBUGDATA and then we will analyze the code that I have written in the first mid-term of the GSoC to accomplish that.

PKG_DEBUGDATA in action

Before digging in the implementation of debugdata functionality let's see what it produces!

In part 1 we took as example a very simple program that just prints out the lyrics of Ten Green Bottles song. After packaging it as local/green-bottles let's just build it without any special pkgsrc system variables set:

$ cd pkgsrc/local/green-bottles
$ make install
[...]
$ green-bottles
ten green bottles hanging on the wall
[...]
$ pkg_info -L green-bottles
Information for green-bottles-0:

Files:
/usr/pkg/bin/green-bottles
$ gdb `which green-bottles`
GNU gdb (GDB) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[...]
Reading symbols from /usr/pkg/bin/green-bottles...(no debugging symbols found)...done.
(gdb) quit

That's expected because we did not set any special CFLAGS nor INSTALL_UNSTRIPPED.

Before setting PKG_DEBUGDATA to "yes" let's inspect its documentation via the help target:

$ make help topic=PKG_DEBUGDATA
===> mk/bsd.debugdata.mk (keywords: INSTALL_UNSTRIPPED PKG_DEBUGLEVEL PKG_DEBUGDATA debug):
# This Makefile fragment is included by bsd.pkg.mk and implements the
# logic needed to strip debug symbols off the program/libraries.
#
# User-settable variables:
#
# PKG_DEBUGDATA
#       If "yes", install stripped debug symbols for all programs and shared
#       libraries. Please notice that if it is defined INSTALL_UNSTRIPPED will
#       be also defined internally.
#
# PKG_DEBUGLEVEL
#       Used to control the granularity of the debug information. Can be
#       "small", "default", "detailed".
#       TODO: the name of this variable should be changed because it can be
#       TODO: easily confused with PKG_DEBUG_LEVEL!
#
# See also:
#       INSTALL_UNSTRIPPED
#

Now that we have finally an idea of what PKG_DEBUGDATA does, let's set it and reinstall the green-bottles package:

$ make clean deinstall
[...]
$ PKG_DEBUGDATA=yes make install
[...]
===> Installing for green-bottles-0
[...]
=> Stripping debug symbols
=> Installing debug data
[...]
=> Checking for missing debug data in green-bottles-0
[...]

Apart from the various phases we can see three extra messages that are now printed out: stripping of debug symbols, installing of debug data and a check for missing debug data.

If we inspect the files installed we can now also see green-bottles.debug:

$ pkg_info -L green-bottles
Information for green-bottles-0:

Files:
/usr/pkg/bin/green-bottles.debug
/usr/pkg/bin/green-bottles

Indeed if we now try to run it through gdb(1):

$ gdb `which green-bottles`
GNU gdb (GDB) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
[...]
Reading symbols from /usr/pkg/bin/green-bottles...Reading symbols from /usr/pkg/bin/green-bottles.debug...done.
done.
(gdb) b main
Breakpoint 1 at 0xad0: file green-bottles.c, line 29.
(gdb) run
Starting program: /usr/pkg/bin/green-bottles

Breakpoint 1, main () at green-bottles.c:29
29      {
(gdb)
[...]

green-bottles was installed as usual without requiring any changes from MAINTAINERs, in fact the various .debug files are generated, installed and added to the PLIST dynamically.

A look at mk/bsd.debugdata.mk and mk/check/check-debugdata.mk implementation

All the functionalities that implement stripping of the debug data from installed programs and libraries are implemented entirely in bsd.debugdata.mk.

check/check-debugdata.mk checks that all programs and libraries have the debug data correctly stripped into their corresponding *.debug files.

mk/bsd.debugdata.mk

The first 23 lines of bsd.debugdata.mk contain a comment that is also accessible via the help target. In particular it describes all the user-settable variables:

• PKG_DEBUGDATA: if "yes" it turns on debugdata functionality to generate the *.debug files and then install them as part of the package.
• PKG_DEBUGLEVEL: useful to control the granularity of the debug information, i.e. the -g level flag passed to the compiler. It can be "small", "default" and "detailed".

Then _VARGROUPS and _USER_VARS.<vargroup> are set accordingly. These are used by the show-all target (if you are more curious regarding that please just try make show-all and/or give a look to mk/misc/show.mk).

After various definitions of some used variables (should be self-explainable) _FIND_DEBUGGABLEDATA_ERE is defined as an Extended Regular Expression that is used to match potential files that can be stripped. _FIND_DEBUGGABLEDATA_ERE is then used to limit the file list generated via _FIND_DEBUGGABLEDATA_FILELIST_CMD

Lines 63-86 pass the appropriate debug flags and debug level to the compiler.

Then _PLIST_DEBUGDATA is added to the PLIST_SRC_DFLT variable. PLIST_SRC_DFLT contains all the default PLISTs that usually resides in pkgsrc/category/PLIST* (e.g. PLIST, PLIST.common, PLIST.NetBSD, etc.). If you are more interested in how it works, please give a look to mk/plist/plist.mk. In this way all the *.debug files listed in _PLIST_DEBUGDATA are dynamically appended to the package PLIST.

In lines 90-111 generate-strip-debugdata target is defined. It basically just does the operations we have explored in part 1 with little adjustments for pkgsrc:

• Check if the current file is strippable via objdump(1)
• If the current file is strippable objcopy --only-keep-debug program|library program.debug|library.debug is invoked in order to populate the .debug file.
• If the current file is strippable objcopy --strip-debug -p -R .gnu_debuglink --add-gnu-debuglink=program.debug|library.debug program|library is invoked to delete the debug information from the current file (program or library) and to add the .gnu_debuglink ELF section to it so that the debugger knows where to pick the corresponding .debug file.
• Append the .debug path and filename to the _PLIST_DEBUGDATA file.

To accomplish that RUN is used to run all shell commands without printing them. Please note that when RUN is used all shell commands should be terminated with a semicolon. For more information regarding RUN please take a look at make help topic=RUN.

In lines 113-122 install-strip-debugdata is defined. It just installs all *.debug files via INSTALL_DATA. install-strip-debugdata target will then be invoked after the post-install phase.

mk/check/check-debugdata.mk

First 26 lines of check-debugdata.mk contain a comment for the pkgsrc online documentation. It describes the following user-settable variables:

• CHECK_DEBUGDATA: if "yes" it enables debugdata checks (by default most checks are usually enabled only if PKG_DEVELOPER is "yes")

...and the following package-settable variables:

• CHECK_DEBUGDATA_SKIP: list of shell patterns that should be excluded from the check.
• CHECK_DEBUGDATA_SUPPORTED: whether the check should be enabled for the package or not.

Like what it was done for bsd.debugdata.mk, _VARGROUPS and _{USER,PKG}_VARS.check-debugdata are defined accordingly.

Similarly to what was done for _FIND_DEBUGGABLEDATA_ERE and _FIND_DEBUGGABLEDATA_FILELIST_CMD in bsd.debugdata.mk, _CHECK_DEBUGDATA_ERE and _CHECK_DEBUGDATA_FILELIST_CMD are defined.

In lines 54-103 _check-debugdata target is defined. _check-debugdata performs the following checks, respectively:

• Check that the program/library is readable.
• If the program/library is a file format recognizable by objdump(1) check if it has a .gnu_debuglink ELF section.
• Check that the respective .debug file of the program/library is readable.
• Print a warning message if the .debug file does not contain a .debug_info ELF section.

Other minor changes in mk/*

In order to instruct pkgsrc to pick up bsd.debugdata.mk and checks/check-debugdata.mk, nothing intrusive though:

• Add .include "bsd.debugdata.mk" in bsd.pkg.mk.
• Add TOOLS_PLATFORM.objcopy and TOOLS_PLATFORM.objdump to mk/tools/tools.NetBSD.mk (other OPSYSs will also needed to be adjusted similarly)
• Add CHECK_DEBUGDATA_SUPPORTED to check/bsd.check-vars.mk.
• Add .include "check-debugdata.mk" in check/bsd.check.mk.

Conclusion

In this blog post we have learned what PKG_DEBUGDATA does via a practical example.

Then we have examinated how bsd.debugdata.mk and checks/check-debugdata.mk are implemented.

PKG_DEBUGDATA is completely agnostic if a package uses GNU configure, cmake, etc., and it is expected to work without any changes. I have only tested it with simple packages also containing libraries and the ones that uses libtool but I have still not tested it in the wild and some minor adjustements can be probably needed.

Thanks again to Google for organizing Google Summer of Code, The NetBSD Foundation and in particular my mentors David Maxwell, Jöerg Sonnenberger, Taylor R. Campbell, Thomas Klausner and William J. Coldwell.

References

• The pkgsrc guide, Alistair Crooks, Hubert Feyrer, The pkgsrc Developers
• PMake -- A Tutorial, Adam de Boor (available under /usr/share/doc/ref1/make/ in PS and text format)
• make(1)
• objdump(1)
• objcopy(1)
• gdb(1)
• pkgsrc/mk/misc/show.mk, 1.12
• pkgsrc/mk/plist/plist.mk, 1.49
• pkgsrc/mk/bsd.pkg.mk, 1.2021
• pkgsrc/mk/check/bsd.check-vars.mk 1.8
• pkgsrc/mk/check/bsd.check.mk 1.8

There was a nice, friendly and informal summit of NetBSD developers (and interested users) in Sofia on Friday, September 26, 2014.

Bernd Ernesti (veego@) took this photo:

In the back row from left to right:
Masao Uebayashi (uebayasi), Thomas Klausner (wiz), Yann Sionneau, Marc Balmer (mbalmer), Justin Cormack (justin), Jaap Boender (jaapb), Adrian Steinmann (ast), Martin Husemann (martin), Taylor R Campbell (riastradh), Michael van Elst (mlelstv), Sevan Janiyan, Alexander Nasonov (alnsn).
In the front row, from left to right:
Julian Coleman (jdc), Joerg Sonnenberger (joerg), Valeriy E. Ushakov (uwe), Christoph Badura (bad), S.P.Zeidler (spz), Pierre Pronchery (khorben), Stephen Borrill (sborrill)

Some Developers made it to the conference only after the summit, so Emmanuel Dreyfus (manu), Luke Mewburn (lukem) and Lourival Neto (lneto) are unfortunately missing on that picture.

Marc Balmer presented some slides prepared by Masanobu SAITOH about ongoing work at IIJ.

Marc also proposed some extensions to the in-tree httpd (aka bozohttpd) to allow creation of simple dynamic content via "Lua templates". The question whether it would be possible to serve www.netbsd.org by bozohttpd was discussed, and only administrative reasons seem to prevent it - which was overall considered "good enough".

Pierre Pronchery presented his work on EdgeBSD - and why he does not consider it a fork, but more a playground for experimentation. He also reported on some of his experiences with using git on the NetBSD source tree.

Two more slightly TNF internal issues were discussed, and after that the whole crowd moved to dinner (including a bit of Bulgarian wine).

Having an in-person meeting of a relative huge number of NetBSD developers was considered very useful and we will try to repeat it at other occasions. Next time, if similar attendance is likely, we will plan for more time (like a full day) and also create a schedule of talks/presentations up front, still with the option to add ad-hoc ones.

The NetBSD Project is pleased to announce NetBSD 6.1.1, the first security/bugfix update of the NetBSD 6.1 release branch. It represents a selected subset of fixes deemed important for security or stability reasons.

For more details, please see the 6.1.1 release notes.

Complete source and binaries for NetBSD 6.1.1 are available for download at many sites around the world. A list of download sites providing FTP, AnonCVS, SUP, and other services may be found at http://www.NetBSD.org/mirrors/.

The most time-consuming part of operating system development is obtaining enough drivers to enable the OS to run real applications which interact with the real world. NetBSD's rump kernels allow reducing that time to almost zero, for example for developing special-purpose operating systems for the cloud and embedded IoT devices. This article describes an experiment in creating an OS by using a rump kernel for drivers. It attempts to avoid going into full detail on the principles of rump kernels, which are available for interested readers from rumpkernel.org. We start by defining the terms in the title:

• OS: operating system, i.e. the overhead that enables applications to run
• internet-ready: supports POSIX applications and talks TCP/IP
• a week: 7 days, in this case the period between Wednesday night last week and Wednesday night this week
• from scratch: began by writing the assembly instructions for the kernel entry point
• rump kernel: partial kernel consisting of unmodified NetBSD kernel drivers
• bare metal: what you get from the BIOS/firmware

Why would anyone want to write a new OS? If you look at our definition of "OS", you notice that you want to keep the OS as small as possible. Sometimes you might not care, e.g. in case of a desktop PC, but other times when hardware resources are limited or you have high enough security concerns, you actually might care. For example, NetBSD itself is not able to run on systems without a MMU, but the OS described in this article does not use virtual memory at all, and yet it can run most of the same applications as NetBSD can. Another example: if you want to finetune the OS to suit your application, it's easier to tune a simple OS than a very complicated general purpose OS. The motivation for this work came in fact from someone who was looking to provision applications as services on top of VMWare, but found that no existing solution supported the system interfaces his applications needed without dragging an entire classic OS along for the ride.

Let's move on to discussing what an OS needs to support for it to be able to host for example a web server written for a regular OS such as Linux or the BSDs. The list gets quite long. You need a file system where the web server reads the served pages from, you need a TCP/IP stack to communicate with the clients, and you need a network interface driver to be able to send and receive packets. Furthermore, you need the often overlooked, yet very surprisingly complicated system call handlers. For example, opening a socket is not really very complicated to handle. Neither is reading and writing data. However, when you start piling things like fcntl(O_NONBLOCK) and poll() on top, things get trickier. By a rough estimate, if you run an httpd on NetBSD, approximately 100k lines of code from kernel are used just to service the requests that the httpd makes. If you do the math (and bc did), there are 86400 seconds in a week. The OS we are discussing is able to run an off-the-shelf httpd, but definitely I did not write >1 line of code per second 24/7 during the past week.

Smoke and Mirrors, CGI Edition

The key to happiness is not to write 100k lines of code from scratch, nor to port it from another OS, as both are time-consuming and error-prone techniques, and error-proneness leads to even more consumption of time. Rump kernels come into the picture as the key to happiness and provide the necessary drivers.

As the old saying goes: "rump kernels do not an OS make", and we need the rest of the bits that make up the OS side of the software stack from somewhere. These bits need to make it seem like the drivers in a rump kernel are running inside the NetBSD kernel, hence "smoke and mirrors". What is surprising is how little code needs to exist between the drivers and the hardware, just some hundreds of lines of code. More specifically, in the bare metal scenario we need support for:

• low level machine dependent code
• thread support and a scheduler
• rump kernel hypercall layer
• additionally: bundling the application into a bootable image

The figure below illustrates the rump kernel software stack. The arrows correspond to the above list (in reverse order). We go over the list starting from the top of the list (bottom of the figure).

Low level machine dependent code is what the OS uses to get the CPU and devices to talking terms with the rest of OS. Before we can do anything useful, we need to bootstrap. Bootstrapping x86-32 is less work than one would expect, which incidentally is also why the OS runs only in 32bit mode (adding 64bit support would not likely be many hours of work — and patches are welcome). Thanks to the Multiboot specification, the bootstrap code is more or less just a question of setting the stack pointer and jumping to C code. In C code we need to parse the amount of physical memory available and initialize the console. Since NetBSD device drivers mainly use interrupts, we also need interrupt support for the drivers to function correctly. On x86, interrupt support means setting up the CPU's interrupt descriptor tables and programming the interrupt controller. Since rump kernels do not support interrupts, in addition we need a small interrupt stub that transfers the interrupt request to a thread context which calls the rump kernel. In total, the machine dependent code is only a few hundred lines. The OSDev.org wiki contains a lot of information which was useful when hammering the hardware into shape. The other source of x86 hardware knowledge was x86 support in NetBSD.

Threads and scheduling might sound intimidating, but they are not. First, rump kernels can run on top of any kinds of threads you throw at them, so we can just use the ones which are the simplest to implement: cooperative threads. Note, simple does not mean poorly performing threads, and in fact the predictability of cooperative threads, at least in my opinion, makes them more likely to perform better than preemptive threading in cases where you are honing an OS for a single application. Second, I already had access to an implementation which served as the basis: Justin Cormack's work on userspace fibers, which in turn has its roots in Xen MiniOS we use for running rump kernel on the Xen hypervisor, could be re-purposed as the threads+scheduler implementation, with the context switch code kindly borrowed from MiniOS.

The rump kernel hypercall interface is what rump kernels themselves run on. While the implementation is platform-specific, our baremetal OS shares a large portion of its qualities with the Xen platform that was already supported. Therefore, most of the Xen implementation applied more or less directly. One notable exception to the similarities is that Xen paravirtualized devices are not available on bare metal and therefore we access all I/O devices via the PCI bus.

All we need now is the application, a.k.a. "userspace". Support for application interfaces (POSIX syscalls, libc, etc.) readily exists for rump kernels, so we just use what is already available. The only remaining issue is building the bundle that we bootstrap. For that, we can repurpose Ian Jackson's app-tools which were originally written for the rump kernel Xen platform. Using app-tools, we could build a bootable image containing thttpd simply by running the app-tools wrappers for ./configure and make. The image below illustrates part of the build output, along with booting the image in QEMU and testing that the httpd really works. The use of QEMU, i.e. software-emulated bare metal, is due to convenience reasons.

Conclusions

You probably noticed that whole thing is just bolting a lot of working components together while writing minimal amounts of necessary glue. That is exactly the point: never write or port or hack what you can reuse without modification. Code reusability has always been the strength of NetBSD and rump kernels add another dimension to that quality.

The source code for the OS discussed in this post is available under a 2-clause BSD license from repo.rumpkernel.org/rumpuser-baremetal.

In the last month I started with upstream of the code for sanitizers: the common layer and ubsan. I worked also on the elimination of unexpected failures in LLVM and Clang. I've managed to achieve, with a pile of local patches, the number of 0 unexpected bugs within LLVM (check-llvm) and 3 unexpected bugs within Clang (check-clang) (however these ones were caused by hardcoded environment -lstdc++ vs -lc++). The number of failures in sanitizers (check-sanitizer) is also low, it's close to zero.

LLVM

In order to achieve the goals of testability concerning the LLVM projects, I had to prepare a new pkgsrc-wip package called llvm-all-in-one that contains 12 active LLVM projects within one tree. The set of these projects is composed of: llvm, clang, compiler-rt, libcxx, libcxxabi, libunwind, test-suite, openmp, llgo, lld, lldb, clang-tools-extra. These were required to build and execute test-suites in the LLVM's projects. Ideally the tests should work in standalone packages - built out-of-LLVM-sources - and with GCC/Clang, however the real life is less bright and this forced me to use Clang as the system compiler an all-in-one package in order to develop the work environment with the ability to build and execute unit tests.

There were four threads within LLVM:

• Broken std::call_once with libstdc++. This is an old and well-known bug, which was usually worked around with a homegrown implementation llvm::call_once. I've discovered that the llvm::call_once workaround isn't sufficient for the whole LLVM functionality, as std::call_once can be called internally inside the libstdc++ libraries - like within the C++11 futures interface. This bug has been solved by Joerg Sonnenberger in the ELF dynamic linker.
• Unportable shell construct hardcoded in tests ">&". This has been fixed upstream.
• LLVM JIT. The LLVM Memory generic allocator (or page mapper) was designed to freely map pages with any combination of the protection bits: R,W,X. This approach breaks on NetBSD with PaX MPROTECT and requires redesign of the interfaces. This is the continuation of the past month AllocateRWX and ReleaseRWX compatibility with NetBSD improvements. I've prepared few variations of local patches addressing these issues and it's still open for discussion with upstream. My personal preference is to remove the current API entirely and introduce a newer one with narrowed down functionality to swap between readable (R--), writable (RW-) and executable (R-X) memory pages. This would effectively enforce W^X.
• Sanitizers support. Right now, I keep the patches locally in order to upstream the common sanitizer code in compiler-rt.

The LLVM JIT API is the last cause of unexpected failures in check-llvm. This breaks MCJIT, ORCJIT and ExecutionEngine libraries and causes around 200 unexpected failures within tests.

Clang

I've upstreamed a patch that enables ubsan and asan on Clang's frontend for NetBSD/amd64. This support isn't complete, and requires sanitizers' support code upstreamed to compiler-rt.

compiler-rt

The current compiler-rt tasks can be divided into:

1. upstream sanitizer common code shared with POSIX platforms
2. upstream sanitizer common code shared with Linux and FreeBSD
3. upstream sanitizer common code shared with FreeBSD
4. upstream sanitizer common code specific to NetBSD
5. build, execute and pass tests for sanitizer common code in check-santizer

This means that ubsan, asan and the rest of the specific sanitizers wait in queue.

All the mentioned tasks are being worked on simultaneously, with a soft goal to finish them one after another from the first to the last one.

The last point with check-sanitizer unveiled so far two generic bugs on NetBSD:

• Return errno EFAULT instead of EACCES on memory fault with read(2)/write(2)-like syscalls.
• Honor PTHREAD_DESTRUCTOR_ITERATIONS in libpthread.

These bugs are not strictly real bugs, but they were introducing needless differences with other modern POSIX systems. The fixes were introduced by Christos Zoulas and backported to NetBSD-8.

Plan for the next milestone

I have decided not to open new issues in with the coming month and focus on upstreaming the remaining LLVM code. The roadmap for the next month is to continue working on the goals of the previous months. std::call_once is an example that every delayed bug keeps biting again and again in future.

LLVM 5.0.0 is planned to be released this month (August) and there is a joint motivation with the upstream maintainer to push compatibility fixes for LLVM JIT. There is an option to submit a workaround now and introduce refactoring for the trunk and next version (6.0.0).

This work was sponsored by The NetBSD Foundation.

The NetBSD Foundation is a non-profit organization and welcomes any donations to help us continue funding projects and services to the open-source community. Please consider visiting the following URL, and chip in what you can:

http://netbsd.org/donations/#how-to-donate

In the last month I started with upstream of the code for sanitizers: the common layer and ubsan. I worked also on the elimination of unexpected failures in LLVM and Clang. I've managed to achieve, with a pile of local patches, the number of 0 unexpected bugs within LLVM (check-llvm) and 3 unexpected bugs within Clang (check-clang) (however these ones were caused by hardcoded environment -lstdc++ vs -lc++). The number of failures in sanitizers (check-sanitizer) is also low, it's close to zero.

LLVM

In order to achieve the goals of testability concerning the LLVM projects, I had to prepare a new pkgsrc-wip package called llvm-all-in-one that contains 12 active LLVM projects within one tree. The set of these projects is composed of: llvm, clang, compiler-rt, libcxx, libcxxabi, libunwind, test-suite, openmp, llgo, lld, lldb, clang-tools-extra. These were required to build and execute test-suites in the LLVM's projects. Ideally the tests should work in standalone packages - built out-of-LLVM-sources - and with GCC/Clang, however the real life is less bright and this forced me to use Clang as the system compiler an all-in-one package in order to develop the work environment with the ability to build and execute unit tests.

There were four threads within LLVM:

• Broken std::call_once with libstdc++. This is an old and well-known bug, which was usually worked around with a homegrown implementation llvm::call_once. I've discovered that the llvm::call_once workaround isn't sufficient for the whole LLVM functionality, as std::call_once can be called internally inside the libstdc++ libraries - like within the C++11 futures interface. This bug has been solved by Joerg Sonnenberger in the ELF dynamic linker.
• Unportable shell construct hardcoded in tests ">&". This has been fixed upstream.
• LLVM JIT. The LLVM Memory generic allocator (or page mapper) was designed to freely map pages with any combination of the protection bits: R,W,X. This approach breaks on NetBSD with PaX MPROTECT and requires redesign of the interfaces. This is the continuation of the past month AllocateRWX and ReleaseRWX compatibility with NetBSD improvements. I've prepared few variations of local patches addressing these issues and it's still open for discussion with upstream. My personal preference is to remove the current API entirely and introduce a newer one with narrowed down functionality to swap between readable (R--), writable (RW-) and executable (R-X) memory pages. This would effectively enforce W^X.
• Sanitizers support. Right now, I keep the patches locally in order to upstream the common sanitizer code in compiler-rt.

The LLVM JIT API is the last cause of unexpected failures in check-llvm. This breaks MCJIT, ORCJIT and ExecutionEngine libraries and causes around 200 unexpected failures within tests.

Clang

I've upstreamed a patch that enables ubsan and asan on Clang's frontend for NetBSD/amd64. This support isn't complete, and requires sanitizers' support code upstreamed to compiler-rt.

compiler-rt

The current compiler-rt tasks can be divided into:

1. upstream sanitizer common code shared with POSIX platforms
2. upstream sanitizer common code shared with Linux and FreeBSD
3. upstream sanitizer common code shared with FreeBSD
4. upstream sanitizer common code specific to NetBSD
5. build, execute and pass tests for sanitizer common code in check-santizer

This means that ubsan, asan and the rest of the specific sanitizers wait in queue.

All the mentioned tasks are being worked on simultaneously, with a soft goal to finish them one after another from the first to the last one.

The last point with check-sanitizer unveiled so far two generic bugs on NetBSD:

• Return errno EFAULT instead of EACCES on memory fault with read(2)/write(2)-like syscalls.
• Honor PTHREAD_DESTRUCTOR_ITERATIONS in libpthread.

These bugs are not strictly real bugs, but they were introducing needless differences with other modern POSIX systems. The fixes were introduced by Christos Zoulas and backported to NetBSD-8.

Plan for the next milestone

I have decided not to open new issues in with the coming month and focus on upstreaming the remaining LLVM code. The roadmap for the next month is to continue working on the goals of the previous months. std::call_once is an example that every delayed bug keeps biting again and again in future.

LLVM 5.0.0 is planned to be released this month (August) and there is a joint motivation with the upstream maintainer to push compatibility fixes for LLVM JIT. There is an option to submit a workaround now and introduce refactoring for the trunk and next version (6.0.0).

This work was sponsored by The NetBSD Foundation.

The NetBSD Foundation is a non-profit organization and welcomes any donations to help us continue funding projects and services to the open-source community. Please consider visiting the following URL, and chip in what you can:

http://netbsd.org/donations/#how-to-donate

In this blog post series I will discuss about SUBPACKAGES work done during Google Summer of Code 2017.

In this first part I'll briefly introduce what are SUBPACKAGES, why and when can be useful and finally we'll give a quick look to a trivial pkgsrc package that uses them. At the end we'll also dive a bit on parts of the pkgsrc infrastructure that needed to be adjusted for implementing that.

Introduction

SUBPACKAGES (on some package systems they are known as multi-packages, but this term for pkgsrc is already used by packages that can be built against several versions (e.g. Python, PHP, Ruby packages)) consist in generating multiple binary packages from a single pkgsrc package. For example, from a pkgsrc package - local/frobnitzem - we will see how to generate three separate binary packages: frobnitzem-foo, frobnitzem-bar and frobnitzem-baz.

This can be useful to separate several components of binary packages (and avoid to run the extract and configure phase two times!), for debugpkgs (so that all *.debug files containing debug symbols are contained in a separate -debugpkg package that can be installed only when it is needed), etc..

A simple SUBPACKAGES package: frobnitzem!

To understand how SUBPACKAGES works and can be useful let's start to see an example of it in practice: frobnitzem.

frobnitzem is a trivial package that just install three scripts in ${PREFIX}/bin, let's see it:

% cd pkgsrc/local/frobnitzem
% tree
.
|-- DESCR
|-- Makefile
|-- PLIST
`-- files
    `-- frobnitzem
        |-- frobnitzem-bar
        |-- frobnitzem-baz
        `-- frobnitzem-foo

2 directories, 6 files
% find . -type f | xargs tail -n +1
==> ./Makefile <==
# $NetBSD$

DISTNAME=   frobnitzem-0
CATEGORIES= local
MASTER_SITES=   # empty
DISTFILES=  # empty

MAINTAINER= leot%NetBSD.org@localhost
HOMEPAGE=   http://netbsd.org/~leot/gsoc2017-diary/
COMMENT=    Simple subpackages example
LICENSE=    public-domain

FILESDIR=   ${.CURDIR}/../../local/frobnitzem/files

WRKSRC=     ${WRKDIR}/frobnitzem

NO_BUILD=   yes

do-extract:
    ${CP} -r ${FILESDIR}/frobnitzem ${WRKDIR}

do-install:
    ${INSTALL_SCRIPT_DIR} ${DESTDIR}${PREFIX}/bin
    ${INSTALL_SCRIPT} ${WRKSRC}/frobnitzem-foo ${DESTDIR}${PREFIX}/bin
    ${INSTALL_SCRIPT} ${WRKSRC}/frobnitzem-bar ${DESTDIR}${PREFIX}/bin
    ${INSTALL_SCRIPT} ${WRKSRC}/frobnitzem-baz ${DESTDIR}${PREFIX}/bin

.include "../../mk/bsd.pkg.mk"

==> ./files/frobnitzem/frobnitzem-bar <==
#!/bin/sh

echo "bar"

==> ./files/frobnitzem/frobnitzem-baz <==
#!/bin/sh

echo "baz"

==> ./files/frobnitzem/frobnitzem-foo <==
#!/bin/sh

echo "foo"

==> ./PLIST <==
@comment $NetBSD$
bin/frobnitzem-bar
bin/frobnitzem-baz
bin/frobnitzem-foo

==> ./DESCR <==
frobnitzem, collection of foo, bar, baz scripts.

(Or, a bit more seriously this is just a very simple package to
test subpackages support!)

Nothing fancy, just three simple scripts, frobnitzem-{bar,baz,foo} that will respectively print to the standard output bar, baz and foo. Let's build and install the frobnitzem package:

% make install
===> Installing dependencies for frobnitzem-0                       
===> Overriding tools for frobnitzem-0                              
===> Extracting for frobnitzem-0  
[...]
===> Installing for frobnitzem-0  
[...]
===> Installing binary package of frobnitzem-0                      
[...]

And now let's try scripts installed as part of the frobnitzem package:

% foreach w (bar baz foo)
... frobnitzem-$w
... end
bar
baz
foo

Okay, as we expected. Despite frobnitzem-{foo,bar,baz} don't do anything particularly useful we can split the frobnitzem-0 package in three separate subpackages: frobnitzem-foo-0, frobnitzem-bar-0 and frobnitzem-baz-0 (they provides different functionalities and can also coexist if they're in separated binary packages).

To do that we need to slighty adjust Makefile, split the PLIST in PLIST.{foo,bar,baz} (one for each separate subpackage), split the DESCR in DESCR.{foo,bar,baz}. So, at the end in local/frobnitzem we'll have:

% tree
.
|-- DESCR.bar
|-- DESCR.baz
|-- DESCR.foo
|-- Makefile
|-- PLIST.bar
|-- PLIST.baz
|-- PLIST.foo
`-- files
    `-- frobnitzem
        |-- frobnitzem-bar
        |-- frobnitzem-baz
        `-- frobnitzem-foo

2 directories, 10 files

Splitting DESCR and PLIST

DESCR and PLIST splits are straightforward. We just provide a separate DESCR.<spkg> for each subpackage, e.g. for the foo subpackage:

% cat DESCR.foo
frobnitzem, collection of foo, bar, baz scripts.

(Or, a bit more seriously this is just a very simple package to
test subpackages support!)

This package provide the foo functionalities.

Similarly, regarding PLISTs, we just provide a separate PLIST.<spkg> for each subpackage, e.g. for the foo subpackage:

% cat PLIST.foo
@comment $NetBSD$
bin/frobnitzem-foo

Makefile changes

In Makefile we'll need to list all SUBPACKAGES hence we'll add the following line as first paragraph:

SUBPACKAGES=    foo bar baz

We'll then need to define a PKGNAME.<spkg> for each subpackages:

PKGNAME.foo=    frobnitzem-foo-0
PKGNAME.bar=    frobnitzem-bar-0
PKGNAME.baz=    frobnitzem-baz-0

...and similarly COMMENT variable should be defined for each subpackage via COMMENT.<spkg>:

COMMENT.foo=    Simple subpackages example (foo)
COMMENT.bar=    Simple subpackages example (bar)
COMMENT.baz=    Simple subpackages example (baz)

To recap here how we have adjusted Makefile, all the other lines rest unchanged:

% sed '/LICENSE/q' < Makefile
# $NetBSD$

SUBPACKAGES=    foo bar baz

DISTNAME=       frobnitzem-0
PKGNAME.foo=    frobnitzem-foo-0
PKGNAME.bar=    frobnitzem-bar-0
PKGNAME.baz=    frobnitzem-baz-0
MASTER_SITES=   # empty
DISTFILES=      # empty
CATEGORIES=     local

MAINTAINER=     leot%NetBSD.org@localhost
HOMEPAGE=       http://netbsd.org/~leot/gsoc2017-diary/
COMMENT.foo=    Simple subpackages example (foo)
COMMENT.bar=    Simple subpackages example (bar)
COMMENT.baz=    Simple subpackages example (baz)
LICENSE=        public-domain

Finally we can install it^Wthem! The usual make install will generate three binary packages (frobnitzem-foo-0.tgz, frobnitzem-bar-0.tgz, frobnitzem-baz-0.tgz) and install all of them:

% make install
===> Installing dependencies for frobnitzem-0
[...]
===> Overriding tools for frobnitzem-0
===> Extracting for frobnitzem-0
[...]
===> Installing for frobnitzem-0
[...]
=> Creating binary package /home/leot/repos/netbsd-github/pkgsrc/packages/All/frobnitzem-foo-0.tgz
=> Creating binary package /home/leot/repos/netbsd-github/pkgsrc/packages/All/frobnitzem-bar-0.tgz
=> Creating binary package /home/leot/repos/netbsd-github/pkgsrc/packages/All/frobnitzem-baz-0.tgz
[...]
===> Installing binary package of frobnitzem-foo-0
===> Installing binary package of frobnitzem-bar-0
===> Installing binary package of frobnitzem-baz-0
[...]

Now we can try them and use pkg_info(1) to get some information about them:

% frobnitzem-foo
foo
% pkg_info -Fe /usr/pkg/bin/frobnitzem-foo
frobnitzem-foo-0
% pkg_info frobnitzem-baz
Information for frobnitzem-baz-0:

Comment:
Simple subpackages example (baz)

Description:
frobnitzem, collection of foo, bar, baz scripts.

(Or, a bit more seriously this is just a very simple package to
test subpackages support!)

This package provide the baz functionalities.

Homepage:
http://netbsd.org/~leot/gsoc2017-diary/
% pkg_info -L frobnitzem-bar
Information for frobnitzem-bar-0:

Files:
/usr/pkg/bin/frobnitzem-bar

So we can see that make install actually installed three different binary packages.

To deinstall all SUBPACKAGES we can run make deinstall in the local/frobnitzem directory (that will remove all subpackages) or we can just manually invoke pkg_delete(1).

An high-level look at how SUBPACKAGES support is implemented

Most of the changes needed are in mk/pkgformat/pkg/ hierarchy (previously known as mk/flavour and then renamed and generalized to other package formats during Anton Panev's Google Summer of Code 2011).

The code in mk/pkgformat/${PKG_FORMAT}/ handle the interaction of pkgsrc with the particular ${PKG_FORMAT}, e.g. for pkg populate meta-data files used by pkg_create(1), install/delete packages via pkg_add(1), and pkg_delete(1), etc.

For more information mk/pkgformat/README is a good introduction to pkgformat hierarchy.

Most of the changes done respect the following template:

.if !empty(SUBPACKAGES)
.  for _spkg_ in ${SUBPACKAGES}
[... code that handles SUBPACKAGES case ...]
.  endfor
.else   # !SUBPACKAGES
[... existing (and usually completely unmodified) code ...]
.endif  # SUBPACKAGES

In particular, in mk/pkgformat/pkg/ targets were adjusted to create/install/deinstall/etc. all subpackages.

Apart mk/pkgformat other changes were needed in mk/install/install.mk in order to adjust the install phase for SUBPACKAGES.

Regarding PLIST.<spkg> handling mk/plist/plist.mk needed some adjustments to honor each PLIST per-subpackage.

mk/bsd.pkg.mk needed to be adjusted too in order to honor several per-subpackage variables (the *.<spkg> ones) and per-subpackage DESCR.<spkg>.

Conclusion

In this first part of this blog post series we have seen what are SUBPACKAGES, when and why they can be useful.

We have then seen a practical example of them taking a very trivial package and learned how to "subpackage-ify" it.

Then we have described - from an high-level perspective - the changes needed to the pkgsrc infrastructure for the SUBPACKAGES features that we have used. If you are more interested in them please give a look to the pkgsrc debugpkg branch that contains all work done described in this blog post.

In the next part we will see how to handle *DEPENDS and buildlink3 inclusion for subpackages.

I would like to thanks Google for organizing Google Summer of Code, the entire The NetBSD Foundation and in particular my mentors Taylor R. Campbell, William J. Coldwell and Thomas Klausner for providing precious guidance during these three months. A special thank you also to Jörg Sonnenberger who provided very useful suggestions. Thank you!

In this blog post series I will discuss about SUBPACKAGES work done during Google Summer of Code 2017.

In this first part I'll briefly introduce what are SUBPACKAGES, why and when can be useful and finally we'll give a quick look to a trivial pkgsrc package that uses them. At the end we'll also dive a bit on parts of the pkgsrc infrastructure that needed to be adjusted for implementing that.

Introduction

SUBPACKAGES (on some package systems they are known as multi-packages, but this term for pkgsrc is already used by packages that can be built against several versions (e.g. Python, PHP, Ruby packages)) consist in generating multiple binary packages from a single pkgsrc package. For example, from a pkgsrc package - local/frobnitzem - we will see how to generate three separate binary packages: frobnitzem-foo, frobnitzem-bar and frobnitzem-baz.

This can be useful to separate several components of binary packages (and avoid to run the extract and configure phase two times!), for debugpkgs (so that all *.debug files containing debug symbols are contained in a separate -debugpkg package that can be installed only when it is needed), etc..

A simple SUBPACKAGES package: frobnitzem!

To understand how SUBPACKAGES works and can be useful let's start to see an example of it in practice: frobnitzem.

frobnitzem is a trivial package that just install three scripts in ${PREFIX}/bin, let's see it:

% cd pkgsrc/local/frobnitzem
% tree
.
|-- DESCR
|-- Makefile
|-- PLIST
`-- files
    `-- frobnitzem
        |-- frobnitzem-bar
        |-- frobnitzem-baz
        `-- frobnitzem-foo

2 directories, 6 files
% find . -type f | xargs tail -n +1
==> ./Makefile <==
# $NetBSD$

DISTNAME=   frobnitzem-0
CATEGORIES= local
MASTER_SITES=   # empty
DISTFILES=  # empty

MAINTAINER= leot%NetBSD.org@localhost
HOMEPAGE=   http://netbsd.org/~leot/gsoc2017-diary/
COMMENT=    Simple subpackages example
LICENSE=    public-domain

FILESDIR=   ${.CURDIR}/../../local/frobnitzem/files

WRKSRC=     ${WRKDIR}/frobnitzem

NO_BUILD=   yes

do-extract:
    ${CP} -r ${FILESDIR}/frobnitzem ${WRKDIR}

do-install:
    ${INSTALL_SCRIPT_DIR} ${DESTDIR}${PREFIX}/bin
    ${INSTALL_SCRIPT} ${WRKSRC}/frobnitzem-foo ${DESTDIR}${PREFIX}/bin
    ${INSTALL_SCRIPT} ${WRKSRC}/frobnitzem-bar ${DESTDIR}${PREFIX}/bin
    ${INSTALL_SCRIPT} ${WRKSRC}/frobnitzem-baz ${DESTDIR}${PREFIX}/bin

.include "../../mk/bsd.pkg.mk"

==> ./files/frobnitzem/frobnitzem-bar <==
#!/bin/sh

echo "bar"

==> ./files/frobnitzem/frobnitzem-baz <==
#!/bin/sh

echo "baz"

==> ./files/frobnitzem/frobnitzem-foo <==
#!/bin/sh

echo "foo"

==> ./PLIST <==
@comment $NetBSD$
bin/frobnitzem-bar
bin/frobnitzem-baz
bin/frobnitzem-foo

==> ./DESCR <==
frobnitzem, collection of foo, bar, baz scripts.

(Or, a bit more seriously this is just a very simple package to
test subpackages support!)

Nothing fancy, just three simple scripts, frobnitzem-{bar,baz,foo} that will respectively print to the standard output bar, baz and foo. Let's build and install the frobnitzem package:

% make install
===> Installing dependencies for frobnitzem-0                       
===> Overriding tools for frobnitzem-0                              
===> Extracting for frobnitzem-0  
[...]
===> Installing for frobnitzem-0  
[...]
===> Installing binary package of frobnitzem-0                      
[...]

And now let's try scripts installed as part of the frobnitzem package:

% foreach w (bar baz foo)
... frobnitzem-$w
... end
bar
baz
foo

Okay, as we expected. Despite frobnitzem-{foo,bar,baz} don't do anything particularly useful we can split the frobnitzem-0 package in three separate subpackages: frobnitzem-foo-0, frobnitzem-bar-0 and frobnitzem-baz-0 (they provides different functionalities and can also coexist if they're in separated binary packages).

To do that we need to slighty adjust Makefile, split the PLIST in PLIST.{foo,bar,baz} (one for each separate subpackage), split the DESCR in DESCR.{foo,bar,baz}. So, at the end in local/frobnitzem we'll have:

% tree
.
|-- DESCR.bar
|-- DESCR.baz
|-- DESCR.foo
|-- Makefile
|-- PLIST.bar
|-- PLIST.baz
|-- PLIST.foo
`-- files
    `-- frobnitzem
        |-- frobnitzem-bar
        |-- frobnitzem-baz
        `-- frobnitzem-foo

2 directories, 10 files

Splitting DESCR and PLIST

DESCR and PLIST splits are straightforward. We just provide a separate DESCR.<spkg> for each subpackage, e.g. for the foo subpackage:

% cat DESCR.foo
frobnitzem, collection of foo, bar, baz scripts.

(Or, a bit more seriously this is just a very simple package to
test subpackages support!)

This package provide the foo functionalities.

Similarly, regarding PLISTs, we just provide a separate PLIST.<spkg> for each subpackage, e.g. for the foo subpackage:

% cat PLIST.foo
@comment $NetBSD$
bin/frobnitzem-foo

Makefile changes

In Makefile we'll need to list all SUBPACKAGES hence we'll add the following line as first paragraph:

SUBPACKAGES=    foo bar baz

We'll then need to define a PKGNAME.<spkg> for each subpackages:

PKGNAME.foo=    frobnitzem-foo-0
PKGNAME.bar=    frobnitzem-bar-0
PKGNAME.baz=    frobnitzem-baz-0

...and similarly COMMENT variable should be defined for each subpackage via COMMENT.<spkg>:

COMMENT.foo=    Simple subpackages example (foo)
COMMENT.bar=    Simple subpackages example (bar)
COMMENT.baz=    Simple subpackages example (baz)

To recap here how we have adjusted Makefile, all the other lines rest unchanged:

% sed '/LICENSE/q' < Makefile
# $NetBSD$

SUBPACKAGES=    foo bar baz

DISTNAME=       frobnitzem-0
PKGNAME.foo=    frobnitzem-foo-0
PKGNAME.bar=    frobnitzem-bar-0
PKGNAME.baz=    frobnitzem-baz-0
MASTER_SITES=   # empty
DISTFILES=      # empty
CATEGORIES=     local

MAINTAINER=     leot%NetBSD.org@localhost
HOMEPAGE=       http://netbsd.org/~leot/gsoc2017-diary/
COMMENT.foo=    Simple subpackages example (foo)
COMMENT.bar=    Simple subpackages example (bar)
COMMENT.baz=    Simple subpackages example (baz)
LICENSE=        public-domain

Finally we can install it^Wthem! The usual make install will generate three binary packages (frobnitzem-foo-0.tgz, frobnitzem-bar-0.tgz, frobnitzem-baz-0.tgz) and install all of them:

% make install
===> Installing dependencies for frobnitzem-0
[...]
===> Overriding tools for frobnitzem-0
===> Extracting for frobnitzem-0
[...]
===> Installing for frobnitzem-0
[...]
=> Creating binary package /home/leot/repos/netbsd-github/pkgsrc/packages/All/frobnitzem-foo-0.tgz
=> Creating binary package /home/leot/repos/netbsd-github/pkgsrc/packages/All/frobnitzem-bar-0.tgz
=> Creating binary package /home/leot/repos/netbsd-github/pkgsrc/packages/All/frobnitzem-baz-0.tgz
[...]
===> Installing binary package of frobnitzem-foo-0
===> Installing binary package of frobnitzem-bar-0
===> Installing binary package of frobnitzem-baz-0
[...]

Now we can try them and use pkg_info(1) to get some information about them:

% frobnitzem-foo
foo
% pkg_info -Fe /usr/pkg/bin/frobnitzem-foo
frobnitzem-foo-0
% pkg_info frobnitzem-baz
Information for frobnitzem-baz-0:

Comment:
Simple subpackages example (baz)

Description:
frobnitzem, collection of foo, bar, baz scripts.

(Or, a bit more seriously this is just a very simple package to
test subpackages support!)

This package provide the baz functionalities.

Homepage:
http://netbsd.org/~leot/gsoc2017-diary/
% pkg_info -L frobnitzem-bar
Information for frobnitzem-bar-0:

Files:
/usr/pkg/bin/frobnitzem-bar

So we can see that make install actually installed three different binary packages.

To deinstall all SUBPACKAGES we can run make deinstall in the local/frobnitzem directory (that will remove all subpackages) or we can just manually invoke pkg_delete(1).

An high-level look at how SUBPACKAGES support is implemented

Most of the changes needed are in mk/pkgformat/pkg/ hierarchy (previously known as mk/flavour and then renamed and generalized to other package formats during Anton Panev's Google Summer of Code 2011).

The code in mk/pkgformat/${PKG_FORMAT}/ handle the interaction of pkgsrc with the particular ${PKG_FORMAT}, e.g. for pkg populate meta-data files used by pkg_create(1), install/delete packages via pkg_add(1), and pkg_delete(1), etc.

For more information mk/pkgformat/README is a good introduction to pkgformat hierarchy.

Most of the changes done respect the following template:

.if !empty(SUBPACKAGES)
.  for _spkg_ in ${SUBPACKAGES}
[... code that handles SUBPACKAGES case ...]
.  endfor
.else   # !SUBPACKAGES
[... existing (and usually completely unmodified) code ...]
.endif  # SUBPACKAGES

In particular, in mk/pkgformat/pkg/ targets were adjusted to create/install/deinstall/etc. all subpackages.

Apart mk/pkgformat other changes were needed in mk/install/install.mk in order to adjust the install phase for SUBPACKAGES.

Regarding PLIST.<spkg> handling mk/plist/plist.mk needed some adjustments to honor each PLIST per-subpackage.

mk/bsd.pkg.mk needed to be adjusted too in order to honor several per-subpackage variables (the *.<spkg> ones) and per-subpackage DESCR.<spkg>.

Conclusion

In this first part of this blog post series we have seen what are SUBPACKAGES, when and why they can be useful.

We have then seen a practical example of them taking a very trivial package and learned how to "subpackage-ify" it.

Then we have described - from an high-level perspective - the changes needed to the pkgsrc infrastructure for the SUBPACKAGES features that we have used. If you are more interested in them please give a look to the pkgsrc debugpkg branch that contains all work done described in this blog post.

In the next part we will see how to handle *DEPENDS and buildlink3 inclusion for subpackages.

I would like to thanks Google for organizing Google Summer of Code, the entire The NetBSD Foundation and in particular my mentors Taylor R. Campbell, William J. Coldwell and Thomas Klausner for providing precious guidance during these three months. A special thank you also to Jörg Sonnenberger who provided very useful suggestions. Thank you!

On behalf of the NetBSD release engineering team, it is my distinct pleasure to announce that the third release candidate of NetBSD 7.0 is now available for download. As the old Schoolhouse Rock song tells us, three is a magic number. We're hoping that RC3 will be the magic/last release candidate of 7.0.

Some of the changes since 7.0_RC2 are:

• Add a resize_root boot operation (disabled by default). If resize_root=YES in rc.conf then the system attempts to resize the root file system to fill its partition prior to mounting read-write.
• Enable SMP on Raspberry Pi 2.
• evbarm: Rename beagleboard.img to armv7.img. The new image includes the same kernels as beagleboard.img plus support for Raspberry Pi 2, ODROID-C1, Cubieboard2, Cubietruck, Hummingbird A31, and Banana Pi.
• evbarm: For armv7.img and rpi.img, enable support for auto-growing the SD card root filesystem.
• Various DRMKMS stability improvements.
• Avoid kernel panic on starting X on Intel 855GM machines. PR kern/49875.
• Fix an uninitalized lock panic when trying to start a Xen kernel with LOCKDEBUG and more than one vcpu.
• Fix an issue where x86 microcode updates could fail if memory was not 16 byte aligned.
• Fix an IPFilter panic.
• macppc: Fix ofwboot failure on PowerPC 603 machines.
• OpenSSH: Apply fix for CVE-2015-5600.
• Fix an issue where fsck_ffs didn't properly handle replaying a WAPBL journal on disks with non-DEV_BSIZE sectors.
• Fix error in the setlist scripts that resulted in /bin/[ being missing from the base set. PR bin/50109.
• Make libperfuse handle resource limits properly.
• Make uplcom(4) suspend/resume.
• Fix case where coretemp(4) didn't attach on some newer CPUs.
• Avoid hanging on some machines after attaching ehci(4).
• Fix crash on oboe(4) attach. PR port-i386/50076.
• mountd(8): Write the correct pid is written to pidfile. PR bin/50125.
• patch(1): Guard against malicious filenames and substitution commands.
• patch(1): Drop SCCS support.
• ypserv(8): When transferring a secure map to a slave server, don't lose the secure flag. PR bin/50057.
• resize_ffs(8):
• Make get_dev_size work on regular files too.
• Add -c to check to see if grow/shrink is required.
• Divide by DEV_BSIZE when returning size of file.
• Handle case in grow() where last cylinder group is too small for ufs2.
• Add a -p flag, which displays a progress bar.
• disklabel(8): Fix a bug that resulted in sun2 liveimages being non-bootable.
• Update libXi to 1.7.4.
• Update BIND to 9.10.2-P3.

The full list of changes can be found near the bottom of http://ftp.NetBSD.org/pub/NetBSD/NetBSD-7.0_RC3/CHANGES-7.0

Binaries of NetBSD 7.0_RC3 are available for download at:

http://ftp.NetBSD.org/pub/NetBSD/NetBSD-7.0_RC3/

Those who prefer to build from source can either use the netbsd-7-0-RC3 tag or follow the netbsd-7 branch.

As always, please let us know how 7.0_RC3 works for you! Any feedback, whether good or bad, is welcome. Problems should be reported through the usual channels (submit a PR or write to the appropriate list). More general feedback is welcome at releng@NetBSD.org.

If everything goes as planned, the pkgsrc-wip CVS repository will be converted to git and hosted on NetBSD.org by end of September.

In July we cleaned up the repository so it can be converted easily; since then we've been working on the infrastructure and details of the conversion. The main tasks are now finished. We have set up a server for it which hosts a preliminary git conversion (on wip.pkgsrc.org) of the CVS repository, created a mailing list for the commit messages, pkgsrc-wip-changes, and prepared a list of authors for the conversion.

We've also provided a conversion of pkgsrc-wip based on data from July so that it can be tested on (nearly) live data. If you are interested in beta-testing the setup, send a suggestion for a username and an SSH public key to me. Details on how to test are on the NetBSD wiki but will probably change some more over time.

We still need help for the conversion: if you are or were a wip contributor, please let me know by September 15 what name and email to use for the conversion from CVS to git. This conversion will not be done again, so after that date, the commit data will be final.

The NVIDIA Jetson TK1 is a quad-core ARMv7 development board that features an NVIDIA Tegra K1 (32-bit) SoC (quad-core Cortex-A15 @ 2.3GHz), 2GB RAM, gigabit ethernet, SATA, HDMI, mini-PCIE, and more.

Since my last status update on the port, HDMI video and audio support have been added along with a handful of stability fixes.

NetBSD -current includes support for this board with the JETSONTK1 kernel. The following hardware is supported:

• Cortex-A15 (multiprocessor)
• CPU frequency scaling
• ARM generic timer
• Clock and reset controller
• GPIO controller
• MPIO / pinmux controller
• Memory controller
• Power management controller
• I2C controller
• UART serial console
• Watchdog timer
• SDMMC controller
• USB 2.0 controller
• AHCI SATA controller
• HD audio controller (HDMI audio)
• HDMI framebuffer console
• PCI express controller, including mini-PCIE slot
• On-board Realtek 8111G gigabit ethernet
• Serial EEPROM
• Temperature sensor
• RF kill switch
• Power button

Of course, Xorg works too:

See the NetBSD/evbarm on NVIDIA Tegra wiki page for more details.

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 7.99.20 (JETSONTK1) #189: Sat Jul 25 12:47:31 ADT 2015
    jmcneill@megatron.local:/Users/jmcneill/netbsd/src/sys/arch/evbarm/compile/obj/JETSONTK1
total memory = 2047 MB
avail memory = 2021 MB
sysctl_createv: sysctl_create(machine_arch) returned 17
timecounter: Timecounters tick every 10.000 msec
mainbus0 (root)
cpu0 at mainbus0 core 0: 2292 MHz Cortex-A15 r3p3 (Cortex V7A core)
cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu0: sctlr: 0xc51c7d
cpu0: actlr: 0x80000041
cpu0: revidr: 0
cpu0: mpidr: 0x80000000
cpu0: isar: [0]=0x2101110 [1]=0x13112111 [2]=0x21232041 [3]=0x11112131, [4]=0x10011142, [5]=0
cpu0: mmfr: [0]=0x10201105 [1]=0x40000000 [2]=0x1240000 [3]=0x2102211
cpu0: pfr: [0]=0x1131 [1]=0x11011
cpu0: 32KB/64B 2-way L1 PIPT Instruction cache
cpu0: 32KB/64B 2-way write-back-locking-C L1 PIPT Data cache
cpu0: 2048KB/64B 16-way write-through L2 PIPT Unified cache
vfp0 at cpu0: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
vfp0: mvfr: [0]=0x10110222 [1]=0x11111111
cpu1 at mainbus0 core 1
cpu2 at mainbus0 core 2
cpu3 at mainbus0 core 3
armperiph0 at mainbus0
armgic0 at armperiph0: Generic Interrupt Controller, 192 sources (183 valid)
armgic0: 32 Priorities, 160 SPIs, 7 PPIs, 16 SGIs
armgtmr0 at armperiph0: ARMv7 Generic 64-bit Timer (12000 kHz)
armgtmr0: interrupting on irq 27
timecounter: Timecounter "armgtmr0" frequency 12000000 Hz quality 500
tegraio0 at mainbus0: Tegra K1 (T124)
tegracar0 at tegraio0: CAR
tegracar0: PLLX = 2292000000 Hz
tegracar0: PLLC = 88000000 Hz
tegracar0: PLLE = 292968 Hz
tegracar0: PLLU = 480000000 Hz
tegracar0: PLLP0 = 408000000 Hz
tegracar0: PLLD2 = 594000000 Hz
tegragpio0 at tegraio0: GPIO
gpio0 at tegragpio0 (A): 8 pins
gpio1 at tegragpio0 (B): 8 pins
gpio2 at tegragpio0 (C): 8 pins
gpio3 at tegragpio0 (D): 8 pins
gpio4 at tegragpio0 (E): 8 pins
gpio5 at tegragpio0 (F): 8 pins
gpio6 at tegragpio0 (G): 8 pins
gpio7 at tegragpio0 (H): 8 pins
gpio8 at tegragpio0 (I): 8 pins
gpio9 at tegragpio0 (J): 8 pins
gpio10 at tegragpio0 (K): 8 pins
gpio11 at tegragpio0 (L): 8 pins
gpio12 at tegragpio0 (M): 8 pins
gpio13 at tegragpio0 (N): 8 pins
gpio14 at tegragpio0 (O): 8 pins
gpio15 at tegragpio0 (P): 8 pins
gpio16 at tegragpio0 (Q): 8 pins
gpiobutton0 at gpio16 pins 0: Power button
gpio17 at tegragpio0 (R): 8 pins
gpio18 at tegragpio0 (S): 8 pins
gpio19 at tegragpio0 (T): 8 pins
gpio20 at tegragpio0 (U): 8 pins
gpio21 at tegragpio0 (V): 8 pins
gpio22 at tegragpio0 (W): 8 pins
gpio23 at tegragpio0 (X): 8 pins
gpiorfkill0 at gpio23 pins 7
gpio24 at tegragpio0 (Y): 8 pins
gpio25 at tegragpio0 (Z): 8 pins
gpio26 at tegragpio0 (AA): 8 pins
gpio27 at tegragpio0 (BB): 8 pins
gpio28 at tegragpio0 (CC): 8 pins
gpio29 at tegragpio0 (DD): 8 pins
gpio30 at tegragpio0 (EE): 8 pins
tegratimer0 at tegraio0: Timers
tegratimer0: default watchdog period is 10 seconds
tegramc0 at tegraio0: MC
tegrapmc0 at tegraio0: PMC
tegraxusbpad0 at tegraio0: XUSB PADCTL
tegrampio0 at tegraio0: MPIO
tegrai2c0 at tegraio0 port 0: I2C1
tegrai2c0: interrupting on irq 70
iic0 at tegrai2c0: I2C bus
seeprom0 at iic0 addr 0x56: AT24Cxx or compatible EEPROM: size 256
titemp0 at iic0 addr 0x4c: TMP451
tegrai2c1 at tegraio0 port 1: I2C2
tegrai2c1: interrupting on irq 116
iic1 at tegrai2c1: I2C bus
tegrai2c2 at tegraio0 port 2: I2C3
tegrai2c2: interrupting on irq 124
iic2 at tegrai2c2: I2C bus
tegrai2c3 at tegraio0 port 3: I2C4
tegrai2c3: interrupting on irq 152
iic3 at tegrai2c3: I2C bus
ddc0 at iic3 addr 0x50: DDC
tegrai2c4 at tegraio0 port 4: I2C5
tegrai2c4: interrupting on irq 85
iic4 at tegrai2c4: I2C bus
com3 at tegraio0 port 3: ns16550a, working fifo
com3: console
tegrartc0 at tegraio0: RTC
sdhc2 at tegraio0 port 2: SDMMC3
sdhc2: interrupting on irq 51
sdhc2: SDHC 4.0, rev 3, DMA, 48000 kHz, 3.0V 3.3V, 4096 byte blocks
sdmmc2 at sdhc2 slot 0
ahcisata0 at tegraio0: SATA
ahcisata0: interrupting on irq 55
ahcisata0: AHCI revision 1.31, 2 ports, 32 slots, CAP 0xe620ff01<PSC,SSC,PMD,ISS=0x2=Gen2,SAL,SALP,SSNTF,SNCQ,S64A>
atabus0 at ahcisata0 channel 0
hdaudio0 at tegraio0: HDA
hdaudio0: interrupting on irq 113
hdafg0 at hdaudio0: NVIDIA Tegra124 HDMI
hdafg0: HDMI00 8ch: Digital Out [Jack]
hdafg0: 8ch/0ch 48000Hz PCM16*
audio0 at hdafg0: full duplex, playback, capture, mmap, independent
ehci0 at tegraio0 port 0: USB1
ehci0: interrupting on irq 52
ehci0: EHCI version 1.10
ehci0: switching to host mode
usb0 at ehci0: USB revision 2.0
ehci1 at tegraio0 port 1: USB2
ehci1: interrupting on irq 53
ehci1: EHCI version 1.10
ehci1: switching to host mode
usb1 at ehci1: USB revision 2.0
ehci2 at tegraio0 port 2: USB3
ehci2: interrupting on irq 129
ehci2: EHCI version 1.10
ehci2: switching to host mode
usb2 at ehci2: USB revision 2.0
tegrahost1x0 at tegraio0: HOST1X
tegradc0 at tegraio0 port 0: DISPLAYA
tegradc1 at tegraio0 port 1: DISPLAYB
tegrahdmi0 at tegraio0: HDMI
tegrahdmi0: display connected
no data for est. mode 640x480x67
tegrahdmi0: connected to HDMI display
genfb0 at tegradc1 output tegrahdmi0
genfb0: framebuffer at 0x9ab00000, size 1920x1080, depth 32, stride 7680
wsdisplay0 at genfb0 kbdmux 1
wsmux1: connecting to wsdisplay0
wsdisplay0: screen 0-3 added (default, vt100 emulation)
tegrapcie0 at tegraio0: PCIE
tegrapcie0: interrupting on irq 130
pci0 at tegrapcie0 bus 0
pci0: memory space enabled, rd/line, rd/mult, wr/inv ok
ppb0 at pci0 dev 0 function 0: vendor 10de product 0e12 (rev. 0xa1)
ppb0: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x2 @ 5.0GT/s
ppb0: link is x1 @ 2.5GT/s
pci1 at ppb0 bus 1
pci1: memory space enabled, rd/line, wr/inv ok
athn0 at pci1 dev 0 function 0athn0: Atheros AR9285
athn0: rev 2 (1T1R), ROM rev 13, address 00:17:c4:d7:d0:58
athn0: interrupting at irq 130
athn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
athn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
ppb1 at pci0 dev 1 function 0: vendor 10de product 0e13 (rev. 0xa1)
ppb1: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x1 @ 5.0GT/s
ppb1: link is x1 @ 2.5GT/s
pci2 at ppb1 bus 2
pci2: memory space enabled, rd/line, wr/inv ok
re0 at pci2 dev 0 function 0: RealTek 8168/8111 PCIe Gigabit Ethernet (rev. 0x0c)
re0: interrupting at irq 130
re0: Ethernet address 00:04:4b:2f:51:a2
re0: using 512 tx descriptors
rgephy0 at re0 phy 7: RTL8251 1000BASE-T media interface, rev. 0
rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto
timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
cpu2: 2292 MHz Cortex-A15 r3p3 (Cortex V7A core)
cpu2: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu2: sctlr: 0xc51c7d
cpu2: actlr: 0x80000040
cpu2: revidr: 0
cpu2: mpidr: 0x80000002
cpu2: isar: [0]=0x2101110 [1]=0x13112111 [2]=0x21232041 [3]=0x11112131, [4]=0x10011142, [5]=0
cpu2: mmfr: [0]=0x10201105 [1]=0x40000000 [2]=0x1240000 [3]=0x2102211
cpu2: pfr: [0]=0x1131 [1]=0x11011
cpu2: 32KB/64B 2-way L1 PIPT Instruction cache
cpu2: 32KB/64B 2-way write-back-locking-C L1 PIPT Data cache
cpu2: 2048KB/64B 16-way write-through L2 PIPT Unified cache
vfp2 at cpu2: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
vfp2: mvfr: [0]=0x10110222 [1]=0x11111111
cpu1: 2292 MHz Cortex-A15 r3p3 (Cortex V7A core)
cpu1: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu1: sctlr: 0xc51c7d
cpu1: actlr: 0x80000040
cpu1: revidr: 0
cpu1: mpidr: 0x80000001
cpu1: isar: [0]=0x2101110 [1]=0x13112111 [2]=0x21232041 [3]=0x11112131, [4]=0x10011142, [5]=0
cpu1: mmfr: [0]=0x10201105 [1]=0x40000000 [2]=0x1240000 [3]=0x2102211
cpu1: pfr: [0]=0x1131 [1]=0x11011
cpu1: 32KB/64B 2-way L1 PIPT Instruction cache
cpu1: 32KB/64B 2-way write-back-locking-C L1 PIPT Data cache
cpu1: 2048KB/64B 16-way write-through L2 PIPT Unified cache
vfp1 at cpu1: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
vfp1: mvfr: [0]=0x10110222 [1]=0x11111111
cpu3: 2292 MHz Cortex-A15 r3p3 (Cortex V7A core)
cpu3: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu3: sctlr: 0xc51c7d
cpu3: actlr: 0x80000040
cpu3: revidr: 0
cpu3: mpidr: 0x80000003
cpu3: isar: [0]=0x2101110 [1]=0x13112111 [2]=0x21232041 [3]=0x11112131, [4]=0x10011142, [5]=0
cpu3: mmfr: [0]=0x10201105 [1]=0x40000000 [2]=0x1240000 [3]=0x2102211
cpu3: pfr: [0]=0x1131 [1]=0x11011
cpu3: 32KB/64B 2-way L1 PIPT Instruction cache
cpu3: 32KB/64B 2-way write-back-locking-C L1 PIPT Data cache
cpu3: 2048KB/64B 16-way write-through L2 PIPT Unified cache
vfp3 at cpu3: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
vfp3: mvfr: [0]=0x10110222 [1]=0x11111111
uhub0 at usb0: Tegra EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub0: 1 port with 1 removable, self powered
uhub1 at usb2: Tegra EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub1: 1 port with 1 removable, self powered
uhub2 at usb1: Tegra EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub2: 1 port with 1 removable, self powered
ahcisata0 port 0: device present, speed: 3.0Gb/s
ld1 at sdmmc2: <0x27:0x5048:SD64G:0x30:0x01ce4def:0x0dc>
ld1: 59504 MB, 7585 cyl, 255 head, 63 sec, 512 bytes/sect x 121864192 sectors
ld1: 4-bit width, bus clock 48.000 MHz
wd0 at atabus0 drive 0
wd0: <OCZ-AGILITY3>
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 111 GB, 232581 cyl, 16 head, 63 sec, 512 bytes/sect x 234441648 sectors
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA)
uhidev0 at uhub0 port 1 configuration 1 interface 0
uhidev0: Logitech USB Receiver, rev 2.00/29.00, addr 2, iclass 3/1
ukbd0 at uhidev0: 8 modifier keys, 6 key codes
wskbd0 at ukbd0 mux 1
wskbd0: connecting to wsdisplay0
uhidev1 at uhub0 port 1 configuration 1 interface 1
uhidev1: Logitech USB Receiver, rev 2.00/29.00, addr 2, iclass 3/1
uhidev1: 17 report ids
ums0 at uhidev1 reportid 2: 16 buttons, W and Z dirs
wsmouse0 at ums0 mux 0
uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0
uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0
uhid2 at uhidev1 reportid 16: input=6, output=6, feature=0
uhid3 at uhidev1 reportid 17: input=19, output=19, feature=0
boot device: ld1
root on ld1a dumps on ld1b
mountroot: trying smbfs...
mountroot: trying ntfs...
mountroot: trying nfs...
mountroot: trying msdos...
mountroot: trying ext2fs...
mountroot: trying ffs...
root file system type: ffs
kern.module.path=/stand/evbarm/7.99.20/modules
WARNING: preposterous TOD clock time
WARNING: using filesystem time
WARNING: CHECK AND RESET THE DATE!
init: copying out path `/sbin/init' 11
WARNING: module error: vfs load failed for `compat', error 2
WARNING: module error: vfs load failed for `compat', error 2
WARNING: module error: vfs load failed for `compat', error 2
WARNING: module error: vfs load failed for `compat', error 2
WARNING: module error: vfs load failed for `compat', error 2
WARNING: module error: vfs load failed for `compat', error 2
re0: link state UP (was UNKNOWN)
athn0: link state UP (was UNKNOWN)

On behalf of the NetBSD project, it is my pleasure to announce the second release candidate of NetBSD 7.0.

Some of the changes since 7.0_RC1 are:

• OpenSSL updated to 1.0.1p
• BIND updated to 9.10.2-P2
• IPSEC support is now included by default in Xen kernels
• Fix several security issues in calendar(1)
• installboot(8) now supports wedge names
• Fix a quota panic when using WAPBL (PR 49948)
• Fix a memory leak in the drm2 code
• Avoid an X crash on i915 DRMKMS
• Add a postinstall(8) check to ensure that /etc/man.conf reflects the modern mandoc world (PR 50020)
• Add a postinstall(8) check to ensure that /etc/fonts/fonts.conf is up to date
• tset(1): Fix handling of the erase character
• gdb(1): Fix attaching to a running process again after previously detaching
• NPF: handle unregistered interfaces correctly
• npfctl(8): Fix a NULL dereference
• zgrep(1): suppress the prefixing of filename on output when only one file is specified, to match grep(1)'s output
• Fix lrint(x) and llrint(x) when x is larger than 2**51 (PR 49690)
• Bump MAXTSIZ and MAXDSIZ on amiga, fixing gcc 4.8 execution
• Fix MKCTF=yes on drm2 kernels
• Make clock_t unsigned int everywhere, so it's the same on LP64 and IPL32 architectures
• arm: if halt is requested and there is no console, keep looping instead of rebooting
• sparc64: Fix booting of kernels with more than 4 MB combined .data and .bss segments
• powerpc: Fix occasional FPU register corruption (PR 50037)
• m68k: Fix atomic_cas_{8,16} and __sync_bool_compare_and_swap_{1,2,4} (PR 49995)

The full list of changes can be found near the bottom of http://ftp.NetBSD.org/pub/NetBSD/NetBSD-7.0_RC2/CHANGES-7.0

Binaries of NetBSD 7.0_RC2 are available for download at:

http://ftp.NetBSD.org/pub/NetBSD/NetBSD-7.0_RC2/

Those who prefer to build from source can either use the netbsd-7-0-RC2 tag or follow the netbsd-7 branch.

As always, please let us know how 7.0_RC2 works for you! Any feedback, whether good or bad, is welcome. Problems should be reported through the usual channels (submit a PR or write to the appropriate list). More general feedback is welcome at releng@NetBSD.org.

pkgsrcCon is the annual technical conference for people working on pkgsrc, a framework for building over 17,000 open source software packages. pkgsrc is the native package manager on NetBSD, SmartOS and Minix, and is portable across many different operating systems including Linux and Mac OS X.

The last year's pkgsrcCon 2016 event took place in Kraków, Poland.

Slides are available on the event site.

Video recordings are stored at https://archive.org/details/pkgsrcCon-2016.

We would like to thank the organizers, sponsors and promotion from the Jagiellonian University, The NetBSD Foundation, Programista Magazyn, OS World, and Subcarpathian BSD User Group.

pkgsrcCon is the annual technical conference for people working on pkgsrc, a framework for building over 17,000 open source software packages. pkgsrc is the native package manager on NetBSD, SmartOS and Minix, and is portable across many different operating systems including Linux and Mac OS X.

The last year's pkgsrcCon 2016 event took place in Kraków, Poland.

Slides are available on the event site.

Video recordings are stored at https://archive.org/details/pkgsrcCon-2016.

We would like to thank the organizers, sponsors and promotion from the Jagiellonian University, The NetBSD Foundation, Programista Magazyn, OS World, and Subcarpathian BSD User Group.

Over the last 30 days I was focusing on getting the environment to enable LLVM sanitizers and the Clang compiler on NetBSD. Meanwhile I pushed forward generic parts that were needing enhancements around pkgsrc and LLVM in general to ease the future LLDB work.

dogfood

When I have realized that in order to work on the LLVM sanitizers I need to use Clang as the compiler. A part of the compiler-rt (lowlevel LLVM compiler runtime library) has code specifically incompatible with GCC. It was mainly related to intrinsic instructions for atomic functions. I tried to research how much work is needed to port it to GCC. It happened to be non-trivial and I filed a bug on the LLVM bugzilla.

These circumstances made me to switch to Clang as the pkgsrc toolchain. I was using it to test the compilation of small bulks of packages and record build and compiler problems. To save time, I used ccache as my cache for builds.

My options in mk.conf(5):

PKGSRC_COMPILER=        ccache clang
CCACHE_BASE=            /usr/local
CCACHE_DIR=             /public/ccache_tmp
CCACHE_LOGFILE=         /tmp/ccache.txt
PKG_CC=                 clang
PKG_CXX=                clang++
CLANGBASE=              /usr/local
HAVE_LLVM=              yes

It's worth noting that ccache with pkgsrc won't check $HOME/.ccache for configuration, it must be placed in $CCACHE_DIR/ccache.conf.

The documented problems can be summarized as:

• Broken ccache in pkgsrc for C++11 packages.
  The pkgsrc framework started supporting C++ languages in the USE_LANGUAGES definition. Packages with newly added USE_LANGUAGES values (such as c++11) were not compiled with ccache because ccache.mk was not yet aware of such values. This broke support of these packages to set these values to be built with ccache. I've corrected it and introduced a new option CCACHE_LOGFILE to more easily track execution of ccache and detect errors.
• Broken ccache in pkgsrc for a custom toolchain.
  ccache tries finding a real-compiler looking for it in $PATH. When I have built clang within pkgsrc to work on it (installed into /usr/pkg), and I had my main toolchain in /usr/local it was picking the one from /usr/pkg for new builds and it resulted in cache-misses for new builds. I have installed a fix for it to pass ccache specific PATH to always find the appropriate compiler.
• Header <execinfo.h> cannot be included on Clang 5.0.0svn.
  For some reason compilers tend to install their own headers that overshadow the system headers. This resulted in build failures in programs including plain <execinfo.h> header (for the backtrace(3) function). This system header used to include <stddef.h> that included our <sys/cdefs.h>... with shadowed <stddef.h> by Clang 5.0.0svn (from $PREFIX/lib/clang/5.0.0/include/stddef.h). Christos Zoulas fixed it by making <execinfo.h> standalone and independent from standard libc headers.
• __float128 and GNU libstdc++.
  Our basesystem GNU libstdc++ enables __float128 on i386, amd64 and i64 ports. As of now the LLVM equivalent library contains partial support for this type. This results in a problem that affects 3rd party programs in the setup of Clang + libstdc++ detect __float128 support and break because the compiler does not define appropriate global define __FLOAT128__. This issue is still open for discussion on how to solve it for NetBSD.
• gforth optimization problems.
  Upstream gforth developers ported this FORTH compiler to Clang, and triggered an optimization issue with attempting to needlessly solve a complex internal problem. This results with compilation times of several minutes on a modern CPUs instead of getting the results immediately. The problem has been already reported on the LLVM bugzilla and I have filed a report that it is still valid.
• bochs can be built with clang.
  A while ago, bochs was buildable only by the GCC compilers and the Clang toolchain was blacklisted. I have verified that this is no longer the case and unmasked the package for compilers other than GCC.

LLVM and Clang testsuites

I have prepared Clang and LLVM testsuites to execute on NetBSD. Correctness of both projects is crucial for LLDB and the LLVM sanitizers to work because their issues resound problems inside programs that depend on them. Originally I have corrected the tests with local patches to build with GCC, and switched later to Clang. I have restructured the packages in pkgsrc-wip in order to execute the test-suite. I have fixed 20 test failures in LLVM implementing AllocateRWX and ReleaseRWX for the NetBSD flavor of PaX MPROTECT. There are still over 200 failures to solve!

It's worth noting that the googletest library (used in a modified version in LLVM and in a regular one in Clang) finally accepted the NetBSD patches.

LLVM asan and ubsan

I expect to get four LLVM sanitizers working in order to move on to LLDB: asan (address sanitizer), ubsan (undefined behavior sanitizer), tsan (thread sanitizer), msan (memory sanitizer). The other ones like dfsan (data-flow sanitizer) or lsan (leak sanitizer) are currently to be skipped. In general, sanitizers are part of the LLDB functionality that I want to get aboard on NetBSD, as there are plugins to integrate them within the debugger. In the current state I require them to debug bugs inside LLDB/NetBSD.

The original work on sanitizers in GCC (with libsanitizer) has been done by Christos Zoulas. GCC libsanitizer is a close sibling of compiler-rt/lib from the LLVM project. I picked up his work and integrated it into compiler-rt and developed the rest (code differences, fixing bugs, Clang/LLVM specific parts in llvm/ and clang/) and I managed to get asan and ubsan to work.

Users should pickup pkgsrc-wip in revision 3e7c52b97b4d6cb8ea69a081409ac818c812c34a and install wip/{llvm,clang,compiler-rt}-netbsd. Clang will be ready for usage:

/usr/pkg/bin/clang -fsanitize=undefined test.c

and

/usr/pkg/bin/clang -fsanitize=address test.c

Additional compiler commands that may improve the experience:

-g -O0 -fno-omit-frame-pointer -pie -fPIE

These sanitizers are not production ready and are active under development.

Plan for the next milestone

Roadmap for the next month:

• Finish and send upstream LLVM asan and ubsan support.
• Correct more problems triggered by LLVM and Clang test-suites.
• Resume msan and tsan porting.

This work was sponsored by The NetBSD Foundation.

The NetBSD Foundation is a non-profit organization and welcomes any donations to help us continue funding projects and services to the open-source community. Please consider visiting the following URL, and chip in what you can:

http://netbsd.org/donations/#how-to-donate

Over the last 30 days I was focusing on getting the environment to enable LLVM sanitizers and the Clang compiler on NetBSD. Meanwhile I pushed forward generic parts that were needing enhancements around pkgsrc and LLVM in general to ease the future LLDB work.

dogfood

When I have realized that in order to work on the LLVM sanitizers I need to use Clang as the compiler. A part of the compiler-rt (lowlevel LLVM compiler runtime library) has code specifically incompatible with GCC. It was mainly related to intrinsic instructions for atomic functions. I tried to research how much work is needed to port it to GCC. It happened to be non-trivial and I filed a bug on the LLVM bugzilla.

These circumstances made me to switch to Clang as the pkgsrc toolchain. I was using it to test the compilation of small bulks of packages and record build and compiler problems. To save time, I used ccache as my cache for builds.

My options in mk.conf(5):

PKGSRC_COMPILER=        ccache clang
CCACHE_BASE=            /usr/local
CCACHE_DIR=             /public/ccache_tmp
CCACHE_LOGFILE=         /tmp/ccache.txt
PKG_CC=                 clang
PKG_CXX=                clang++
CLANGBASE=              /usr/local
HAVE_LLVM=              yes

It's worth noting that ccache with pkgsrc won't check $HOME/.ccache for configuration, it must be placed in $CCACHE_DIR/ccache.conf.

The documented problems can be summarized as:

• Broken ccache in pkgsrc for C++11 packages.
  The pkgsrc framework started supporting C++ languages in the USE_LANGUAGES definition. Packages with newly added USE_LANGUAGES values (such as c++11) were not compiled with ccache because ccache.mk was not yet aware of such values. This broke support of these packages to set these values to be built with ccache. I've corrected it and introduced a new option CCACHE_LOGFILE to more easily track execution of ccache and detect errors.
• Broken ccache in pkgsrc for a custom toolchain.
  ccache tries finding a real-compiler looking for it in $PATH. When I have built clang within pkgsrc to work on it (installed into /usr/pkg), and I had my main toolchain in /usr/local it was picking the one from /usr/pkg for new builds and it resulted in cache-misses for new builds. I have installed a fix for it to pass ccache specific PATH to always find the appropriate compiler.
• Header <execinfo.h> cannot be included on Clang 5.0.0svn.
  For some reason compilers tend to install their own headers that overshadow the system headers. This resulted in build failures in programs including plain <execinfo.h> header (for the backtrace(3) function). This system header used to include <stddef.h> that included our <sys/cdefs.h>... with shadowed <stddef.h> by Clang 5.0.0svn (from $PREFIX/lib/clang/5.0.0/include/stddef.h). Christos Zoulas fixed it by making <execinfo.h> standalone and independent from standard libc headers.
• __float128 and GNU libstdc++.
  Our basesystem GNU libstdc++ enables __float128 on i386, amd64 and i64 ports. As of now the LLVM equivalent library contains partial support for this type. This results in a problem that affects 3rd party programs in the setup of Clang + libstdc++ detect __float128 support and break because the compiler does not define appropriate global define __FLOAT128__. This issue is still open for discussion on how to solve it for NetBSD.
• gforth optimization problems.
  Upstream gforth developers ported this FORTH compiler to Clang, and triggered an optimization issue with attempting to needlessly solve a complex internal problem. This results with compilation times of several minutes on a modern CPUs instead of getting the results immediately. The problem has been already reported on the LLVM bugzilla and I have filed a report that it is still valid.
• bochs can be built with clang.
  A while ago, bochs was buildable only by the GCC compilers and the Clang toolchain was blacklisted. I have verified that this is no longer the case and unmasked the package for compilers other than GCC.

LLVM and Clang testsuites

I have prepared Clang and LLVM testsuites to execute on NetBSD. Correctness of both projects is crucial for LLDB and the LLVM sanitizers to work because their issues resound problems inside programs that depend on them. Originally I have corrected the tests with local patches to build with GCC, and switched later to Clang. I have restructured the packages in pkgsrc-wip in order to execute the test-suite. I have fixed 20 test failures in LLVM implementing AllocateRWX and ReleaseRWX for the NetBSD flavor of PaX MPROTECT. There are still over 200 failures to solve!

It's worth noting that the googletest library (used in a modified version in LLVM and in a regular one in Clang) finally accepted the NetBSD patches.

LLVM asan and ubsan

I expect to get four LLVM sanitizers working in order to move on to LLDB: asan (address sanitizer), ubsan (undefined behavior sanitizer), tsan (thread sanitizer), msan (memory sanitizer). The other ones like dfsan (data-flow sanitizer) or lsan (leak sanitizer) are currently to be skipped. In general, sanitizers are part of the LLDB functionality that I want to get aboard on NetBSD, as there are plugins to integrate them within the debugger. In the current state I require them to debug bugs inside LLDB/NetBSD.

The original work on sanitizers in GCC (with libsanitizer) has been done by Christos Zoulas. GCC libsanitizer is a close sibling of compiler-rt/lib from the LLVM project. I picked up his work and integrated it into compiler-rt and developed the rest (code differences, fixing bugs, Clang/LLVM specific parts in llvm/ and clang/) and I managed to get asan and ubsan to work.

Users should pickup pkgsrc-wip in revision 3e7c52b97b4d6cb8ea69a081409ac818c812c34a and install wip/{llvm,clang,compiler-rt}-netbsd. Clang will be ready for usage:

/usr/pkg/bin/clang -fsanitize=undefined test.c

and

/usr/pkg/bin/clang -fsanitize=address test.c

Additional compiler commands that may improve the experience:

-g -O0 -fno-omit-frame-pointer -pie -fPIE

These sanitizers are not production ready and are active under development.

Plan for the next milestone

Roadmap for the next month:

• Finish and send upstream LLVM asan and ubsan support.
• Correct more problems triggered by LLVM and Clang test-suites.
• Resume msan and tsan porting.

This work was sponsored by The NetBSD Foundation.

The NetBSD Foundation is a non-profit organization and welcomes any donations to help us continue funding projects and services to the open-source community. Please consider visiting the following URL, and chip in what you can:

http://netbsd.org/donations/#how-to-donate

This years pkgsrcCon returned to London once again. It was last held in London back in 2014. The 2014 con was the first pkgsrcCon I attended, I had been working on Darwin/PowerPC fixes for some months and presented on the progress I'd made with a 12" G4 PowerBook. I took away a G4 Mac Mini that day to help spare the PowerBook for use and dedicate a machine for build and testing. The offer of PowerPC hardware donations was repeated at this years con, thanks to jperkin@ who showed up with a backpack full of Mac Minis (more on that later).

Since 2014 we have held cons in Berlin (2015) & Krakow (2016). In Krakow we had talks about a wide range of projects over 2 days, from Haiku Ports to Common Lisp to midipix (building native PE binaries for Windows) and back to the BSDs. I was very pleased to continue the theme of a diverse program this year.

Aside from pkgsrc and NetBSD, we had talks about FreeBSD, OpenBSD, Slackware Linux, and Plan 9.
Things began with a pub gathering on the Friday for the pre-con social, we hung out and chatted till almost midnight on a wide range of topics, such as supporting a system using NFS on MS-DOS, the origins of pdksh, corporate IT, culture and many other topics.

On parting I was asked about the starting time on Saturday as there was some conflicting information. I learnt that the registration email had stated a later start than I had scheduled for & advertised on the website, by 30 minutes.
Lesson learnt: register for your own event!
Not a problem, I still needed to setup a webpage for the live video stream, I could do both when I got back. With some trimming here and there I had a new schedule, I posted that to the pkgsrcCon website and moved to trying to setup a basic web page which contained a snippet of javascript to play a live video stream from Scale Engine.
2+ hours later, it was pointed out that the XSS protection headers on pkgsrc.org breaks the functionality. Thanks to jmcneill@ for debugging and providing a working page.

Saturday started off with Giovanni Bechis speaking about pledge in OpenBSD and adding support to various packages in their ports tree, alnsn@ then spoke about installing packages from a repo hosted on the Tor network.

After a quick coffee break we were back to hear Charles Forsyth speak about how Plan 9 and Inferno dealt with portability, building software and the problem which are avoided by the environment there. This was followed by a very energetic rant by David Spencer from the Slackbuilds project on packaging 3rd party software. Slackbuilds is a packaging system for Slackware Linux, which was inspired by FreeBSD ports.

For the first slot after lunch, agc@ gave a talk on the early history of pkgsrc followed by Thomas Merkel on using vagrant to test pkgsrc changes with ease, locally, using vagrant. khorben@ covered his work on adding security to pkgsrc and bsiegert@ covered the benefits of performing our bulk builds in the cloud and the challenges we currently face.
My talk was about some topics and ideas which had inspired me or caught my attention, and how it could maybe apply to my work.The title of the talk was taken from the name of Andrew Weatherall's Saint Etienne remix, possibly referring to two different styles of track (dub & vocal) merged into one or something else. I meant it in terms of applicability of thoughts and ideas. After me, agc@ gave a second talk on the evolution of the Netflix Open Connect appliance which runs FreeBSD and Vsevolod Stakhov wrapped up the day with a talk about the technical implementation details of the successor to pkg_tools in FreeBSD, called pkg, and how it could be of benefit for pkgsrc.

Netflix confirms it: BSD is not dying #pkgsrcCon

— Benny Siegert (@bentsukun) July 1, 2017

For day 2 we gathered for a hack day at the London Hack Space.
I had burn't some some CD of the most recent macppc builds of NetBSD 8.0_BETA and -current to install and upgrade Mac Minis. I setup the donated G4 minis for everyone in a dual-boot configuration and moved on to taking apart my MacBook Air to inspect the wifi adapter as I wanted to replace it with something which works on FreeBSD. It was not clear from the ifixit teardown photos of cards size, it seemed like a normal mini-PCIe card but it turned out to be far smaller. Thomas had also had the same card in his and we are not alone. Thomas has started putting together a driver for the Broadcom card, the project is still in its early days and lacks support for encrypted networks but hopefully it will appear on review.freebsd.org in the future.
weidi@ worked on fixing SunOS bugs in various packages and later in the night we setup a NetBSD/macppc bulk build environment together on his Mac Mini.
Thomas setup an OpenGrock instance to index the source code of all the software available for packaging in pkgsrc. This helps make the evaluation of changes easier and the scope of impact a little quicker without having to run through a potentially lengthy bulk build with a change in mind to realise the impact.
bsiegert@ cleared his ticket and email backlog for pkgsrc and alnsn@ got NetBSD/evbmips64-eb booting on his EdgeRouter Lite.

#pkgsrcCon hackathon work by @docscream: https://t.co/3GY3TRtdNV code search over everything (still indexing)

— Wiedi (@wied0r) July 2, 2017

On Monday we reconvened at the Hack Space again and worked some more. I started putting together the talks page with the details from Saturday and the the slides which I had received, in preperation for the videos which would come later in the week. By 3pm pkgsrcCon was over. I was pretty exhausted but really pleased to have had a few days of techie fun.

Many thanks to The NetBSD Foundation for purchasing a camera to use for streaming the event and a speedy response all round by the board. The Open Source Specialist Group at BCS, The Chartered Institute for IT and the London Hack Space for hosting us. Scale Engine for providing streaming facility. weidi@ for hosting the recorded videos.
Allan Jude for pointers, Jared McNeill for debugging, NYCBUG and Patrick McEvoy for tips on streaming, the attendees and speakers. This year we had speakers from USA, Italy, Germany and London E2.
Looking forward to pkgsrcCon 2018!

The videos and slides are available here and the Internet Archive.

This years pkgsrcCon returned to London once again. It was last held in London back in 2014. The 2014 con was the first pkgsrcCon I attended, I had been working on Darwin/PowerPC fixes for some months and presented on the progress I'd made with a 12" G4 PowerBook. I took away a G4 Mac Mini that day to help spare the PowerBook for use and dedicate a machine for build and testing. The offer of PowerPC hardware donations was repeated at this years con, thanks to jperkin@ who showed up with a backpack full of Mac Minis (more on that later).

Since 2014 we have held cons in Berlin (2015) & Krakow (2016). In Krakow we had talks about a wide range of projects over 2 days, from Haiku Ports to Common Lisp to midipix (building native PE binaries for Windows) and back to the BSDs. I was very pleased to continue the theme of a diverse program this year.

Aside from pkgsrc and NetBSD, we had talks about FreeBSD, OpenBSD, Slackware Linux, and Plan 9.
Things began with a pub gathering on the Friday for the pre-con social, we hung out and chatted till almost midnight on a wide range of topics, such as supporting a system using NFS on MS-DOS, the origins of pdksh, corporate IT, culture and many other topics.

On parting I was asked about the starting time on Saturday as there was some conflicting information. I learnt that the registration email had stated a later start than I had scheduled for & advertised on the website, by 30 minutes.
Lesson learnt: register for your own event!
Not a problem, I still needed to setup a webpage for the live video stream, I could do both when I got back. With some trimming here and there I had a new schedule, I posted that to the pkgsrcCon website and moved to trying to setup a basic web page which contained a snippet of javascript to play a live video stream from Scale Engine.
2+ hours later, it was pointed out that the XSS protection headers on pkgsrc.org breaks the functionality. Thanks to jmcneill@ for debugging and providing a working page.

Saturday started off with Giovanni Bechis speaking about pledge in OpenBSD and adding support to various packages in their ports tree, alnsn@ then spoke about installing packages from a repo hosted on the Tor network.

After a quick coffee break we were back to hear Charles Forsyth speak about how Plan 9 and Inferno dealt with portability, building software and the problem which are avoided by the environment there. This was followed by a very energetic rant by David Spencer from the Slackbuilds project on packaging 3rd party software. Slackbuilds is a packaging system for Slackware Linux, which was inspired by FreeBSD ports.

For the first slot after lunch, agc@ gave a talk on the early history of pkgsrc followed by Thomas Merkel on using vagrant to test pkgsrc changes with ease, locally, using vagrant. khorben@ covered his work on adding security to pkgsrc and bsiegert@ covered the benefits of performing our bulk builds in the cloud and the challenges we currently face.
My talk was about some topics and ideas which had inspired me or caught my attention, and how it could maybe apply to my work.The title of the talk was taken from the name of Andrew Weatherall's Saint Etienne remix, possibly referring to two different styles of track (dub & vocal) merged into one or something else. I meant it in terms of applicability of thoughts and ideas. After me, agc@ gave a second talk on the evolution of the Netflix Open Connect appliance which runs FreeBSD and Vsevolod Stakhov wrapped up the day with a talk about the technical implementation details of the successor to pkg_tools in FreeBSD, called pkg, and how it could be of benefit for pkgsrc.

Netflix confirms it: BSD is not dying #pkgsrcCon

— Benny Siegert (@bentsukun) July 1, 2017

For day 2 we gathered for a hack day at the London Hack Space.
I had burn't some some CD of the most recent macppc builds of NetBSD 8.0_BETA and -current to install and upgrade Mac Minis. I setup the donated G4 minis for everyone in a dual-boot configuration and moved on to taking apart my MacBook Air to inspect the wifi adapter as I wanted to replace it with something which works on FreeBSD. It was not clear from the ifixit teardown photos of cards size, it seemed like a normal mini-PCIe card but it turned out to be far smaller. Thomas had also had the same card in his and we are not alone. Thomas has started putting together a driver for the Broadcom card, the project is still in its early days and lacks support for encrypted networks but hopefully it will appear on review.freebsd.org in the future.
weidi@ worked on fixing SunOS bugs in various packages and later in the night we setup a NetBSD/macppc bulk build environment together on his Mac Mini.
Thomas setup an OpenGrock instance to index the source code of all the software available for packaging in pkgsrc. This helps make the evaluation of changes easier and the scope of impact a little quicker without having to run through a potentially lengthy bulk build with a change in mind to realise the impact.
bsiegert@ cleared his ticket and email backlog for pkgsrc and alnsn@ got NetBSD/evbmips64-eb booting on his EdgeRouter Lite.

#pkgsrcCon hackathon work by @docscream: https://t.co/3GY3TRtdNV code search over everything (still indexing)

— Wiedi (@wied0r) July 2, 2017

On Monday we reconvened at the Hack Space again and worked some more. I started putting together the talks page with the details from Saturday and the the slides which I had received, in preperation for the videos which would come later in the week. By 3pm pkgsrcCon was over. I was pretty exhausted but really pleased to have had a few days of techie fun.

Many thanks to The NetBSD Foundation for purchasing a camera to use for streaming the event and a speedy response all round by the board. The Open Source Specialist Group at BCS, The Chartered Institute for IT and the London Hack Space for hosting us. Scale Engine for providing streaming facility. weidi@ for hosting the recorded videos.
Allan Jude for pointers, Jared McNeill for debugging, NYCBUG and Patrick McEvoy for tips on streaming, the attendees and speakers. This year we had speakers from USA, Italy, Germany and London E2.
Looking forward to pkgsrcCon 2018!

The videos and slides are available here and the Internet Archive.

A new SUNXI evbarm kernel has appeared recently in NetBSD -current with support for boards based on the Allwinner H3 system on a chip (SoC). The H3 SoC is a quad-core Cortex-A7 SoC designed primarily for set-top boxes, but has managed to find its way into many single-board computers (SBC). This is one of the first evbarm ports built from the ground up with device tree support, which helps us to use a single kernel config to support many different boards.

To get these boards up and running, first we need to deal with low-level startup code. For the SUNXI kernel this currently lives in sys/arch/evbarm/sunxi/. The purpose of this code is fairly simple; initialize the boot CPU and initialize the MMU so we can jump to the kernel. The initial MMU configuration needs to cover a few things -- early on we need to be able to access the kernel, UART debug console, and the device tree blob (DTB) passed in from U-Boot. We wrap the kernel in a U-Boot header that claims to be a Linux kernel; this is no accident! This tells U-Boot to use the Linux boot protocol when loading the kernel, which ensures that the DTB (loaded by U-Boot) is processed and passed to us in r2.

Once the CPU and MMU are ready, we jump to the generic ARM FDT implementation of initarm in sys/arch/evbarm/fdt/fdt_machdep.c. The first thing this code does is validate and relocate the DTB data. After it has been relocated, we compare the compatible property of the root node in the device tree with the list of ARM platforms compiled into the kernel. The Allwinner sunxi platform code lives in sys/arch/arm/sunxi/sunxi_platform.c. The sunxi platform code provides SoC-specific versions of code needed early at boot. We need to know how to initialize the debug console, spin up application CPUs, reset the board, etc.

Instead of writing H3-specific code for spinning up application CPUs, I took advantage of U-Boot's Power State Coordination Interface implementation. A psci(4) driver was added and the allwinner,sun8i-h3 platform code was modified to use this code to start up all processors.

With a bit of luck, we're now booting and enumerating devices. Apart from a few devices, almost nothing works yet as we are missing a driver for the CCU. The CCU in the Allwinner H3 SoC controls PLLs and most of the clock generation, division, muxing, and gating. Since there are many similarities between Allwinner SoCs, I opted to write generic CCU code and then SoC-specific frontends. The resulting code lives in sys/arch/arm/sunxi/; generic code as sunxi_ccu.c and H3-specific code in sun8i_h3_ccu.c.

Now we have a CCU driver, we can attach a com(4) and have a valid console device.

After this, it's a matter of writing drivers and/or adapting existing code to attach to fdtbus based on the bindings used in the DTB. For cases where we had a compatible driver in the old Allwinner port, I opted to make a copy of the code and FDT-ize it. A few reasons for this -- 1) the old drivers have CCU-specific code with per-SoC ifdefs scattered throughout, 2) I didn't want to break existing kernels, and 3) long term goal is to move the SoCs supported by the old code over to the new code (this process has already started with the Allwinner A31 port).

So what do we get out of this? This is a step towards being able to ship a GENERIC evbarm kernel. I developed the H3 port on two boards, the NanoPi NEO and Orange Pi Plus 2E, but since then users on port-arm@ have been reporting success on many other H3 boards, all from a single kernel config. In addition, I've added support for other Allwinner SoCs (sun8i-a83t, sun6i-a31) to the kernel and have tested booting the same kernel across all 3 SoCs.

Orange Pi Plus 2E boot log is below.

U-Boot SPL 2017.05 (Jul 01 2017 - 17:11:09)
DRAM: 2048 MiB
Trying to boot from MMC1


U-Boot 2017.05 (Jul 01 2017 - 17:11:09 -0300) Allwinner Technology

CPU:   Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi Plus 2E
I2C:   ready
DRAM:  2 GiB
MMC:   SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
In:    serial
Out:   serial
Err:   serial
Net:   phy interface7
eth0: ethernet@1c30000
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
USB4:   USB EHCI 1.00
USB5:   USB OHCI 1.0
scanning bus 0 for devices... 2 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
scanning bus 4 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
reading netbsd.ub
6600212 bytes read in 334 ms (18.8 MiB/s)
reading sun8i-h3-orangepi-plus2e.dtb
16775 bytes read in 49 ms (334 KiB/s)
## Booting kernel from Legacy Image at 42000000 ...
   Image Name:   NetBSD/sunxi 8.99.1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    6600148 Bytes = 6.3 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 43000000
   Booting using the fdt blob at 0x43000000
   Loading Kernel Image ... OK
   Loading Device Tree to 49ff8000, end 49fff186 ... OK

Starting kernel ...

[ Kernel symbol table missing! ]
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 8.99.1 (SUNXI) #304: Sat Jul  8 11:01:22 ADT 2017
        jmcneill@undine.invisible.ca:/usr/home/jmcneill/netbsd/cvs-src/sys/arch/evbarm/compile/obj/SUNXI
total memory = 2048 MB
avail memory = 2020 MB
sysctl_createv: sysctl_create(machine_arch) returned 17
armfdt0 (root)
fdt0 at armfdt0: Xunlong Orange Pi Plus 2E
fdt1 at fdt0
fdt2 at fdt0
cpus0 at fdt0
cpu0 at cpus0: Cortex-A7 r0p5 (Cortex V7A core)
cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu0: 32KB/32B 2-way L1 VIPT Instruction cache
cpu0: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache
cpu0: 512KB/64B 8-way write-through L2 PIPT Unified cache
vfp0 at cpu0: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
cpu1 at cpus0
cpu2 at cpus0
cpu3 at cpus0
gic0 at fdt1: GIC
armgic0 at gic0: Generic Interrupt Controller, 160 sources (150 valid)
armgic0: 16 Priorities, 128 SPIs, 7 PPIs, 15 SGIs
fclock0 at fdt2: 24000000 Hz fixed clock
ffclock0 at fdt2: x1 /1 fixed-factor clock
fclock1 at fdt2: 32768 Hz fixed clock
sunxigates0 at fdt2
sunxiresets0 at fdt1
gtmr0 at fdt0: Generic Timer
armgtmr0 at gtmr0: ARMv7 Generic 64-bit Timer (24000 kHz)
armgtmr0: interrupting on irq 27
sunxigpio0 at fdt1: PIO
gpio0 at sunxigpio0: 94 pins
sunxigpio1 at fdt1: PIO
gpio1 at sunxigpio1: 12 pins
sun8ih3ccu0 at fdt1: H3 CCU
fregulator0 at fdt0: vcc3v3
fregulator1 at fdt0: gmac-3v3
fregulator2 at fdt0: vcc3v0
fregulator3 at fdt0: vcc5v0
sunxiusbphy0 at fdt1: USB PHY
/soc/dma-controller@01c02000 at fdt1 not configured
/soc/codec-analog@01f015c0 at fdt1 not configured
/clocks/ir_clk@01f01454 at fdt2 not configured
sunxiemac0 at fdt1: EMAC
sunxiemac0: interrupting on GIC irq 114
rgephy0 at sunxiemac0 phy 0: RTL8169S/8110S/8211 1000BASE-T media interface, rev. 5
rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
rgephy1 at sunxiemac0 phy 1: RTL8169S/8110S/8211 1000BASE-T media interface, rev. 5
rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
psci0 at fdt0: PSCI 0.1
gpioleds0 at fdt0: orangepi:green:pwr orangepi:red:status
gpiokeys0 at fdt0: sw4
sunximmc0 at fdt1: SD/MMC controller
sunximmc0: interrupting on GIC irq 92
sunximmc1 at fdt1: SD/MMC controller
sunximmc1: interrupting on GIC irq 93
sunximmc2 at fdt1: SD/MMC controller
sunximmc2: interrupting on GIC irq 94
ehci0 at fdt1: EHCI
ehci0: interrupting on GIC irq 106
ehci0: 1 companion controller, 1 port
usb0 at ehci0: USB revision 2.0
ohci0 at fdt1: OHCI
ohci0: interrupting on GIC irq 107
ohci0: OHCI version 1.0
usb1 at ohci0: USB revision 1.0
ehci1 at fdt1: EHCI
ehci1: interrupting on GIC irq 108
ehci1: 1 companion controller, 1 port
usb2 at ehci1: USB revision 2.0
ohci1 at fdt1: OHCI
ohci1: interrupting on GIC irq 109
ohci1: OHCI version 1.0
usb3 at ohci1: USB revision 1.0
ehci2 at fdt1: EHCI
ehci2: interrupting on GIC irq 110
ehci2: 1 companion controller, 1 port
usb4 at ehci2: USB revision 2.0
ohci2 at fdt1: OHCI
ohci2: interrupting on GIC irq 111
ohci2: OHCI version 1.0
usb5 at ohci2: USB revision 1.0
/soc/timer@01c20c00 at fdt1 not configured
/soc/watchdog@01c20ca0 at fdt1 not configured
/soc/codec@01c22c00 at fdt1 not configured
com0 at fdt1: ns16550a, working fifo
com0: console
com0: interrupting on GIC irq 32
sunxirtc0 at fdt1: RTC
/soc/ir@01f02000 at fdt1 not configured
cpu3: Cortex-A7 r0p5 (Cortex V7A core)
cpu3: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu3: 32KB/32B 2-way L1 VIPT Instruction cache
cpu3: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache
cpu3: 512KB/64B 8-way write-through L2 PIPT Unified cache
vfp3 at cpu3: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
cpu1: Cortex-A7 r0p5 (Cortex V7A core)
cpu1: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu1: 32KB/32B 2-way L1 VIPT Instruction cache
cpu1: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache
cpu1: 512KB/64B 8-way write-through L2 PIPT Unified cache
vfp1 at cpu1: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
cpu2: Cortex-A7 r0p5 (Cortex V7A core)
cpu2: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu2: 32KB/32B 2-way L1 VIPT Instruction cache
cpu2: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache
cpu2: 512KB/64B 8-way write-through L2 PIPT Unified cache
vfp2 at cpu2: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
sdmmc0 at sunximmc0
sdmmc1 at sunximmc1
sdmmc2 at sunximmc2
uhub0 at usb0: Generic (0000) EHCI root hub (0000), class 9/0, rev 2.00/1.00, addr 1
uhub1 at usb2: Generic (0000) EHCI root hub (0000), class 9/0, rev 2.00/1.00, addr 1
uhub2 at usb3: Generic (0000) OHCI root hub (0000), class 9/0, rev 1.00/1.00, addr 1
uhub3 at usb1: Generic (0000) OHCI root hub (0000), class 9/0, rev 1.00/1.00, addr 1
uhub4 at usb4: Generic (0000) EHCI root hub (0000), class 9/0, rev 2.00/1.00, addr 1
uhub5 at usb5: Generic (0000) OHCI root hub (0000), class 9/0, rev 1.00/1.00, addr 1
ld2 at sdmmc2: <0x15:0x0100:AWPD3R:0x00:0xec19649f:0x000>
sdmmc0: SD card status: 4-bit, C10, U1, V10
ld0 at sdmmc0: <0x27:0x5048:2&DRP:0x07:0x01c828bc:0x109>
ld2: 14910 MB, 7573 cyl, 64 head, 63 sec, 512 bytes/sect x 30535680 sectors
ld0: 15288 MB, 7765 cyl, 64 head, 63 sec, 512 bytes/sect x 31309824 sectors
(manufacturer 0x24c, product 0xf179, standard function interface code 0x7)at sdmmc1 function 1 not configured
ld2: mbr partition exceeds disk size
ld0: 4-bit width, High-Speed/SDR25, 50.000 MHz
ld2: 8-bit width, 52.000 MHz
urtwn0 at uhub0 port 1
urtwn0: Realtek (0xbda) 802.11n NIC (0x8179), rev 2.00/0.00, addr 2
urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R, address e8:de:27:16:0c:81
urtwn0: 1 rx pipe, 2 tx pipes
urtwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
urtwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
boot device: ld0
root on ld0a dumps on ld0b
root file system type: ffs
kern.module.path=/stand/evbarm/8.99.1/modules
WARNING: clock lost 6398 days
WARNING: using filesystem time
WARNING: CHECK AND RESET THE DATE!
Sat Jul  8 11:05:42 ADT 2017
Starting root file system check:
/dev/rld0a: file system is clean; not checking
Not resizing /: already correct size
swapctl: adding /dev/ld0b as swap device at priority 0
Starting file system checks:
/dev/rld0e: 22 files, 32340 free (8085 clusters)
random_seed: /var/db/entropy-file: Not present
Setting tty flags.
Setting sysctl variables:
ddb.onpanic: 1 -> 1
Starting network.
Hostname: sunxi
IPv6 mode: host
Configuring network interfaces:.
Adding interface aliases:.
Waiting for DAD to complete for statically configured addresses...
Starting dhcpcd.
Starting mdnsd.
Building databases: dev, utmp, utmpx.
Starting syslogd.
Mounting all file systems...
Clearing temporary files.
Updating fontconfig cache: done.
Creating a.out runtime link editor directory cache.
Checking quotas: done.
Setting securelevel: kern.securelevel: 0 -> 1
Starting virecover.
Checking for core dump...
savecore: no core dump
Starting devpubd.
Starting local daemons:.
Updating motd.
Starting ntpd.
Jul  8 11:05:58 sunxi ntpd[595]: ntp_rlimit: Cannot set RLIMIT_STACK: Invalid argument
Starting sshd.
Starting inetd.
Starting cron.
Sat Jul  8 11:06:02 ADT 2017

NetBSD/evbarm (sunxi) (console)

login:

A new SUNXI evbarm kernel has appeared recently in NetBSD -current with support for boards based on the Allwinner H3 system on a chip (SoC). The H3 SoC is a quad-core Cortex-A7 SoC designed primarily for set-top boxes, but has managed to find its way into many single-board computers (SBC). This is one of the first evbarm ports built from the ground up with device tree support, which helps us to use a single kernel config to support many different boards.

To get these boards up and running, first we need to deal with low-level startup code. For the SUNXI kernel this currently lives in sys/arch/evbarm/sunxi/. The purpose of this code is fairly simple; initialize the boot CPU and initialize the MMU so we can jump to the kernel. The initial MMU configuration needs to cover a few things -- early on we need to be able to access the kernel, UART debug console, and the device tree blob (DTB) passed in from U-Boot. We wrap the kernel in a U-Boot header that claims to be a Linux kernel; this is no accident! This tells U-Boot to use the Linux boot protocol when loading the kernel, which ensures that the DTB (loaded by U-Boot) is processed and passed to us in r2.

Once the CPU and MMU are ready, we jump to the generic ARM FDT implementation of initarm in sys/arch/evbarm/fdt/fdt_machdep.c. The first thing this code does is validate and relocate the DTB data. After it has been relocated, we compare the compatible property of the root node in the device tree with the list of ARM platforms compiled into the kernel. The Allwinner sunxi platform code lives in sys/arch/arm/sunxi/sunxi_platform.c. The sunxi platform code provides SoC-specific versions of code needed early at boot. We need to know how to initialize the debug console, spin up application CPUs, reset the board, etc.

Instead of writing H3-specific code for spinning up application CPUs, I took advantage of U-Boot's Power State Coordination Interface implementation. A psci(4) driver was added and the allwinner,sun8i-h3 platform code was modified to use this code to start up all processors.

With a bit of luck, we're now booting and enumerating devices. Apart from a few devices, almost nothing works yet as we are missing a driver for the CCU. The CCU in the Allwinner H3 SoC controls PLLs and most of the clock generation, division, muxing, and gating. Since there are many similarities between Allwinner SoCs, I opted to write generic CCU code and then SoC-specific frontends. The resulting code lives in sys/arch/arm/sunxi/; generic code as sunxi_ccu.c and H3-specific code in sun8i_h3_ccu.c.

Now we have a CCU driver, we can attach a com(4) and have a valid console device.

After this, it's a matter of writing drivers and/or adapting existing code to attach to fdtbus based on the bindings used in the DTB. For cases where we had a compatible driver in the old Allwinner port, I opted to make a copy of the code and FDT-ize it. A few reasons for this -- 1) the old drivers have CCU-specific code with per-SoC ifdefs scattered throughout, 2) I didn't want to break existing kernels, and 3) long term goal is to move the SoCs supported by the old code over to the new code (this process has already started with the Allwinner A31 port).

So what do we get out of this? This is a step towards being able to ship a GENERIC evbarm kernel. I developed the H3 port on two boards, the NanoPi NEO and Orange Pi Plus 2E, but since then users on port-arm@ have been reporting success on many other H3 boards, all from a single kernel config. In addition, I've added support for other Allwinner SoCs (sun8i-a83t, sun6i-a31) to the kernel and have tested booting the same kernel across all 3 SoCs.

Orange Pi Plus 2E boot log is below.

U-Boot SPL 2017.05 (Jul 01 2017 - 17:11:09)
DRAM: 2048 MiB
Trying to boot from MMC1


U-Boot 2017.05 (Jul 01 2017 - 17:11:09 -0300) Allwinner Technology

CPU:   Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi Plus 2E
I2C:   ready
DRAM:  2 GiB
MMC:   SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
In:    serial
Out:   serial
Err:   serial
Net:   phy interface7
eth0: ethernet@1c30000
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
USB4:   USB EHCI 1.00
USB5:   USB OHCI 1.0
scanning bus 0 for devices... 2 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
scanning bus 4 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
reading netbsd.ub
6600212 bytes read in 334 ms (18.8 MiB/s)
reading sun8i-h3-orangepi-plus2e.dtb
16775 bytes read in 49 ms (334 KiB/s)
## Booting kernel from Legacy Image at 42000000 ...
   Image Name:   NetBSD/sunxi 8.99.1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    6600148 Bytes = 6.3 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 43000000
   Booting using the fdt blob at 0x43000000
   Loading Kernel Image ... OK
   Loading Device Tree to 49ff8000, end 49fff186 ... OK

Starting kernel ...

[ Kernel symbol table missing! ]
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 8.99.1 (SUNXI) #304: Sat Jul  8 11:01:22 ADT 2017
        jmcneill@undine.invisible.ca:/usr/home/jmcneill/netbsd/cvs-src/sys/arch/evbarm/compile/obj/SUNXI
total memory = 2048 MB
avail memory = 2020 MB
sysctl_createv: sysctl_create(machine_arch) returned 17
armfdt0 (root)
fdt0 at armfdt0: Xunlong Orange Pi Plus 2E
fdt1 at fdt0
fdt2 at fdt0
cpus0 at fdt0
cpu0 at cpus0: Cortex-A7 r0p5 (Cortex V7A core)
cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu0: 32KB/32B 2-way L1 VIPT Instruction cache
cpu0: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache
cpu0: 512KB/64B 8-way write-through L2 PIPT Unified cache
vfp0 at cpu0: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
cpu1 at cpus0
cpu2 at cpus0
cpu3 at cpus0
gic0 at fdt1: GIC
armgic0 at gic0: Generic Interrupt Controller, 160 sources (150 valid)
armgic0: 16 Priorities, 128 SPIs, 7 PPIs, 15 SGIs
fclock0 at fdt2: 24000000 Hz fixed clock
ffclock0 at fdt2: x1 /1 fixed-factor clock
fclock1 at fdt2: 32768 Hz fixed clock
sunxigates0 at fdt2
sunxiresets0 at fdt1
gtmr0 at fdt0: Generic Timer
armgtmr0 at gtmr0: ARMv7 Generic 64-bit Timer (24000 kHz)
armgtmr0: interrupting on irq 27
sunxigpio0 at fdt1: PIO
gpio0 at sunxigpio0: 94 pins
sunxigpio1 at fdt1: PIO
gpio1 at sunxigpio1: 12 pins
sun8ih3ccu0 at fdt1: H3 CCU
fregulator0 at fdt0: vcc3v3
fregulator1 at fdt0: gmac-3v3
fregulator2 at fdt0: vcc3v0
fregulator3 at fdt0: vcc5v0
sunxiusbphy0 at fdt1: USB PHY
/soc/dma-controller@01c02000 at fdt1 not configured
/soc/codec-analog@01f015c0 at fdt1 not configured
/clocks/ir_clk@01f01454 at fdt2 not configured
sunxiemac0 at fdt1: EMAC
sunxiemac0: interrupting on GIC irq 114
rgephy0 at sunxiemac0 phy 0: RTL8169S/8110S/8211 1000BASE-T media interface, rev. 5
rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
rgephy1 at sunxiemac0 phy 1: RTL8169S/8110S/8211 1000BASE-T media interface, rev. 5
rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
psci0 at fdt0: PSCI 0.1
gpioleds0 at fdt0: orangepi:green:pwr orangepi:red:status
gpiokeys0 at fdt0: sw4
sunximmc0 at fdt1: SD/MMC controller
sunximmc0: interrupting on GIC irq 92
sunximmc1 at fdt1: SD/MMC controller
sunximmc1: interrupting on GIC irq 93
sunximmc2 at fdt1: SD/MMC controller
sunximmc2: interrupting on GIC irq 94
ehci0 at fdt1: EHCI
ehci0: interrupting on GIC irq 106
ehci0: 1 companion controller, 1 port
usb0 at ehci0: USB revision 2.0
ohci0 at fdt1: OHCI
ohci0: interrupting on GIC irq 107
ohci0: OHCI version 1.0
usb1 at ohci0: USB revision 1.0
ehci1 at fdt1: EHCI
ehci1: interrupting on GIC irq 108
ehci1: 1 companion controller, 1 port
usb2 at ehci1: USB revision 2.0
ohci1 at fdt1: OHCI
ohci1: interrupting on GIC irq 109
ohci1: OHCI version 1.0
usb3 at ohci1: USB revision 1.0
ehci2 at fdt1: EHCI
ehci2: interrupting on GIC irq 110
ehci2: 1 companion controller, 1 port
usb4 at ehci2: USB revision 2.0
ohci2 at fdt1: OHCI
ohci2: interrupting on GIC irq 111
ohci2: OHCI version 1.0
usb5 at ohci2: USB revision 1.0
/soc/timer@01c20c00 at fdt1 not configured
/soc/watchdog@01c20ca0 at fdt1 not configured
/soc/codec@01c22c00 at fdt1 not configured
com0 at fdt1: ns16550a, working fifo
com0: console
com0: interrupting on GIC irq 32
sunxirtc0 at fdt1: RTC
/soc/ir@01f02000 at fdt1 not configured
cpu3: Cortex-A7 r0p5 (Cortex V7A core)
cpu3: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu3: 32KB/32B 2-way L1 VIPT Instruction cache
cpu3: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache
cpu3: 512KB/64B 8-way write-through L2 PIPT Unified cache
vfp3 at cpu3: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
cpu1: Cortex-A7 r0p5 (Cortex V7A core)
cpu1: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu1: 32KB/32B 2-way L1 VIPT Instruction cache
cpu1: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache
cpu1: 512KB/64B 8-way write-through L2 PIPT Unified cache
vfp1 at cpu1: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
cpu2: Cortex-A7 r0p5 (Cortex V7A core)
cpu2: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu2: 32KB/32B 2-way L1 VIPT Instruction cache
cpu2: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache
cpu2: 512KB/64B 8-way write-through L2 PIPT Unified cache
vfp2 at cpu2: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
sdmmc0 at sunximmc0
sdmmc1 at sunximmc1
sdmmc2 at sunximmc2
uhub0 at usb0: Generic (0000) EHCI root hub (0000), class 9/0, rev 2.00/1.00, addr 1
uhub1 at usb2: Generic (0000) EHCI root hub (0000), class 9/0, rev 2.00/1.00, addr 1
uhub2 at usb3: Generic (0000) OHCI root hub (0000), class 9/0, rev 1.00/1.00, addr 1
uhub3 at usb1: Generic (0000) OHCI root hub (0000), class 9/0, rev 1.00/1.00, addr 1
uhub4 at usb4: Generic (0000) EHCI root hub (0000), class 9/0, rev 2.00/1.00, addr 1
uhub5 at usb5: Generic (0000) OHCI root hub (0000), class 9/0, rev 1.00/1.00, addr 1
ld2 at sdmmc2: <0x15:0x0100:AWPD3R:0x00:0xec19649f:0x000>
sdmmc0: SD card status: 4-bit, C10, U1, V10
ld0 at sdmmc0: <0x27:0x5048:2&DRP:0x07:0x01c828bc:0x109>
ld2: 14910 MB, 7573 cyl, 64 head, 63 sec, 512 bytes/sect x 30535680 sectors
ld0: 15288 MB, 7765 cyl, 64 head, 63 sec, 512 bytes/sect x 31309824 sectors
(manufacturer 0x24c, product 0xf179, standard function interface code 0x7)at sdmmc1 function 1 not configured
ld2: mbr partition exceeds disk size
ld0: 4-bit width, High-Speed/SDR25, 50.000 MHz
ld2: 8-bit width, 52.000 MHz
urtwn0 at uhub0 port 1
urtwn0: Realtek (0xbda) 802.11n NIC (0x8179), rev 2.00/0.00, addr 2
urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R, address e8:de:27:16:0c:81
urtwn0: 1 rx pipe, 2 tx pipes
urtwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
urtwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
boot device: ld0
root on ld0a dumps on ld0b
root file system type: ffs
kern.module.path=/stand/evbarm/8.99.1/modules
WARNING: clock lost 6398 days
WARNING: using filesystem time
WARNING: CHECK AND RESET THE DATE!
Sat Jul  8 11:05:42 ADT 2017
Starting root file system check:
/dev/rld0a: file system is clean; not checking
Not resizing /: already correct size
swapctl: adding /dev/ld0b as swap device at priority 0
Starting file system checks:
/dev/rld0e: 22 files, 32340 free (8085 clusters)
random_seed: /var/db/entropy-file: Not present
Setting tty flags.
Setting sysctl variables:
ddb.onpanic: 1 -> 1
Starting network.
Hostname: sunxi
IPv6 mode: host
Configuring network interfaces:.
Adding interface aliases:.
Waiting for DAD to complete for statically configured addresses...
Starting dhcpcd.
Starting mdnsd.
Building databases: dev, utmp, utmpx.
Starting syslogd.
Mounting all file systems...
Clearing temporary files.
Updating fontconfig cache: done.
Creating a.out runtime link editor directory cache.
Checking quotas: done.
Setting securelevel: kern.securelevel: 0 -> 1
Starting virecover.
Checking for core dump...
savecore: no core dump
Starting devpubd.
Starting local daemons:.
Updating motd.
Starting ntpd.
Jul  8 11:05:58 sunxi ntpd[595]: ntp_rlimit: Cannot set RLIMIT_STACK: Invalid argument
Starting sshd.
Starting inetd.
Starting cron.
Sat Jul  8 11:06:02 ADT 2017

NetBSD/evbarm (sunxi) (console)

login:

NetBSD is happy to announce a generous setup provided by Fastly to give us CDN services. We are live with cdn.NetBSD.org for downloading iso files, binary packages, and anything else that you would find on ftp.NetBSD.org.

nycdn is using nyftp.NetBSD.org as an origin so you can use it to download build snapshots and other useful stuff you would otherwise find on nyftp. (NetBSD-daily for example)

We have already changed some default download links (downloads and pkgsrc) and some pkgsrc files, so you might already be using the cdn without knowing it.

You can also change your PKG_PATH from ftp://ftp.netbsd.org to http://cdn.netbsd.org

HTTPS also works, but not IPv6

If you are not familiar, a CDN is a globally distributed set of caching proxy servers which makes downloading files faster when they are hot in the cache.

NetBSD is happy to announce a generous setup provided by Fastly to give us CDN services. We are live with cdn.NetBSD.org for downloading iso files, binary packages, and anything else that you would find on ftp.NetBSD.org.

nycdn is using nyftp.NetBSD.org as an origin so you can use it to download build snapshots and other useful stuff you would otherwise find on nyftp. (NetBSD-daily for example)

We have already changed some default download links (downloads and pkgsrc) and some pkgsrc files, so you might already be using the cdn without knowing it.

You can also change your PKG_PATH from ftp://ftp.netbsd.org to http://cdn.netbsd.org

HTTPS also works, but not IPv6

If you are not familiar, a CDN is a globally distributed set of caching proxy servers which makes downloading files faster when they are hot in the cache.

When I got my Sun T1000 machine, it came with a ~80 GB hard disk - good enough for a NetBSD installation, but a bit challenged when you want to use logical domains. Time to expand disk space, or maybe make it faster? But these 1U server machines do not offer a lot of room for extensions, and it is sometimes tricky to get hold of the official extension options nowadays.

So I had fun with disks and modern replacements again... (after the scsi2sd adventures).

The T1000 were offered in single 3.5" disk configurations (this is what I got) or with two 2.5" disks. The mainboard has two sata (sas?) connectors. But the disk tray in my machine is not usable for mounting two 2.5" HDs.

But: the machine has a spare PCIe slot:

and we support NVMe, so why not put a M.2 module in an adapter card in there? I tried and failed. I learned that the T1000's PCIe x4 slot is PCIe version 1, but modern NVMe modules do not fancy working in anything older than PCIe version 3.

Too bad, but whatever. I switched things around, my amd64 desktop machine got a faster "SSD" (i.e. the NVMe), another machine got the SSD freed from there and I ended up with a spare 128 GB sata SSD.

Now the T1000 had a sata connector free, but no way to place the disk and no power connector for it. The mainboard had a legacy 5/12V jack and the single disk used a strange power/sata connector:

but of course that could be replaced easily. I cut a Y-sata power split and one legacy 5/12V power connector from an old (broken) PSU and soldered a dual sata power connector cable that connected to the jack on the mainboard.

I found a small cavity in the at the front of the machine in the sheet separating PSU and disk from the fans and mainboard. Big enough to push a sata power connector and a sata connector through! So I just glued the SSD at the bottom of the chasis in front of the fans (it should be low enough to not harm airflow significantly):

It was a bit tricky to fit the custom power cabling and the standard sata cable alongside the disk, and I hope the disk will not get too hot to unsolder the connectors
Hardware service technicians would hate this, as usually the T1000 offers really easy and fast hard disk replacement, but I suppose no one but me will ever deal with hardware failure on this particular machine.

Now thats it, fast base system on SSD and plenty of space for other LDOMs data on the second disk:

mpt0 at pci3 dev 2 function 0: Symbios Logic SAS1064 (rev. 0x02)
mpt0: interrupting at ivec 7c0
mpt0: Phy 0: Link Status Unknown
mpt0: Phy 0: Link Status Unknown
scsibus0 at mpt0: 63 targets, 8 luns per target
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 0 lun 0:  disk fixed
sd0: 111 GB, 114474 cyl, 16 head, 127 sec, 512 bytes/sect x 234441648 sectors
sd0: tagged queueing
sd1 at scsibus0 target 1 lun 0:  disk fixed
sd1: 1863 GB, 1907730 cyl, 16 head, 127 sec, 512 bytes/sect x 3907029168 sectors
sd1: tagged queueing

Unfortunately the machine is louder than hell, and even though the rack is in our basement, the sound level is still irritating elsewhere in the house (massive stone walls, old style german construction). My wife officially hates the T1000.

Now that the hardware is ready, it is time to get it fully supported and import the LDOM management/utilities. I need to find time and help Palle!

When I got my Sun T1000 machine, it came with a ~80 GB hard disk - good enough for a NetBSD installation, but a bit challenged when you want to use logical domains. Time to expand disk space, or maybe make it faster? But these 1U server machines do not offer a lot of room for extensions, and it is sometimes tricky to get hold of the official extension options nowadays.

So I had fun with disks and modern replacements again... (after the scsi2sd adventures).

The T1000 were offered in single 3.5" disk configurations (this is what I got) or with two 2.5" disks. The mainboard has two sata (sas?) connectors. But the disk tray in my machine is not usable for mounting two 2.5" HDs.

But: the machine has a spare PCIe slot:

and we support NVMe, so why not put a M.2 module in an adapter card in there? I tried and failed. I learned that the T1000's PCIe x4 slot is PCIe version 1, but modern NVMe modules do not fancy working in anything older than PCIe version 3.

Too bad, but whatever. I switched things around, my amd64 desktop machine got a faster "SSD" (i.e. the NVMe), another machine got the SSD freed from there and I ended up with a spare 128 GB sata SSD.

Now the T1000 had a sata connector free, but no way to place the disk and no power connector for it. The mainboard had a legacy 5/12V jack and the single disk used a strange power/sata connector:

but of course that could be replaced easily. I cut a Y-sata power split and one legacy 5/12V power connector from an old (broken) PSU and soldered a dual sata power connector cable that connected to the jack on the mainboard.

I found a small cavity in the at the front of the machine in the sheet separating PSU and disk from the fans and mainboard. Big enough to push a sata power connector and a sata connector through! So I just glued the SSD at the bottom of the chasis in front of the fans (it should be low enough to not harm airflow significantly):

It was a bit tricky to fit the custom power cabling and the standard sata cable alongside the disk, and I hope the disk will not get too hot to unsolder the connectors
Hardware service technicians would hate this, as usually the T1000 offers really easy and fast hard disk replacement, but I suppose no one but me will ever deal with hardware failure on this particular machine.

Now thats it, fast base system on SSD and plenty of space for other LDOMs data on the second disk:

mpt0 at pci3 dev 2 function 0: Symbios Logic SAS1064 (rev. 0x02)
mpt0: interrupting at ivec 7c0
mpt0: Phy 0: Link Status Unknown
mpt0: Phy 0: Link Status Unknown
scsibus0 at mpt0: 63 targets, 8 luns per target
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 0 lun 0:  disk fixed
sd0: 111 GB, 114474 cyl, 16 head, 127 sec, 512 bytes/sect x 234441648 sectors
sd0: tagged queueing
sd1 at scsibus0 target 1 lun 0:  disk fixed
sd1: 1863 GB, 1907730 cyl, 16 head, 127 sec, 512 bytes/sect x 3907029168 sectors
sd1: tagged queueing

Unfortunately the machine is louder than hell, and even though the rack is in our basement, the sound level is still irritating elsewhere in the house (massive stone walls, old style german construction). My wife officially hates the T1000.

Now that the hardware is ready, it is time to get it fully supported and import the LDOM management/utilities. I need to find time and help Palle!

Google Code-In (GCi) is a project like Google Summer Of Code (GSoC), but for younger students. While GSoC is aimed at university students, i.e. for people usually of age 19 or older, GCi wants to recruit pupils for Open Source projects.

When applying for participation, every project had to create a large number of potentially small tasks for students. A task was meant to be two hours of work of an experienced developer, and feasible to be done by a person 13 to 18 years old. Google selected ten participating organisations (this time, NetBSD was the only BSD participating) to insert their tasks into Google Melange (the platform which is used for managing GCi and GSoC).

Then, the students registered at Google Melange, chose a project they wanted to work on, and claimed tasks to do. There were many chats in the NetBSD code channel for students coming in and asking questions about their tasks.

After GCi was over, every organisation had to choose their two favourite students who did the best work. For NetBSD, the choice was difficult, as there were more than two students doing great work, but in the end we chose Mingzhe Wang and Matthew Bauer. These two "grand price winners" were given a trip to Mountain View to visit the Google headquarters and meet with other GCi price winners.

You can see the results on the corresponding wiki page

There were 89 finished tasks, ranging from research tasks (document how other projects manage their documentation), creating howtos, trying out software on NetBSD, writing code (ATF tests and Markdown converters and more), writing manpages and documentation, fixing bugs and converting documentation from the website to the wiki.

Overall, it was a nice experience for NetBSD. On the one hand, some real work was done (for many of them, integration is still pending). On the other hand, it was a stressful time for the NetBSD mentors supervising the students and helping them on their tasks. Especially, we had to learn many lessons (you will find them on the wiki page for GCi 2012), but next time, we will do much better. We will try to apply again next year, but we will need a large bunch of new possible tasks to be chosen again.

So if you think you have a task which doesn't require great prior knowledge, and is solvable within two hours by an experienced developer, but also by a 13-18 year old within finite time, feel free to contact us with an outline, or write it directly to the wiki page for Code-In in the NetBSD wiki.

Support for Sun's SX rendering engine ( found in the SparcStation 20 and 10SX's memory controllers ) has been added, both for the console and X. Both drivers support basic acceleration ( block copy, rectangle fill, character drawing in the kernel ), the Xorg driver also supports Xrender acceleration. This probably makes SX the oldest supported hardware which can do that.

SX is more or less a vector processor built into a memory controller. The 'or less' part comes from the fact that it can't actually read instructions from memory - the CPU has to feed them one by one. This isn't quite as bad as it sounds - SX has plenty of registers ( 128 - eight of them have special functions, the rest is free for all ) and every instruction takes a count to operate on several subsequent registers or memory locations ( ALU ops can use up to 16, memory accesses up to 32 ). SX supports some parallelism too - the ALUs can do up to two 16bit multiplications and two other arithmetic or logical ops per clock cycle ( 32bit multiplications use both ALUs ). The thing runs at 50MHz - not a whole lot by today's standards but it can be a significant help to any CPUs you can put into these machines.

The kernel part hs been committed a while ago ( see cgfourteen at obio ), always runs in 8bit colour with everything ( scrolling, character drawing etc. ) done by SX. Substantially faster than software only operation.

The Xorg driver ( xf86-video-suncg14 that is, it needs a recent cgfourteen kernel driver to map SX registers ) uses EXA, by default it enables basic acceleration ( Solid and Copy, hardware cursor support has been added years ago ), Xrender acceleration is incomplete and can be enabled by adding Options "Xrender" "true" to the cg14's device section in xorg.conf. For now it implements what's needed for anti-aliased font drawing, assembling alpha maps in video memory and operations KDE3 uses for drawing icons, buttons and so on. As it is now KDE3 looks mostly right - there are a few rendering errors ( for example the corners of the white frame in Konqueror's startup page, also some text is drawn with red and blue channels switched ) but nothing that would interfere with functionality.

Speed isn't great ( well, the hardware is 20 years old ) but the improvement over unaccelerated X is more than noticeable. Some benchmark numbers, all taken on an SS20 with a single 125MHz HyperSPARC:

• x11perf -comppixwin went from 26.3 to 93.7
• x11perf -compwinwin went from 8.8 to 93.5
• x11perf -aaftext went from about 4000 ( 5000 with shadow fb but that's technically cheating since not everything is drawn into video memory ) to 16000

There is still room for improvement - for now all Xrender operations work on one pixel at a time, SX has enough registers to do at least four in most cases. Also, functionality is added as needed whenever I run into it, so other things are likely broken ( I know gtk2 is, but that's easy to fix ) which is why Xrender acceleration is disabled by default.

If you've been reading source-changes@, you likely noticed the recent creation of the netbsd-8 branch. If you haven't been reading source-changes@, here's some news: the netbsd-8 branch has been created, signaling the beginning of the release process for NetBSD 8.0.

We don't have a strict timeline for the 8.0 release, but things are looking pretty good at the moment, and we expect this release to happen in a shorter amount of time than the last couple major releases did.

At this point, we would love for folks to test out netbsd-8 and let us know how it goes. A couple of major improvements since 7.0 are the addition of USB 3 support and an overhaul of the audio subsystem, including an in-kernel mixer. Feedback about these areas is particularly desired.

To download the latest binaries built from the netbsd-8 branch, head to http://daily-builds.NetBSD.org/pub/NetBSD-daily/netbsd-8/

Thanks in advance for helping make NetBSD 8.0 a stellar release!

If you've been reading source-changes@, you likely noticed the recent creation of the netbsd-8 branch. If you haven't been reading source-changes@, here's some news: the netbsd-8 branch has been created, signaling the beginning of the release process for NetBSD 8.0.

We don't have a strict timeline for the 8.0 release, but things are looking pretty good at the moment, and we expect this release to happen in a shorter amount of time than the last couple major releases did.

At this point, we would love for folks to test out netbsd-8 and let us know how it goes. A couple of major improvements since 7.0 are the addition of USB 3 support and an overhaul of the audio subsystem, including an in-kernel mixer. Feedback about these areas is particularly desired.

To download the latest binaries built from the netbsd-8 branch, head to http://daily-builds.NetBSD.org/pub/NetBSD-daily/netbsd-8/

Thanks in advance for helping make NetBSD 8.0 a stellar release!

This month I started to work on correcting of the ptrace(2) layer, as test suites used to trigger failures on the kernel side. This finally ended up sanitizing the LLDB runtime as well, addressing LLDB and NetBSD userland bugs.

It turned out that more bugs were unveiled and this is not the final report on LLDB.

The good

Besides the greater enhancements this month I performed a cleanup in the ATF ptrace(2) tests again. Additionally I have managed to unbreak the LLDB Debug build and to eliminate compiler warnings in the NetBSD Native Process Plugin.

It is worth noting that LLVM can run tests on NetBSD again, the patch in gtest/LLVM has been installed by Joerg Sonnenberg and a more generic one has been submitted to the upstream googletest repository. There was also an improvement in ftruncate(2) on the LLVM side (authored by Joerg).

Since LLD (the LLVM linker) is advancing rapidly, it improved support for NetBSD and it can link a functional executable on NetBSD. I submitted a patch to stop crashing it on startup anymore. It was nearly used for linking LLDB/NetBSD and it spotted a real linking error... however there are further issues that need to be addressed in the future. Currently LLD is not part of the mainline LLDB tasks - it's part of improving the work environment. This linker should reduce the linking time - compared to GNU linkers - of LLDB by a factor of 3x-10x and save precious developer time. As of now LLDB linking can take minutes on a modern amd64 machine designed for performance.

Kernel correctness

I have researched (in pkgsrc-wip) initial support for multiple threads in the NetBSD Native Process Plugin. This code revealed - when running the LLDB regression test-suite - new kernel bugs. This unfortunately affects the usability of a debugger in a multithread environment in general and explains why GDB was never doing its job properly in such circumstances.

One of the first errors was asserting kernel panic with PT_*STEP, when a debuggee has more than a single thread. I have narrowed it down to lock primitives misuse in the do_ptrace() kernel code. The fix has been committed.

LLDB and userland correctness

LLDB introduced support for kevent(2) and it contains the following function:

Status MainLoop::RunImpl::Poll() {
  in_events.resize(loop.m_read_fds.size());
  unsigned i = 0;
  for (auto &fd : loop.m_read_fds)
    EV_SET(&in_events[i++], fd.first, EVFILT_READ, EV_ADD, 0, 0, 0);
  num_events = kevent(loop.m_kqueue, in_events.data(), in_events.size(),
                      out_events, llvm::array_lengthof(out_events), nullptr);
  if (num_events < 0)
    return Status("kevent() failed with error %d\n", num_events);
  return Status();
}

It works on FreeBSD and MacOSX, however it broke on NetBSD.

Culprit line:

   EV_SET(&in_events[i++], fd.first, EVFILT_READ, EV_ADD, 0, 0, 0);

FreeBSD defined EV_SET() as a macro this way:

#define EV_SET(kevp_, a, b, c, d, e, f) do {    \
        struct kevent *kevp = (kevp_);          \
        (kevp)->ident = (a);                    \
        (kevp)->filter = (b);                   \
        (kevp)->flags = (c);                    \
        (kevp)->fflags = (d);                   \
        (kevp)->data = (e);                     \
        (kevp)->udata = (f);                    \
} while(0)

NetBSD version was different:

#define EV_SET(kevp, a, b, c, d, e, f)                                  \
do {                                                                    \
        (kevp)->ident = (a);                                            \
        (kevp)->filter = (b);                                           \
        (kevp)->flags = (c);                                            \
        (kevp)->fflags = (d);                                           \
        (kevp)->data = (e);                                             \
        (kevp)->udata = (f);                                            \
} while (/* CONSTCOND */ 0)

This resulted in heap damage, as keyp was incremented every time a value was assigned to (keyp)->.

Without GCC asan and ubsan tools, finding this bug would be much more time consuming, as the random memory corruption was affecting unrelated lambda function in a different part of the code.

To use the GCC sanitizers with packages from pkgsrc, on NetBSD-current, one has to use one or both of these lines:

_WRAP_EXTRA_ARGS.CXX+= -fno-omit-frame-pointer -O0 -g -ggdb -U_FORTIFY_SOURCE -fsanitize=address -fsanitize=undefined -lasan -lubsan
CWRAPPERS_APPEND.cxx+= -fno-omit-frame-pointer -O0 -g -ggdb -U_FORTIFY_SOURCE -fsanitize=address -fsanitize=undefined -lasan -lubsan

While there, I have fixed another - generic - bug in the LLVM headers. The class Triple constructor hadn't initialized the SubArch field, which upsetting the GCC address sanitizer. It was triggered in LLDB in the following code:

void ArchSpec::Clear() {
  m_triple = llvm::Triple();
  m_core = kCore_invalid;
  m_byte_order = eByteOrderInvalid;
  m_distribution_id.Clear();
  m_flags = 0;
}

I have filed a patch for review to address this.

The bad

Unfortunately this is not the full story and there is further mandatory work.

LLDB acceleration

The EV_SET() bug broke upstream LLDB over a month ago, and during this period the debugger was significantly accelerated and parallelized. It is difficult to declare it definitely, but it might be the reason why the tracer's runtime broke due to threading desynchronization. LLDB behaves differently when run standalone, under ktruss(1) and under gdb(1) - the shared bug is that it always fails in one way or another, which isn't trivial to debug.

The ugly

There are also unpleasant issues at the core of the Operating System.

Kernel troubles

Another bug with single-step functions that affects another aspect of correctness - this time with reliable execution of a program - is that processes die in non-deterministic ways when single-stepped. My current impression is that there is no appropriate translation between process and thread (LWP) states under a debugger.

These issues are sibling problems to unreliable PT_RESUME and PT_SUSPEND.

In order to be able to appropriately address this, I have diligently studied this month the Solaris Internals book to get a better image of the design of the NetBSD kernel multiprocessing, which was modeled after this commercial UNIX.

Plan for the next milestone

The current troubles can be summarized as data races in the kernel and at the same time in LLDB. I have decided to port the LLVM sanitizers, as I require the Thread Sanitizer (tsan). Temporarily I have removed the code for tracing processes with multiple threads to hide the known kernel bugs and focus on the LLDB races.

Unfortunately LLDB is not easily bisectable (build time of the LLVM+Clang+LLDB stack, number of revisions), therefore the debugging has to be performed on the most recent code from upstream trunk.

This work was sponsored by The NetBSD Foundation.

The NetBSD Foundation is a non-profit organization and welcomes any donations to help us continue funding projects and services to the open-source community. Please consider visiting the following URL, and chip in what you can:

http://netbsd.org/donations/#how-to-donate

This month I started to work on correcting of the ptrace(2) layer, as test suites used to trigger failures on the kernel side. This finally ended up sanitizing the LLDB runtime as well, addressing LLDB and NetBSD userland bugs.

It turned out that more bugs were unveiled and this is not the final report on LLDB.

The good

Besides the greater enhancements this month I performed a cleanup in the ATF ptrace(2) tests again. Additionally I have managed to unbreak the LLDB Debug build and to eliminate compiler warnings in the NetBSD Native Process Plugin.

It is worth noting that LLVM can run tests on NetBSD again, the patch in gtest/LLVM has been installed by Joerg Sonnenberg and a more generic one has been submitted to the upstream googletest repository. There was also an improvement in ftruncate(2) on the LLVM side (authored by Joerg).

Since LLD (the LLVM linker) is advancing rapidly, it improved support for NetBSD and it can link a functional executable on NetBSD. I submitted a patch to stop crashing it on startup anymore. It was nearly used for linking LLDB/NetBSD and it spotted a real linking error... however there are further issues that need to be addressed in the future. Currently LLD is not part of the mainline LLDB tasks - it's part of improving the work environment. This linker should reduce the linking time - compared to GNU linkers - of LLDB by a factor of 3x-10x and save precious developer time. As of now LLDB linking can take minutes on a modern amd64 machine designed for performance.

Kernel correctness

I have researched (in pkgsrc-wip) initial support for multiple threads in the NetBSD Native Process Plugin. This code revealed - when running the LLDB regression test-suite - new kernel bugs. This unfortunately affects the usability of a debugger in a multithread environment in general and explains why GDB was never doing its job properly in such circumstances.

One of the first errors was asserting kernel panic with PT_*STEP, when a debuggee has more than a single thread. I have narrowed it down to lock primitives misuse in the do_ptrace() kernel code. The fix has been committed.

LLDB and userland correctness

LLDB introduced support for kevent(2) and it contains the following function:

Status MainLoop::RunImpl::Poll() {
  in_events.resize(loop.m_read_fds.size());
  unsigned i = 0;
  for (auto &fd : loop.m_read_fds)
    EV_SET(&in_events[i++], fd.first, EVFILT_READ, EV_ADD, 0, 0, 0);
  num_events = kevent(loop.m_kqueue, in_events.data(), in_events.size(),
                      out_events, llvm::array_lengthof(out_events), nullptr);
  if (num_events < 0)
    return Status("kevent() failed with error %d\n", num_events);
  return Status();
}

It works on FreeBSD and MacOSX, however it broke on NetBSD.

Culprit line:

   EV_SET(&in_events[i++], fd.first, EVFILT_READ, EV_ADD, 0, 0, 0);

FreeBSD defined EV_SET() as a macro this way:

#define EV_SET(kevp_, a, b, c, d, e, f) do {    \
        struct kevent *kevp = (kevp_);          \
        (kevp)->ident = (a);                    \
        (kevp)->filter = (b);                   \
        (kevp)->flags = (c);                    \
        (kevp)->fflags = (d);                   \
        (kevp)->data = (e);                     \
        (kevp)->udata = (f);                    \
} while(0)

NetBSD version was different:

#define EV_SET(kevp, a, b, c, d, e, f)                                  \
do {                                                                    \
        (kevp)->ident = (a);                                            \
        (kevp)->filter = (b);                                           \
        (kevp)->flags = (c);                                            \
        (kevp)->fflags = (d);                                           \
        (kevp)->data = (e);                                             \
        (kevp)->udata = (f);                                            \
} while (/* CONSTCOND */ 0)

This resulted in heap damage, as keyp was incremented every time a value was assigned to (keyp)->.

Without GCC asan and ubsan tools, finding this bug would be much more time consuming, as the random memory corruption was affecting unrelated lambda function in a different part of the code.

To use the GCC sanitizers with packages from pkgsrc, on NetBSD-current, one has to use one or both of these lines:

_WRAP_EXTRA_ARGS.CXX+= -fno-omit-frame-pointer -O0 -g -ggdb -U_FORTIFY_SOURCE -fsanitize=address -fsanitize=undefined -lasan -lubsan
CWRAPPERS_APPEND.cxx+= -fno-omit-frame-pointer -O0 -g -ggdb -U_FORTIFY_SOURCE -fsanitize=address -fsanitize=undefined -lasan -lubsan

While there, I have fixed another - generic - bug in the LLVM headers. The class Triple constructor hadn't initialized the SubArch field, which upsetting the GCC address sanitizer. It was triggered in LLDB in the following code:

void ArchSpec::Clear() {
  m_triple = llvm::Triple();
  m_core = kCore_invalid;
  m_byte_order = eByteOrderInvalid;
  m_distribution_id.Clear();
  m_flags = 0;
}

I have filed a patch for review to address this.

The bad

Unfortunately this is not the full story and there is further mandatory work.

LLDB acceleration

The EV_SET() bug broke upstream LLDB over a month ago, and during this period the debugger was significantly accelerated and parallelized. It is difficult to declare it definitely, but it might be the reason why the tracer's runtime broke due to threading desynchronization. LLDB behaves differently when run standalone, under ktruss(1) and under gdb(1) - the shared bug is that it always fails in one way or another, which isn't trivial to debug.

The ugly

There are also unpleasant issues at the core of the Operating System.

Kernel troubles

Another bug with single-step functions that affects another aspect of correctness - this time with reliable execution of a program - is that processes die in non-deterministic ways when single-stepped. My current impression is that there is no appropriate translation between process and thread (LWP) states under a debugger.

These issues are sibling problems to unreliable PT_RESUME and PT_SUSPEND.

In order to be able to appropriately address this, I have diligently studied this month the Solaris Internals book to get a better image of the design of the NetBSD kernel multiprocessing, which was modeled after this commercial UNIX.

Plan for the next milestone

The current troubles can be summarized as data races in the kernel and at the same time in LLDB. I have decided to port the LLVM sanitizers, as I require the Thread Sanitizer (tsan). Temporarily I have removed the code for tracing processes with multiple threads to hide the known kernel bugs and focus on the LLDB races.

Unfortunately LLDB is not easily bisectable (build time of the LLVM+Clang+LLDB stack, number of revisions), therefore the debugging has to be performed on the most recent code from upstream trunk.

This work was sponsored by The NetBSD Foundation.

The NetBSD Foundation is a non-profit organization and welcomes any donations to help us continue funding projects and services to the open-source community. Please consider visiting the following URL, and chip in what you can:

http://netbsd.org/donations/#how-to-donate

Hello all,

the repository conversion setup for NetBSD CVS -> Fossil -> Git has found a new home. Ironically, on former cvs.NetBSD.org hardware. This provides a somewhat faster conversion cycle as well as removing anoncvs.NetBSD.org from the process. This should avoid occasional problems with incomplete syncs. Two other changes have been applied at the same time:

• The Fossil repositories have moved to using the SHA512 checksums internally. To avoid accidents, a new project code is used. This requires Fossil 2.x.
• The Git repositories map user names to @NetBSD.org addresses (src, xsrc) or @pkgsrc.org addresses (pkgsrc). This allows consolidation on github with user accounts, assuming you have the corresponding addresses as primary or secondary address.

The new locations for the repositories are:

CVS	Fossil	Git
src	https://src.fossil.NetBSD.org	https://github.com/NetBSD/src
pkgsrc	https://pkgsrc.fossil.NetBSD.org	https://github.com/NetBSD/pkgsrc
xsrc	https://xsrc.fossil.NetBSD.org	https://github.com/NetBSD/xsrc

The old conversions will be provided for the near future, but likely stop toward the end of the month.

A special thanks goes to Petra and Christos from the admin team for the assistance with the machine setup and low-level CVS clean-ups.

Joerg

-- source https://mail-index.netbsd.org/tech-repository/2017/06/10/msg000637.html

Hello all,

the repository conversion setup for NetBSD CVS -> Fossil -> Git has found a new home. Ironically, on former cvs.NetBSD.org hardware. This provides a somewhat faster conversion cycle as well as removing anoncvs.NetBSD.org from the process. This should avoid occasional problems with incomplete syncs. Two other changes have been applied at the same time:

• The Fossil repositories have moved to using the SHA512 checksums internally. To avoid accidents, a new project code is used. This requires Fossil 2.x.
• The Git repositories map user names to @NetBSD.org addresses (src, xsrc) or @pkgsrc.org addresses (pkgsrc). This allows consolidation on github with user accounts, assuming you have the corresponding addresses as primary or secondary address.

The new locations for the repositories are:

CVS	Fossil	Git
src	https://src.fossil.NetBSD.org	https://github.com/NetBSD/src
pkgsrc	https://pkgsrc.fossil.NetBSD.org	https://github.com/NetBSD/pkgsrc
xsrc	https://xsrc.fossil.NetBSD.org	https://github.com/NetBSD/xsrc

The old conversions will be provided for the near future, but likely stop toward the end of the month.

A special thanks goes to Petra and Christos from the admin team for the assistance with the machine setup and low-level CVS clean-ups.

Joerg

-- source https://mail-index.netbsd.org/tech-repository/2017/06/10/msg000637.html

Nicolas Joly passed away on 2017-06-07.

Born in 1969, he developed a passion for computer science in his youth but chose to study biology. He then attended a bioinformatics training at the Pasteur Institute in 1997 at the end of which he got hired in the scientific IT department. He has continuously worked there since. Not only was he skilled in biology but also in system administration, databases, and programming.

He was introduced to NetBSD in 1999 and quickly became a dedicated user and hacker. He became a NetBSD developer in 2007 for working on Linux/i386 (32 bits) emulation on NetBSD/amd64 (64 bits).

Nicolas leaves a wife and three children.

Memorial note submitted by Marc Baudoin.

Nicolas Joly passed away on 2017-06-07.

Born in 1969, he developed a passion for computer science in his youth but chose to study biology. He then attended a bioinformatics training at the Pasteur Institute in 1997 at the end of which he got hired in the scientific IT department. He has continuously worked there since. Not only was he skilled in biology but also in system administration, databases, and programming.

He was introduced to NetBSD in 1999 and quickly became a dedicated user and hacker. He became a NetBSD developer in 2007 for working on Linux/i386 (32 bits) emulation on NetBSD/amd64 (64 bits).

Nicolas leaves a wife and three children.

Memorial note submitted by Marc Baudoin.

I didn't really have much time to work on more hardware support on CI20 but it's been a while since the last post so here's what I've got:

• drivers for on-chip ehci and ohci have been added. Ohci works fine, ehci for some reason detects all high speed devices as full speed and hands them over to ohci. No idea why.
• I2C ports work now, including the onboard RTC. You have to hook up your own battery though.
• we're no longer limited to 256MB, all RAM is usable now.
• onboard ethernet is supported by the dme driver.

There's also an unfinished driver for the SD/MMC ports.
The RTC is a bit funny - according to the manual there's a Pericom RTC on iic4 addr 0x68 - not on my preproduction board. I've got something that looks like a PCF8563 at addr 0x51, and so do the production boards that I know of. Some pins on one of the expansion connectors seem to be for a battery but I haven't been able to confirm that yet. Either way, since the main connector is supposed to be Raspberry Pi compatible any RTC module for the RPi should Just Work(tm), with the appropriate line added to the kernel config.
Some more work has been done under the hood, like some preparations for SMP support.

Here's the obligatory boot transcript, complete with incomplete drivers and debug spam:

U-Boot SPL 2013.10-rc3-g9329ab16a204 (Jun 26 2014 - 09:43:22)
SDRAM H5TQ2G83CFR initialization... done


U-Boot 2013.10-rc3-g9329ab16a204 (Jun 26 2014 - 09:43:22)

Board: ci20 (Ingenic XBurst JZ4780 SoC)
DRAM:  1 GiB
NAND:  8192 MiB
MMC:   jz_mmc msc1: 0
In:    eserial3
Out:   eserial3
Err:   eserial3
Net:   dm9000
ci20# dhcp
ERROR: resetting DM9000 -> not responding
dm9000 i/o: 0xb6000000, id: 0x90000a46 
DM9000: running in 8 bit mode
MAC: d0:31:10:ff:7e:89
operating at 100M full duplex mode
BOOTP broadcast 1
DHCP client bound to address 192.168.0.47
*** Warning: no boot file name; using 'C0A8002F.img'
Using dm9000 device
TFTP from server 192.168.0.44; our IP address is 192.168.0.47
Filename 'C0A8002F.img'.
Load address: 0x88000000
Loading: #################################################################
     ##############################################
     369.1 KiB/s
done
Bytes transferred = 1621771 (18bf0b hex)
ci20# bootm
## Booting kernel from Legacy Image at 88000000 ...
   Image Name:   evbmips 7.99.18 (CI20)
   Image Type:   MIPS NetBSD Kernel Image (gzip compressed)
   Data Size:    1621707 Bytes = 1.5 MiB
   Load Address: 80020000
   Entry Point:  80020000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
subcommand not supported
ci20# g 80020000
## Starting application at 0x80020000 ...
pmap_steal_memory: seg 0: 0x6bf 0x6bf 0xffff 0xffff
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 7.99.18 (CI20) #20: Thu Jun 11 13:06:41 EDT 2015
    ml@blackbush:/home/build/obj_evbmips32/sys/arch/evbmips/compile/CI20
Ingenic XBurst
total memory = 1024 MB
avail memory = 997 MB
mainbus0 (root)
cpu0 at mainbus0: 1200.00MHz (hz cycles = 120000, delay divisor = 12)
cpu0: Ingenic XBurst (0x3ee1024f) Rev. 79 with unknown FPC type (0x330000) Rev. 0
cpu0: 32 TLB entries, 16MB max page size
cpu0: 32KB/32B 8-way set-associative L1 instruction cache
cpu0: 32KB/32B 8-way set-associative write-back L1 data cache
com0 at mainbus0: Ingenic UART, working fifo
com0: console

apbus0 at mainbus0
JZ_CLKGR0 3f587fe0
JZ_CLKGR1 000073e0
JZ_SPCR0  00000000
JZ_SPCR1  00000000
JZ_SRBC   00000002
JZ_OPCR   000015e6
JZ_UHCCDR c0000000
dwctwo0 at apbus0 addr 0x13500000 irq 21: USB OTG controller
ohci0 at apbus0 addr 0x134a0000 irq 5: OHCI USB controller
ohci0: OHCI version 1.0
usb0 at ohci0: USB revision 1.0
ehci0 at apbus0 addr 0x13490000 irq 20: EHCI USB controller
48352 46418
UHCCDR: c0000000
UHCCDR: 60000017
caplength 10
ehci0: companion controller, 1 port each: ohci0
usb1 at ehci0: USB revision 2.0
dme0 at apbus0 addr 0x16000000: DM9000 Ethernet controller
jzgpio at apbus0 addr 0x10010000 not configured
jzgpio at apbus0 addr 0x10010100 not configured
jzgpio at apbus0 addr 0x10010200 not configured
jzgpio at apbus0 addr 0x10010300 not configured
jzgpio at apbus0 addr 0x10010400 not configured
jzgpio at apbus0 addr 0x10010500 not configured
jziic0 at apbus0 addr 0x10050000 irq 60: SMBus controller
iic0 at jziic0: I2C bus
jziic1 at apbus0 addr 0x10051000 irq 59: SMBus controller
iic1 at jziic1: I2C bus
jziic2 at apbus0 addr 0x10052000 irq 58: SMBus controller
iic2 at jziic2: I2C bus
jziic3 at apbus0 addr 0x10053000 irq 57: SMBus controller
iic3 at jziic3: I2C bus
jziic4 at apbus0 addr 0x10054000 irq 56: SMBus controller
iic4 at jziic4: I2C bus
pcf8563rtc0 at iic4 addr 0x51: NXP PCF8563 Real-time Clock
jzmmc0 at apbus0 addr 0x13450000 irq 37: SD/MMC controller
25227 24176
jzmmc0: going to use 25227 kHz
MSC*CDR: 80000000
sdmmc0 at jzmmc0
jzmmc1 at apbus0 addr 0x13460000 irq 36: SD/MMC controller
25227 24176
jzmmc1: going to use 25227 kHz
MSC*CDR: 20000018
sdmmc1 at jzmmc1
jzmmc2 at apbus0 addr 0x13470000 irq 35: SD/MMC controller
25227 24176
jzmmc2: going to use 25227 kHz
MSC*CDR: 00000000
sdmmc2 at jzmmc2
jzfb at apbus0 addr 0x13050000 not configured
JZ_CLKGR0 2c586780
JZ_CLKGR1 000060e0
usb2 at dwctwo0: USB revision 2.0
starting timer interrupt...
jzmmc_bus_clock: 400
sh: 6 freq: 394
sdmmc0: couldn't identify card
sdmmc0: no functions
jzmmc_bus_clock: 0
sh: 7 freq: 197
jzmmc_bus_clock: 400
sh: 6 freq: 394
sdmmc1: couldn't identify card
sdmmc1: no functions
jzmmc_bus_clock: 0
sh: 7 freq: 197
jzmmc_bus_clock: 400
sh: 6 freq: 394
sdmmc2: couldn't identify card
sdmmc2: no functions
jzmmc_bus_clock: 0
sh: 7 freq: 197
uhub0 at usb0: Ingenic OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1 at usb1: Ingenic EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub2 at usb2: Ingenic DWC2 root hub, class 9/0, rev 2.00/1.00, addr 1
PS_LS(1): 00001801
port1: 00001801
port2: 00000000
ehci0: handing over full speed device on port 1 to ohci0
umass0 at uhub2 port 1 configuration 1 interface 0
umass0: Generic Mass Storage Device, rev 2.00/1.05, addr 2
scsibus0 at umass0: 2 targets, 1 lun per target
sd0 at scsibus0 target 0 lun 0:  disk removable
sd0: fabricating a geometry
sd0: 15193 MB, 15193 cyl, 64 head, 32 sec, 512 bytes/sect x 31116288 sectors
root on sd0a dumps on sd0b
sd0: fabricating a geometry
/: replaying log to memory
kern.module.path=/stand/evbmips/7.99.18/modules
pid 1(init): ABI set to O32 (e_flags=0x70001007)
Thu Jun 11 07:15:08 GMT 2015
uhub3 at uhub0 port 1: Terminus Technology USB 2.0 Hub [MTT], class 9/0, rev 2.00/1.00, addr 2
Starting root file system check:
/dev/rsd0a: file system is journaled; not checking
/: replaying log to disk
umass1 at uhub3 port 5 configuration 1 interface 0
umass1: LaCie P'9220 Mobile Drive, rev 2.10/0.06, addr 3
scsibus1 at umass1: 2 targets, 1 lun per target
sd1 at scsibus1 target 0 lun 0:  disk fixed
sd1: 465 GB, 16383 cyl, 16 head, 63 sec, 512 bytes/sect x 976773168 sectors
swapctl: adding /dev/sd1b as swap device at priority 0
Starting file system checks:
/dev/rsd0e: file system is journaled; not checking
/dev/rsd0g: file system is journaled; not checking
/dev/rsd0f: 1 files, 249856 free (31232 clusters)
/dev/rsd1e: file system is journaled; not checking
random_seed: /var/db/entropy-file: Not present
Setting tty flags.
Setting sysctl variables:
ddb.onpanic: 1 -> 0
Starting network.
Hostname: ci20
IPv6 mode: autoconfigured host
Configuring network interfaces: dme0.
Adding interface aliases:.
add net default: gateway 192.168.0.1
Waiting for DAD to complete for statically configured addresses...
/usr: replaying log to disk
Building databases: dev, dev, utmp, utmpx.
Starting syslogd.
Starting rpcbind.
Mounting all file systems...
/stuff: replaying log to disk
/home: replaying log to disk
Clearing temporary files.
Updating fontconfig cache: done.
Checking quotas: done.
/etc/rc: WARNING: /etc/exports is not readable.
/etc/rc.d/mountd exited with code 1
Setting securelevel: kern.securelevel: 0 -> 1
Starting virecover.
Checking for core dump...
savecore: no core dump
Starting local daemons:.
Updating motd.
Starting ntpd.
Starting sshd.
Starting mdnsd.
Jun 11 03:23:01 ci20 mdnsd: mDNSResponder (Engineering Build) starting
Starting inetd.
Starting cron.
The following components reported failures:
    /etc/rc.d/mountd
See /var/run/rc.log for more information.
Thu Jun 11 03:23:02 EDT 2015

NetBSD/evbmips (ci20) (console)

login:

On behalf of the NetBSD project, it is my pleasure to announce the first release candidate of NetBSD 7.0.

Many changes have been made since 6.0. Here are a few highlights:

• Greatly improved support for modern Intel and Radeon graphics hardware through a port of the Linux DRM/KMS code. Most X.Org components have been updated as well.
• ARM multiprocessor support
• Support for new ARM boards, some of which are listed below:
• Raspberry Pi 2
• ODROID-C1
• BeagleBoard-xM
• BeagleBone
• BeagleBone Black
• Banana Pi
• Cubieboard 2
• Cubietruck
• Merii Hummingbird
• Marvell ARMADA XP
• GlobalScale MiraBox
• Kobo
• Sharp Netwalker PC-Z1
• GPT support in sysinst
• Lua kernel scripting
• Multiprocessor USB stack
• Many improvements to NPF, the NetBSD packet filter
• GCC 4.8.4 (and optionally, LLVM/Clang 3.6.1)

Binaries of NetBSD 7.0_RC1 are available for download at:

http://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0_RC1/

Those who prefer to build from source can either use the netbsd-7-0-RC1 tag or follow the netbsd-7 branch.

Please help us out by testing 7.0_RC1. We love any and all feedback. Report problems through the usual channels (submit a PR or write to the appropriate list). More general feedback is welcome at releng@NetBSD.org. Your input will help us put the finishing touches on what promises to be a great release!

Sitting in one of the nice pubs in Edinburgh during KohaCon, I had the idea to add MARC records as a proper datatype to the PostgreSQL database server. After a discussion with Marc Véron and Dobrica Pavlinusic about what that could mean, I decided to just try it and I have now a basic implementation (or, more a proof of concept). So here is some information on this:

read more

The pkgsrc team has prepared the 50th release of their package management system, with the 2016Q1 version. It's infrequent event, as the 100th release will be held after 50 quarters.

The NetBSD team has prepared series of interviews with the authors. The 2nd one is with Sevan Janiyan, a developer well known for his bulk builds for several platforms.

Hi Sevan, please introduce yourself.

Hello,

I'm Sevan Janiyan. A sysadmin from England and a NetBSD developer, working on the pkgsrc packaging system. My areas of focus are pkgsrc security and Darwin (PowerPC) but as I enjoy running many operating systems I manage builds on a variety of them across different CPU architectures. I was a user of pkgsrc for many years but only started working on pkgsrc itself early 2014 when I obtained a PowerBook from a friend and started fixing issues on OS X Tiger/PowerPC. I was invited to become a member of TNF in 2015.

First of all, congratulations on the 50th release of pkgsrc! How do you feel about this anniversary?

It's fantastic to see a tool that has evolved over time, it's extremely flexible and has grown support for numerous operating systems during this period. Not only can it serve as the native packaging system for most OS' but thanks to its multi platform support, it can be used to save a lot of effort in implementing a packaging system on a project when a set of packages need to be built and deployed in a consistent manner across multiple operating systems.

What are the main benefits of the pkgsrc system?

The ability the provide a single API for dealing with multiple environments & toolchains, for example translating a setting to the relevant flags to compliment the compiler in use.

Unprivileged mode allows a user to build the tools they require in a location which executables are permitted and the user has write access e.g your home directory when the partition it resides on is not mounted noexec

The buildlink framework - it provides the ability to detect components available on the host operating system & allows a user the choice whether to build against such a component or to opt for a version provided by pkgsrc itself.

Where and how do you use pkgsrc?

pkgsrc is an essential part of my sysadmin tool belt, on one hand I rely on it to obtain a set of packages on a system without touching the systems packaging system. This is for example on a customer system where I either have not been given root access or I do not wish to install a package on a system with a big dependency list for my personal use.

The packages in pkgsrc generally see very little in terms of local changes, besides tweaks to ensure package integrates into the system. This encourages interaction from developers with projects to upstream changes. This can be a benefit when debugging software issues where it is not certain if the issue exists in the version of software package from OS vendor or there is a bug in the software project upstream.

The ability to bootstrap multiple instances of the packaging system under different prefixes permits a user to install multiple and conflicting versions of software in isolated locations on a system.

As a use case, I worked on a project troubleshooting a clients varnish instance. The issues they were experiencing was specific to the version packaged for their OS by vendor. This was varnish 3.x and 4.1.0 had just been released, we decided to evaluate varnish 4.1.0 but as there were changes to the configuration language some development would need to by carried out, to adapt things to the new syntax. To reduce downtime the instance of varnish installed using the native package manager was left untouched and continued running, pkgsrc was bootstrapped in a separate location and varnish was installed from there. The development work to bring the config up to date happened with the new version of varnish from pkgsrc listening on a different port, but running alongside the original 3.x instance. Switching between the two instances was just a matter of changing ports to forward traffic to on the front-end web servers. Unfortunately 4.1.0 release had some bugs, so we considered trying 4.0.x. Another instance of pkgsrc was bootstrapped & v4.0.x was installed, again running on another port. This instance was brought up alongside the other two instance and started receiving traffic, at this point it was trivial to evaluate behaviour across 3 different versions of a piece of software running on a single host.

What are the pkgsrc projects you are currently working on?

I've worked very little in the tree recently. I continue to run the bulk builds of pkgsrc-current on a variety of systems and have recently begun making the packages generated from some of these builds for people to be able evaluate pkgsrc. At present there are packages for OS X Tiger (PowerPC), Debian Linux (amd64 & armv7), FreeBSD (amd64) and OmniOS published on https://files.venture37.com/pkgsrc/packages

Debian/armv7
http://mail-index.netbsd.org/pkgsrc-users/2016/03/22/msg023192.html

Debian/amd64
http://mail-index.netbsd.org/pkgsrc-users/2016/03/26/msg023209.html

FreeBSD/amd64
http://mail-index.netbsd.org/pkgsrc-users/2016/03/29/msg023222.html

If you analyze the current state of pkgsrc, which improvements and changes do you wish for the future?

A better mechanism for running the bulkbuilds or to grok how to setup the parallel builds.

Do you have any practical tips to share with the pkgsrc users?

As I mentioned with the varnish example, you can save a considerable amount of effort when required to run multiple instances of conflicting components by using pkgsrc. As everything isolated to a given prefix, specified during bootstrap, it's trivial to run multiple versions of Ruby for example without any conflict.

You can leverage this to experiment with changes which could be deemed volatile using other means.

What's the best way to start contributing to pkgsrc and what needs to be done?

Pick an OS from list, try to bootstrap pkgsrc on it, try to install some packages. If the process failed at any stage, file a bug report even better if the report includes a patch.

Rinse, repeat

If you have resources to attempt larger builds, follow the steps to setup a bulk build environment and run a build. The results ideally should be published on a public webserver & the report posted to the pkgsrc-bulk list, developers and maintainers use these reports to see problems and it could serve as a starting point for a potential contributor as a list of things that need to be fixed.

Bulktracker also makes use of these reports to build a picture of the status of packages and their impact across multiple platforms.

Do you plan to participate in the upcoming pkgsrcCon 2016 in Kraków (1-3 July)?

Yes, see you there

Sevan

The pkgsrc team has prepared the 50th release of their package management system, with the 2016Q1 version. It's infrequent event, as the 100th release will be held after 50 quarters.

The NetBSD team has prepared series of interviews with the authors. The 2nd one is with Sevan Janiyan, a developer well known for his bulk builds for several platforms.

Hi Sevan, please introduce yourself.

Hello,

I'm Sevan Janiyan. A sysadmin from England and a NetBSD developer, working on the pkgsrc packaging system. My areas of focus are pkgsrc security and Darwin (PowerPC) but as I enjoy running many operating systems I manage builds on a variety of them across different CPU architectures. I was a user of pkgsrc for many years but only started working on pkgsrc itself early 2014 when I obtained a PowerBook from a friend and started fixing issues on OS X Tiger/PowerPC. I was invited to become a member of TNF in 2015.

First of all, congratulations on the 50th release of pkgsrc! How do you feel about this anniversary?

It's fantastic to see a tool that has evolved over time, it's extremely flexible and has grown support for numerous operating systems during this period. Not only can it serve as the native packaging system for most OS' but thanks to its multi platform support, it can be used to save a lot of effort in implementing a packaging system on a project when a set of packages need to be built and deployed in a consistent manner across multiple operating systems.

What are the main benefits of the pkgsrc system?

The ability the provide a single API for dealing with multiple environments & toolchains, for example translating a setting to the relevant flags to compliment the compiler in use.

Unprivileged mode allows a user to build the tools they require in a location which executables are permitted and the user has write access e.g your home directory when the partition it resides on is not mounted noexec

The buildlink framework - it provides the ability to detect components available on the host operating system & allows a user the choice whether to build against such a component or to opt for a version provided by pkgsrc itself.

Where and how do you use pkgsrc?

pkgsrc is an essential part of my sysadmin tool belt, on one hand I rely on it to obtain a set of packages on a system without touching the systems packaging system. This is for example on a customer system where I either have not been given root access or I do not wish to install a package on a system with a big dependency list for my personal use.

The packages in pkgsrc generally see very little in terms of local changes, besides tweaks to ensure package integrates into the system. This encourages interaction from developers with projects to upstream changes. This can be a benefit when debugging software issues where it is not certain if the issue exists in the version of software package from OS vendor or there is a bug in the software project upstream.

The ability to bootstrap multiple instances of the packaging system under different prefixes permits a user to install multiple and conflicting versions of software in isolated locations on a system.

As a use case, I worked on a project troubleshooting a clients varnish instance. The issues they were experiencing was specific to the version packaged for their OS by vendor. This was varnish 3.x and 4.1.0 had just been released, we decided to evaluate varnish 4.1.0 but as there were changes to the configuration language some development would need to by carried out, to adapt things to the new syntax. To reduce downtime the instance of varnish installed using the native package manager was left untouched and continued running, pkgsrc was bootstrapped in a separate location and varnish was installed from there. The development work to bring the config up to date happened with the new version of varnish from pkgsrc listening on a different port, but running alongside the original 3.x instance. Switching between the two instances was just a matter of changing ports to forward traffic to on the front-end web servers. Unfortunately 4.1.0 release had some bugs, so we considered trying 4.0.x. Another instance of pkgsrc was bootstrapped & v4.0.x was installed, again running on another port. This instance was brought up alongside the other two instance and started receiving traffic, at this point it was trivial to evaluate behaviour across 3 different versions of a piece of software running on a single host.

What are the pkgsrc projects you are currently working on?

I've worked very little in the tree recently. I continue to run the bulk builds of pkgsrc-current on a variety of systems and have recently begun making the packages generated from some of these builds for people to be able evaluate pkgsrc. At present there are packages for OS X Tiger (PowerPC), Debian Linux (amd64 & armv7), FreeBSD (amd64) and OmniOS published on https://files.venture37.com/pkgsrc/packages

Debian/armv7
http://mail-index.netbsd.org/pkgsrc-users/2016/03/22/msg023192.html

Debian/amd64
http://mail-index.netbsd.org/pkgsrc-users/2016/03/26/msg023209.html

FreeBSD/amd64
http://mail-index.netbsd.org/pkgsrc-users/2016/03/29/msg023222.html

If you analyze the current state of pkgsrc, which improvements and changes do you wish for the future?

A better mechanism for running the bulkbuilds or to grok how to setup the parallel builds.

Do you have any practical tips to share with the pkgsrc users?

As I mentioned with the varnish example, you can save a considerable amount of effort when required to run multiple instances of conflicting components by using pkgsrc. As everything isolated to a given prefix, specified during bootstrap, it's trivial to run multiple versions of Ruby for example without any conflict.

You can leverage this to experiment with changes which could be deemed volatile using other means.

What's the best way to start contributing to pkgsrc and what needs to be done?

Pick an OS from list, try to bootstrap pkgsrc on it, try to install some packages. If the process failed at any stage, file a bug report even better if the report includes a patch.

Rinse, repeat

If you have resources to attempt larger builds, follow the steps to setup a bulk build environment and run a build. The results ideally should be published on a public webserver & the report posted to the pkgsrc-bulk list, developers and maintainers use these reports to see problems and it could serve as a starting point for a potential contributor as a list of things that need to be fixed.

Bulktracker also makes use of these reports to build a picture of the status of packages and their impact across multiple platforms.

Do you plan to participate in the upcoming pkgsrcCon 2016 in Kraków (1-3 July)?

Yes, see you there

Sevan

The pkgsrc team has prepared the 50th release of their package management system, with the 2016Q1 version. It's infrequent event, as the 100th release will be held after 50 quarters.

The NetBSD team has prepared series of interviews with the authors. The 3rd one is with Thomas Klausner, a developer well known for his maintainership of the pkgsrc-wip project.

First of all, congratulations on the 50th release of pkgsrc! How do you feel about this anniversary?

I'm very glad that pkgsrc that so many people find pkgsrc useful and like working on it, both on pkgsrc itself and pkgsrc-wip.

What are the main benefits of the pkgsrc system?

Get packages installed on your system, and keep them up-to-date, and don't worry about the underlying operating system.

Where and how do you use pkgsrc?

I use pkgsrc on my desktop machine at home and on various servers.

What are the pkgsrc projects you are currently working on?

Currently I have no single big project. I regularly try to keep a couple of hundred packages up-to-date, and to feed back patches upstream, so more software builds out-of-the-box. This also has the advantages of making updates easier, and spreading awareness of pkgsrc and NetBSD. Recently I've been more focusing on pushing upstream the pkgsrc patches for firefox.

If you analyze the current state of pkgsrc, which improvements and changes do you wish for the future?

A recent issue is that we need to add a framework for PaX security features; luckily, this is already implemented and just needs merging. Longer term I think our binary package tools could use some love and fresh code.

Do you have any practical tips to share with the pkgsrc users?

If you build your packages yourself, then use pkgtools/mksandbox to create sandboxes and run bulk builds inside them using pkgtools/pbulk. It makes life in general and updates in particular so much easier!

What's the best way to start contributing to pkgsrc and what needs to be done?

The easiest way is to start using pkgsrc on your own machines. Once you feel comfortable with that you'll probably notice that you want to update a package, or add a new one. If you reach that point, visit http://pkgsrc.org/wip/ to get commit access to the pkgsrc wip repository.

If you need help, contact the pkgsrc-users mailing list or visit us in #pkgsrc on freenode!

Do you plan to participate in the upcoming pkgsrcCon 2016 in Kraków (1-3 July)?

Definitely! I'm looking forward to meeting other pkgsrc developers again or for the first time, and to many interesting talks.

Cheers,
Thomas

The pkgsrc team has prepared the 50th release of their package management system, with the 2016Q1 version. It's infrequent event, as the 100th release will be held after 50 quarters.

The NetBSD team has prepared series of interviews with the authors. The 3rd one is with Thomas Klausner, a developer well known for his maintainership of the pkgsrc-wip project.

First of all, congratulations on the 50th release of pkgsrc! How do you feel about this anniversary?

I'm very glad that pkgsrc that so many people find pkgsrc useful and like working on it, both on pkgsrc itself and pkgsrc-wip.

What are the main benefits of the pkgsrc system?

Get packages installed on your system, and keep them up-to-date, and don't worry about the underlying operating system.

Where and how do you use pkgsrc?

I use pkgsrc on my desktop machine at home and on various servers.

What are the pkgsrc projects you are currently working on?

Currently I have no single big project. I regularly try to keep a couple of hundred packages up-to-date, and to feed back patches upstream, so more software builds out-of-the-box. This also has the advantages of making updates easier, and spreading awareness of pkgsrc and NetBSD. Recently I've been more focusing on pushing upstream the pkgsrc patches for firefox.

If you analyze the current state of pkgsrc, which improvements and changes do you wish for the future?

A recent issue is that we need to add a framework for PaX security features; luckily, this is already implemented and just needs merging. Longer term I think our binary package tools could use some love and fresh code.

Do you have any practical tips to share with the pkgsrc users?

If you build your packages yourself, then use pkgtools/mksandbox to create sandboxes and run bulk builds inside them using pkgtools/pbulk. It makes life in general and updates in particular so much easier!

What's the best way to start contributing to pkgsrc and what needs to be done?

The easiest way is to start using pkgsrc on your own machines. Once you feel comfortable with that you'll probably notice that you want to update a package, or add a new one. If you reach that point, visit http://pkgsrc.org/wip/ to get commit access to the pkgsrc wip repository.

If you need help, contact the pkgsrc-users mailing list or visit us in #pkgsrc on freenode!

Do you plan to participate in the upcoming pkgsrcCon 2016 in Kraków (1-3 July)?

Definitely! I'm looking forward to meeting other pkgsrc developers again or for the first time, and to many interesting talks.

Cheers,
Thomas

The pkgsrc team has prepared the 50th release of their package management system, with the 2016Q1 version. It's infrequent event, as the 100th release will be held after 50 quarters.

The NetBSD team has prepared series of interviews with the authors. The next one is with Benny Siegert, a developer active in the release engineering team.

Hi Benny, please introduce yourself.

I came to pkgsrc to my work on MirBSD. MirBSD only had a handful of developers, so there was not enough manpower to maintain our own ports tree -- not that we didn't try! In the end, we decided to support pkgsrc, and I joined the NetBSD project as a developer, in an amazingly quick and painless process.

My dayjob is as an SRE at Google; luckily, Google allows me to use my 20% time to work on pkgsrc. Working in this job has changed my perspective on computing. I try to apply some of the SRE principles (automate repetitive work, discipline in bug tracking, etc.) to my work in pkgsrc.

First of all, congratulations on the 50th release of pkgsrc! How do you feel about this anniversary?

Wow, 50 releases already! I find it remarkable how pkgsrc has continued on a stable growth trajectory all these years. And together, we have built one of the best and most advanced package collections.

What are the main benefits of the pkgsrc system?

pkgsrc runs on almost any platform that you are likely to use, from NetBSD, other BSDs, commercial Unixes, Linux and Mac OS. Whatever the platform, you have the same huge choice of up-to-date packages. You can install them with a single command. That's pretty compelling.

Where and how do you use pkgsrc?

These days, I mostly use pkgsrc on NetBSD and Mac OS X. On the Mac, pkgsrc may not be the most popular package collection but it still works amazingly well. (By the way, I applaud the team behind saveosx.org for making an effort to make pkgsrc more widely known among Mac users.)

What are the pkgsrc projects you are currently working on?

By accident, I ended up being the maintainer of the pkgsrc stable branch I am the one who handles most of the security updates to the stable release.

As a fan of the Go programming language (and a contributor to the project), I work on making software written in Go easy to use in pkgsrc. There is infrastructure (go-package.mk) for packaging Go software easily.

If you analyze the current state of pkgsrc, which improvements and changes do you wish for the future?

I would love to have more modern tooling. Gnats for bugs and CVS for the repository are both outdated. But this is an ongoing discussion.

I would also like to have a more rigorous handling of security fixes. The vulnerability DB is great and kept very well; on the other hand actually fixing the vulnerabilities is sometimes neglected, particularly for packages that not many people use.

Do you have any practical tips to share with the pkgsrc users?

- If you are on a machine where you do not have root access (such as a shared Linux machine), you can bootstrap pkgsrc in unprivileged mode. This way, everything builds and installs without needing to use root rights.

- Read up on "pkg_admin audit" and use it regularly, to find when you have packages with security problems installed.

What's the best way to start contributing to pkgsrc and what needs to be done?

pkgsrc-wip has a really low barrier to entry. Try to make your own package for something simple and put it in wip.

Look in pkgsrc/doc/TODO, it contains some suggestions for things you may want to work on. There is also a long list of suggested package updates in there, you can send a PR with patch for these.

Finally, if you run "pkg_admin audit", as I suggested above, and discover that pkgsrc does not contain a fix for a given vulnerability, you can try to find a patch and submit it via PR. I would be more than happy to apply it

Do you plan to participate in the upcoming pkgsrcCon 2016 in Kraków (1-3 July)?

pkgsrcCon is a fantastic conference. I am not 100% sure yet if I can make it but I will try to.

The pkgsrc team has prepared the 50th release of their package management system, with the 2016Q1 version. It's infrequent event, as the 100th release will be held after 50 quarters.

The NetBSD team has prepared series of interviews with the authors. The next one is with Benny Siegert, a developer active in the release engineering team.

Hi Benny, please introduce yourself.

I came to pkgsrc to my work on MirBSD. MirBSD only had a handful of developers, so there was not enough manpower to maintain our own ports tree -- not that we didn't try! In the end, we decided to support pkgsrc, and I joined the NetBSD project as a developer, in an amazingly quick and painless process.

My dayjob is as an SRE at Google; luckily, Google allows me to use my 20% time to work on pkgsrc. Working in this job has changed my perspective on computing. I try to apply some of the SRE principles (automate repetitive work, discipline in bug tracking, etc.) to my work in pkgsrc.

First of all, congratulations on the 50th release of pkgsrc! How do you feel about this anniversary?

Wow, 50 releases already! I find it remarkable how pkgsrc has continued on a stable growth trajectory all these years. And together, we have built one of the best and most advanced package collections.

What are the main benefits of the pkgsrc system?

pkgsrc runs on almost any platform that you are likely to use, from NetBSD, other BSDs, commercial Unixes, Linux and Mac OS. Whatever the platform, you have the same huge choice of up-to-date packages. You can install them with a single command. That's pretty compelling.

Where and how do you use pkgsrc?

These days, I mostly use pkgsrc on NetBSD and Mac OS X. On the Mac, pkgsrc may not be the most popular package collection but it still works amazingly well. (By the way, I applaud the team behind saveosx.org for making an effort to make pkgsrc more widely known among Mac users.)

What are the pkgsrc projects you are currently working on?

By accident, I ended up being the maintainer of the pkgsrc stable branch I am the one who handles most of the security updates to the stable release.

As a fan of the Go programming language (and a contributor to the project), I work on making software written in Go easy to use in pkgsrc. There is infrastructure (go-package.mk) for packaging Go software easily.

If you analyze the current state of pkgsrc, which improvements and changes do you wish for the future?

I would love to have more modern tooling. Gnats for bugs and CVS for the repository are both outdated. But this is an ongoing discussion.

I would also like to have a more rigorous handling of security fixes. The vulnerability DB is great and kept very well; on the other hand actually fixing the vulnerabilities is sometimes neglected, particularly for packages that not many people use.

Do you have any practical tips to share with the pkgsrc users?

- If you are on a machine where you do not have root access (such as a shared Linux machine), you can bootstrap pkgsrc in unprivileged mode. This way, everything builds and installs without needing to use root rights.

- Read up on "pkg_admin audit" and use it regularly, to find when you have packages with security problems installed.

What's the best way to start contributing to pkgsrc and what needs to be done?

pkgsrc-wip has a really low barrier to entry. Try to make your own package for something simple and put it in wip.

Look in pkgsrc/doc/TODO, it contains some suggestions for things you may want to work on. There is also a long list of suggested package updates in there, you can send a PR with patch for these.

Finally, if you run "pkg_admin audit", as I suggested above, and discover that pkgsrc does not contain a fix for a given vulnerability, you can try to find a patch and submit it via PR. I would be more than happy to apply it

Do you plan to participate in the upcoming pkgsrcCon 2016 in Kraków (1-3 July)?

pkgsrcCon is a fantastic conference. I am not 100% sure yet if I can make it but I will try to.

The pkgsrc team has prepared the 50th release of their package management system, with the 2016Q1 version. It's infrequent event, as the 100th release will be held after 50 quarters.

The NetBSD team has prepared series of interviews with the authors. The next one is with Jonathan Perkin, a developer in the Joyent team.

Hi Jonathan, please introduce yourself.

Hello! Thirty-something, married with 4 kids. Obviously this means life is usually pretty busy! I work as a Software Engineer for Joyent, where we provide SmartOS zones (also known as "containers" these days) running pkgsrc. This means I am in the privileged position of getting paid to work full-time on what for many years has been my hobby.

First of all, congratulations on the 50th release of pkgsrc! How do you feel about this anniversary?

I've been involved in pkgsrc since 2001, which was a few years before we started the quarterly releases. Back then and during the early 2000s there was a significant amount of work going into the pkgsrc infrastructure to give it all the amazing features that we have today, but that often meant the development branch had some rough edges while those features were still being integrated across the tree.

The quarterly releases gave users confidence in building from a stable release without unexpected breakages, and also helped developers to schedule any large changes at the appropriate time.

At Joyent we make heavy use of the quarterly releases, producing new SmartOS images for each branch, so for example our 16.1.x images are based on pkgsrc-2016Q1, and so on.

Reaching the 50th release makes me feel old! It also makes me feel proud that we've come a long way, yet still have people who want to be involved and continue to develop both the infrastructure and packages.

I'd also like to highlight the fantastic work of the pkgsrc releng team, who work to ensure the releases are kept up-to-date until the next one is released. They do a great job and we benefit a lot from their work.

What are the main benefits of the pkgsrc system?

For me the big one is portability. This is what sets it apart from all other package managers (and, increasingly, software in general), not just because it runs on so many platforms but because it is such a core part of the infrastructure and has been constantly developed and refined over the years. We are now up to 23 distinct platforms, not counting different distributions, and adding support for new ones is relatively easy thanks to the huge amount of work which has gone into the infrastructure.

The other main benefit for me is the buildlink infrastructure and various quality checks we have. As someone who distributes binary packages to end users, it is imperative that those packages work as expected on the target environment and don't have any embarrassing bugs. The buildlink system ensures (amongst other things) that dependencies are correct and avoids many issues around build host pollution. We then have a number of QA scripts which analyse the generated package and ensure that the contents are accurate, RPATHs are correct, etc. It's not perfect and there are more tests we could write, but these catch a lot of mistakes that would otherwise go undetected until a user submits a bug report.

Others for me are unprivileged support, signed packages, multi-version support, pbulk, and probably a lot of other things I've forgotten and take for granted!

Where and how do you use pkgsrc?

As mentioned above I work on pkgsrc for SmartOS. We are probably one of the biggest users of pkgsrc in the world, shipping over a million package downloads per year and rising to our users, not including those distributed as part of our images or delivered from mirrors. This is where I spend the majority of my time working on pkgsrc, and it is all performed remotely on a number of zones running in the Joyent Public Cloud. The packages we build are designed to run not just on SmartOS but across all illumos distributions, and so I also have an OmniOS virtual machine locally where I test new releases before announcing them.

As an OS X user, I also use pkgsrc on my MacBook. This is generally where I perform any final tests before committing changes to pkgsrc so that I'm reasonably confident they are correct, but I also install a bunch of different packages from pkgsrc (mutt, ffmpeg, nodejs, jekyll, pstree etc) for my day-to-day work. I also have a number of Mac build servers in my loft and at the Joyent offices in San Francisco where I produce the binary OS X packages we offer which are starting to become popular among users looking for an alternative to Homebrew or MacPorts.

Finally, I have a few Linux machines also running in the Joyent Public Cloud which I have configured for continuous bulk builds of pkgsrc trunk. These help me to test any infrastructure changes I'm working on to ensure that they are portable and correct.

On all of these machines I have written infrastructure to perform builds inside chroots, ensuring a consistent environment and allowing me to work on multiple things simultaneously. They all have various tools installed (git, pkgvi, pkglint, etc) to aid my personal development workflow. We then make heavy use of GitHub and Jenkins to manage automatic builds when pushing to various branches.

What are the pkgsrc projects you are currently working on?

One of my priorities over the past year has been on performance. We build a lot of packages (over 40,000 per branch, and we support up to 4 branches simultaneously), and when the latest OpenSSL vulnerability hits it's critical to get a fix out to users as quickly as possible. We're now at the stage where, with a couple of patches, we can complete a full bulk build in under 3 hours. There is still a lot of room for improvement though, so recently I've been looking at slibtool (a libtool replacement written in C) and supporting dash (a minimal POSIX shell which is faster than bash).

There are also a few features we've developed at Joyent that I continue to maintain, such as our multiarch work (which combines 32-bit and 64-bit builds into a single package), additional multi-version support for MySQL and Percona, SMF support, and a bunch of other patches which aren't yet ready to be integrated.

I'm also very keen on getting new users into pkgsrc and turning them into developers, so a lot of my time has been spent on making pkgsrc more accessible, whether that's via our pkgbuild image (which gives users a ready-made pkgsrc development environment) or the developer guides I've written, or maintaining our https://pkgsrc.joyent.com/ website. There's lots more to do in this area though to ensure users of all abilities can contribute meaningfully.

Most of my day-to-day work though is general bug fixing and updating packages, performing the quarterly release builds, and maintaining our build infrastructure.

If you analyze the current state of pkgsrc, which improvements and changes do you wish for the future?

More users and developers! I am one of only a small handful of people who are paid to work on pkgsrc, the vast majority of the work is done by our amazing volunteer community. By its very nature pkgsrc requires constant effort updating existing packages and adding new ones. This is something that will never change and if anything the demand is accelerating, so we need to ensure that we continue to train up and add new developers if we are to keep up.

We need more documentation, more HOWTO guides, simpler infrastructure, easier patch submission, faster and less onerous on-boarding of developers, more bulk builds, more development machines. Plenty to be getting on with!

Some technical changes I'd like to see are better upgrade support, launchd support, integration of a working alternative pkg backend e.g. IPS, bmake IPC (so we don't need to recompute the same variables over and over), and many more!

Do you have any practical tips to share with the pkgsrc users?

Separate your build and install environments, so e.g. build in chroots or in a VM then deploy the built packages to your target. Trying to update a live install is the source of many problems, and there are few things more frustrating than having your development environment be messed up by an upgrade which fails part-way through.

For brand new users, document your experience and tell us what works and what sucks. Many of us have been using pkgsrc for many many years, and have lost your unique ability to identify problems, inconsistencies, and bad documentation.

If you run into problems, connect to Freenode IRC #pkgsrc, and we'll try to help you out. Hang out there even if you aren't having problems!

Finally, if you like pkgsrc, tell your friends, write blog posts, post to Hacker News etc. It's amazing to me how unknown pkgsrc is despite being around for so long, and how many people love it when they discover it.

More users leads to more developers, which leads to improved pkgsrc, which leads to more users, which...

What's the best way to start contributing to pkgsrc and what needs to be done?

Pick something that interests you and just start working on it. The great thing about pkgsrc is that there are open tasks for any ability, from documentation fixes all the way through adding packages to rewriting large parts of the infrastructure.

When you have something to contribute, don't worry about whether it's perfect or how you are to deliver it. Just make it available and let us know via PR, pull request, or just mail, and we can take it from there.

Do you plan to participate in the upcoming pkgsrcCon 2016 in Kraków (1-3 July)?

I am hoping to. If so I usually give a talk on what we've been working on at Joyent over the past year, and will probably do the same.

The pkgsrc team has prepared the 50th release of their package management system, with the 2016Q1 version. It's infrequent event, as the 100th release will be held after 50 quarters.

The NetBSD team has prepared series of interviews with the authors. The next one is with Jonathan Perkin, a developer in the Joyent team.

Hi Jonathan, please introduce yourself.

Hello! Thirty-something, married with 4 kids. Obviously this means life is usually pretty busy! I work as a Software Engineer for Joyent, where we provide SmartOS zones (also known as "containers" these days) running pkgsrc. This means I am in the privileged position of getting paid to work full-time on what for many years has been my hobby.

First of all, congratulations on the 50th release of pkgsrc! How do you feel about this anniversary?

I've been involved in pkgsrc since 2001, which was a few years before we started the quarterly releases. Back then and during the early 2000s there was a significant amount of work going into the pkgsrc infrastructure to give it all the amazing features that we have today, but that often meant the development branch had some rough edges while those features were still being integrated across the tree.

The quarterly releases gave users confidence in building from a stable release without unexpected breakages, and also helped developers to schedule any large changes at the appropriate time.

At Joyent we make heavy use of the quarterly releases, producing new SmartOS images for each branch, so for example our 16.1.x images are based on pkgsrc-2016Q1, and so on.

Reaching the 50th release makes me feel old! It also makes me feel proud that we've come a long way, yet still have people who want to be involved and continue to develop both the infrastructure and packages.

I'd also like to highlight the fantastic work of the pkgsrc releng team, who work to ensure the releases are kept up-to-date until the next one is released. They do a great job and we benefit a lot from their work.

What are the main benefits of the pkgsrc system?

For me the big one is portability. This is what sets it apart from all other package managers (and, increasingly, software in general), not just because it runs on so many platforms but because it is such a core part of the infrastructure and has been constantly developed and refined over the years. We are now up to 23 distinct platforms, not counting different distributions, and adding support for new ones is relatively easy thanks to the huge amount of work which has gone into the infrastructure.

The other main benefit for me is the buildlink infrastructure and various quality checks we have. As someone who distributes binary packages to end users, it is imperative that those packages work as expected on the target environment and don't have any embarrassing bugs. The buildlink system ensures (amongst other things) that dependencies are correct and avoids many issues around build host pollution. We then have a number of QA scripts which analyse the generated package and ensure that the contents are accurate, RPATHs are correct, etc. It's not perfect and there are more tests we could write, but these catch a lot of mistakes that would otherwise go undetected until a user submits a bug report.

Others for me are unprivileged support, signed packages, multi-version support, pbulk, and probably a lot of other things I've forgotten and take for granted!

Where and how do you use pkgsrc?

As mentioned above I work on pkgsrc for SmartOS. We are probably one of the biggest users of pkgsrc in the world, shipping over a million package downloads per year and rising to our users, not including those distributed as part of our images or delivered from mirrors. This is where I spend the majority of my time working on pkgsrc, and it is all performed remotely on a number of zones running in the Joyent Public Cloud. The packages we build are designed to run not just on SmartOS but across all illumos distributions, and so I also have an OmniOS virtual machine locally where I test new releases before announcing them.

As an OS X user, I also use pkgsrc on my MacBook. This is generally where I perform any final tests before committing changes to pkgsrc so that I'm reasonably confident they are correct, but I also install a bunch of different packages from pkgsrc (mutt, ffmpeg, nodejs, jekyll, pstree etc) for my day-to-day work. I also have a number of Mac build servers in my loft and at the Joyent offices in San Francisco where I produce the binary OS X packages we offer which are starting to become popular among users looking for an alternative to Homebrew or MacPorts.

Finally, I have a few Linux machines also running in the Joyent Public Cloud which I have configured for continuous bulk builds of pkgsrc trunk. These help me to test any infrastructure changes I'm working on to ensure that they are portable and correct.

On all of these machines I have written infrastructure to perform builds inside chroots, ensuring a consistent environment and allowing me to work on multiple things simultaneously. They all have various tools installed (git, pkgvi, pkglint, etc) to aid my personal development workflow. We then make heavy use of GitHub and Jenkins to manage automatic builds when pushing to various branches.

What are the pkgsrc projects you are currently working on?

One of my priorities over the past year has been on performance. We build a lot of packages (over 40,000 per branch, and we support up to 4 branches simultaneously), and when the latest OpenSSL vulnerability hits it's critical to get a fix out to users as quickly as possible. We're now at the stage where, with a couple of patches, we can complete a full bulk build in under 3 hours. There is still a lot of room for improvement though, so recently I've been looking at slibtool (a libtool replacement written in C) and supporting dash (a minimal POSIX shell which is faster than bash).

There are also a few features we've developed at Joyent that I continue to maintain, such as our multiarch work (which combines 32-bit and 64-bit builds into a single package), additional multi-version support for MySQL and Percona, SMF support, and a bunch of other patches which aren't yet ready to be integrated.

I'm also very keen on getting new users into pkgsrc and turning them into developers, so a lot of my time has been spent on making pkgsrc more accessible, whether that's via our pkgbuild image (which gives users a ready-made pkgsrc development environment) or the developer guides I've written, or maintaining our https://pkgsrc.joyent.com/ website. There's lots more to do in this area though to ensure users of all abilities can contribute meaningfully.

Most of my day-to-day work though is general bug fixing and updating packages, performing the quarterly release builds, and maintaining our build infrastructure.

If you analyze the current state of pkgsrc, which improvements and changes do you wish for the future?

More users and developers! I am one of only a small handful of people who are paid to work on pkgsrc, the vast majority of the work is done by our amazing volunteer community. By its very nature pkgsrc requires constant effort updating existing packages and adding new ones. This is something that will never change and if anything the demand is accelerating, so we need to ensure that we continue to train up and add new developers if we are to keep up.

We need more documentation, more HOWTO guides, simpler infrastructure, easier patch submission, faster and less onerous on-boarding of developers, more bulk builds, more development machines. Plenty to be getting on with!

Some technical changes I'd like to see are better upgrade support, launchd support, integration of a working alternative pkg backend e.g. IPS, bmake IPC (so we don't need to recompute the same variables over and over), and many more!

Do you have any practical tips to share with the pkgsrc users?

Separate your build and install environments, so e.g. build in chroots or in a VM then deploy the built packages to your target. Trying to update a live install is the source of many problems, and there are few things more frustrating than having your development environment be messed up by an upgrade which fails part-way through.

For brand new users, document your experience and tell us what works and what sucks. Many of us have been using pkgsrc for many many years, and have lost your unique ability to identify problems, inconsistencies, and bad documentation.

If you run into problems, connect to Freenode IRC #pkgsrc, and we'll try to help you out. Hang out there even if you aren't having problems!

Finally, if you like pkgsrc, tell your friends, write blog posts, post to Hacker News etc. It's amazing to me how unknown pkgsrc is despite being around for so long, and how many people love it when they discover it.

More users leads to more developers, which leads to improved pkgsrc, which leads to more users, which...

What's the best way to start contributing to pkgsrc and what needs to be done?

Pick something that interests you and just start working on it. The great thing about pkgsrc is that there are open tasks for any ability, from documentation fixes all the way through adding packages to rewriting large parts of the infrastructure.

When you have something to contribute, don't worry about whether it's perfect or how you are to deliver it. Just make it available and let us know via PR, pull request, or just mail, and we can take it from there.

Do you plan to participate in the upcoming pkgsrcCon 2016 in Kraków (1-3 July)?

I am hoping to. If so I usually give a talk on what we've been working on at Joyent over the past year, and will probably do the same.

The pkgsrc team has prepared the 50th release of their package management system, with the 2016Q1 version. It's infrequent event, as the 100th release will be held after 50 quarters.

The NetBSD team has prepared series of interviews with the authors. The next one is with Ryo ONODERA, a Japanese developer maintaining large C++ packages.

Hi Ryo, please introduce yourself.

Hi,
I am hobbyist.
I maintain some large C++ packages, however my knowledge about recent C++ is poor.
My current home work is to learn modern C++.

First of all, congratulations on the 50th release of pkgsrc! How do you feel about this anniversary?

I am very glad to commit some changes for this remarkable 50th release.
I feel 50 releases is very long history.
The pkgsrc should be improved for next 100th anniversary.

What are the main benefits of the pkgsrc system?

The pkgsrc helps building from source.
Building from source is interesting and I have learned many things from it. It is worth for experiencing.

I like up-to-date software.
And I believe many people like latest software.
Recently security concerns us.
Sharing the recipe for latest software is getting worth, I believe.

Where and how do you use pkgsrc?

My laptop and home NAS run NetBSD/amd64.
And of course I uses pkgsrc.
And some day-job FreeBSD/amd64 servers also use pkgsrc.

What are the pkgsrc projects you are currently working on?

I am user of Mozilla Firefox (pkgsrc/www/firefox) and LibreOffice (pkgsrc/misc/libreoffice).
I need latest ones. And I will keep them up-to-date.

If you analyze the current state of pkgsrc, which improvements and changes do you wish for the future?

I feel Fortran support is not so powerful. This should be improved.
And Chromium browser should be ported to NetBSD.
If I setup great machine, I will try to do it.

Do you have any practical tips to share with the pkgsrc users?

Good /etc/mk.conf or /usr/pkg/etc/mk.conf improve your pkgsrc experience.
At least,
WRKOBJDIR=/usr/tmp/pkgsrc
and
MASTER_SITE_OVERRIDE=http://ftp.XX.netbsd.org/pub/pkgsrc/distfiles/
should improve your pkgsrc experience.

What's the best way to start contributing to pkgsrc and what needs to be done?

Updating simple package is good start point. For example, Font package or simple C software.
I recommend to get commit bit for pkgsrc-wip.
Committing your idea to the repository is invaluable experience.

Do you plan to participate in the upcoming pkgsrcCon 2016 in Kraków (1-3 July)?

Sadly, I cannot do long distance travel...
If video streaming is provided, I will watch it carefully!

Thank you.
Please use and contribute the pkgsrc!

The pkgsrc team has prepared the 50th release of their package management system, with the 2016Q1 version. It's infrequent event, as the 100th release will be held after 50 quarters.

The NetBSD team has prepared series of interviews with the authors. The next one is with Ryo ONODERA, a Japanese developer maintaining large C++ packages.

Hi Ryo, please introduce yourself.

Hi,
I am hobbyist.
I maintain some large C++ packages, however my knowledge about recent C++ is poor.
My current home work is to learn modern C++.

First of all, congratulations on the 50th release of pkgsrc! How do you feel about this anniversary?

I am very glad to commit some changes for this remarkable 50th release.
I feel 50 releases is very long history.
The pkgsrc should be improved for next 100th anniversary.

What are the main benefits of the pkgsrc system?

The pkgsrc helps building from source.
Building from source is interesting and I have learned many things from it. It is worth for experiencing.

I like up-to-date software.
And I believe many people like latest software.
Recently security concerns us.
Sharing the recipe for latest software is getting worth, I believe.

Where and how do you use pkgsrc?

My laptop and home NAS run NetBSD/amd64.
And of course I uses pkgsrc.
And some day-job FreeBSD/amd64 servers also use pkgsrc.

What are the pkgsrc projects you are currently working on?

I am user of Mozilla Firefox (pkgsrc/www/firefox) and LibreOffice (pkgsrc/misc/libreoffice).
I need latest ones. And I will keep them up-to-date.

If you analyze the current state of pkgsrc, which improvements and changes do you wish for the future?

I feel Fortran support is not so powerful. This should be improved.
And Chromium browser should be ported to NetBSD.
If I setup great machine, I will try to do it.

Do you have any practical tips to share with the pkgsrc users?

Good /etc/mk.conf or /usr/pkg/etc/mk.conf improve your pkgsrc experience.
At least,
WRKOBJDIR=/usr/tmp/pkgsrc
and
MASTER_SITE_OVERRIDE=http://ftp.XX.netbsd.org/pub/pkgsrc/distfiles/
should improve your pkgsrc experience.

What's the best way to start contributing to pkgsrc and what needs to be done?

Updating simple package is good start point. For example, Font package or simple C software.
I recommend to get commit bit for pkgsrc-wip.
Committing your idea to the repository is invaluable experience.

Do you plan to participate in the upcoming pkgsrcCon 2016 in Kraków (1-3 July)?

Sadly, I cannot do long distance travel...
If video streaming is provided, I will watch it carefully!

Thank you.
Please use and contribute the pkgsrc!

For the 10th time The NetBSD Foundation was selected for the GSoC 2016!

Now that we're near the first mid-term evaluation and have written the code during these weeks it's also the right time to start writing some reports regarding our projects in this series of blog posts.

About Split debug symbols for pkgsrc builds GSoC project

As part of Split debug symbols for pkgsrc builds GSoC project I'm working to provide support for pkgsrc packages for splitted packages that just contain debug symbols for their correspondent package (e.g. for the foo-0.1.2.tgz package there will be a corresponding foo-0.1.2-debugpkg.tgz package that just contains stripped debug symbols of all the former binaries and libraries installed by foo-0.1.2).

If you're more curious and you would like to know more information about it please take a look to the proposal.

Introduction

In this blog post we will learn how debug information are stored and stripped off from the programs and/or libraries. We will first write a simple program and a Makefile to analyze what MKDEBUG* flags in NetBSD do. Then we will take a look more in depth to how everything is implemented in the various src/share/*.mk files and at the end we will give a look to related works already implemented in RPM and dpkg.

A pretty long list of references is also provided for the most curiouses readers!

A quick introduction to ELF and how debug information are stored/stripped off

In order to become familiar with ELF format a good starting point are Object file and Executable and Linkable Format pages from Wikipedia, the free encyclopedia.

Trying to describe ELF format is not easy in short terms so, it is strongly suggested to read the nice article series written by Eric Youngdale for Linux Journal: The ELF Object File Format: Introduction and The ELF Object File Format by Dissection. Please note that these two resources should be enough to completely understand this blog post!

After reading the above resources we have just learned that every programs and libraries in NetBSD (and several other Unix-like operating systems) uses the ELF format. There are four types of ELF object files:

• executable
• relocatable
• shared
• core

For more information regarding them please give a look to elf(5).

We are interested to understand what happens when we compile the programs/libraries with debugging options (basically the -g option).

NetBSD already supports everything out of the box and so we can quickly start looking at it just writing a simple Makefile and a program that will print the lyrics of the famous Ten Green Bottles song! To avoid all the hassle of providing (multiple times!) the right flags to the compiler and manually invoke the right tool we can just write a very simple Makefile that will do everything for us:

$ cat green-bottles/Makefile
#   $NetBSD$

NOMAN=  # defined

PROG=   green-bottles

.include <bsd.prog.mk>

Now that we have the Makefile we can start writing the green-bottles PROGram (please note that all the green bottles accidentally fall were properly recycled during the writing of this article):

$ cat green-bottles/green-bottles.c 
#include <stdio.h>

void
sing_green_bottles(int n)
{
    const char *numbers[] = { "no more", "one", "two", "three", "four", "five",
        "six", "seven", "eight", "nine", "ten" };

    if ((1 <= n) && (n <= 10)) {
        printf("%s green bottle%s hanging on the wall\n",
            numbers[n], n > 1 ? "s" : "");
        printf("%s green bottle%s hanging on the wall\n",
            numbers[n], n > 1 ? "s" : "");
        printf("and if %s green bottle should accidentally fall,\n",
            n > 2 ? "one" : "that");
        printf("there'll be %s green bottles hanging on the wall.\n",
            numbers[n - 1]);
    }

    return;
}


/*
 * Sing the famous `Ten Green Bottles' song.
 */
int
main(void)
{
    int i;

    for (i = 10; i > 0; i--) {
        sing_green_bottles(i);
    }

    return 0;
}

OK! Now everything is ready and if we just invoke make(1) we'll build the program. However, we would like to inspect what's happening behind the scenes, so we'll look at each steps. Please note that right now it is not important that you'll understand everything because we'll look at what make(1) magic do in more details later.

First, we compile the C program to generate the relocatable object file, i.e. green-bottles.o:

$ cd green-bottles/
$ make green-bottles.o
#   compile  green-bottles/green-bottles.o
gcc -O2 -fPIE    -std=gnu99   -Werror     -c    green-bottles.c
ctfconvert -g -L VERSION green-bottles.o

Let's see what file(1) says regarding it:

$ file green-bottles.o
green-bottles.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

In order to get more information we can use readelf(1) tool provided by the binutils (GNU binary utilities), e.g. via readelf -h (the -h option is used to just print the file headers, if you would like to get more information you can use the -a option instead):

$ readelf -h green-bottles.o
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          2816 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           64 (bytes)
  Number of section headers:         17
  Section header string table index: 13

We can see the 17 sections always via readelf (-S option). Now let's recompile it but via the debugging options turned on:

$ make green-bottles.o MKDEBUG=yes
#   compile  green-bottles/green-bottles.o
gcc -O2 -fPIE  -g   -std=gnu99   -Werror     -c    green-bottles.c
ctfconvert -g -L VERSION -g green-bottles.o

If we are careful we can see that unlike the previous make incantation now the -g option is passed to the compiler... Let's see if we can inspect that via readelf:

$ readelf -h green-bottles.o
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          6424 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           64 (bytes)
  Number of section headers:         29
  Section header string table index: 25

We can note several differences compared to the previous relocatable file compiled without MKDEBUG:

• Start of section headers (previously 2816, now 6424)
• Number of section headers (previously 17, now 29)
• Section header string table index (previously 13, now 25)

If we compare the sections between the two relocatable files (tips: using: readelf -WS green-bottles.o | sed -nEe 's/^ \[ *([0-9]+)\] ([^ ]*) .*/\2/p' is a possible way to do it) we can observe the following new ELF sections:

• .debug_info: contains main DWARF DIEs (Debugging Information Entry)
• .debug_abbrev: contains abbreviations used in .debug_info section
• .debug_loc: contains location expressions
• .debug_aranges: contains a table for lookup by addresses of program entities (i.e. data objects, types, functions)
• .debug_ranges: contains address ranges referenced by DIEs
• .debug_line: contains line number program
• .debug_str: contains all strings referenced by .debug_info
• other .rela.debug_*

It's time to finally build the program:

$ make green-bottles
rm -f .gdbinit
touch .gdbinit
#      link  green-bottles/green-bottles
gcc     -pie  -shared-libgcc      -o green-bottles  green-bottles.o  -Wl,-rpath-link,/lib  -L=/lib
ctfmerge -t -g -L VERSION -o green-bottles green-bottles.o

We can observe:

$ readelf -h green-bottles
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x730
  Start of program headers:          64 (bytes into file)
  Start of section headers:          6448 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         7
  Size of section headers:           64 (bytes)
  Number of section headers:         31
  Section header string table index: 27

...and for its counterpart compiled via MKDEBUG=yes:

$ readelf -h green-bottles
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x730
  Start of program headers:          64 (bytes into file)
  Start of section headers:          8304 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         7
  Size of section headers:           64 (bytes)
  Number of section headers:         38
  Section header string table index: 34

Not so surprisingly the number of the 7 extra sections are exactly the .debug_* ones!

Now that it's clear the difference between the program compiled with/without -g option let's see what happen when the debug symbols are stripped off the program:

$ make green-bottles.debug MKDEBUG=yes
#    create  green-bottles/green-bottles.debug
(  objcopy --only-keep-debug green-bottles green-bottles.debug  && objcopy --strip-debug -p -R .gnu_debuglink  --add-gnu-debuglink=green-bottles.debug green-bottles  ) || (rm -f green-bottles.debug; false)

We can try to describe what happened with an image:

The first objcopy(1) incantation generate the green-bottles.debug file. The second objcopy(1) incantation strip the debug symbols off green-bottles (now that they're stored in green-bottles.debug they are no more needed) and add the .gnu_debuglink ELF section to it.

Let's quickly look them via file(1):

$ file green-bottles green-bottles.debug
green-bottles:       ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/libexec/ld.elf_so, for NetBSD 7.99.29, not stripped
green-bottles.debug: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter *empty*, for NetBSD 7.99.29, not stripped

Using readelf we can note that now green-bottles has 32 sections and green-bottles.debug has 38 sections. green-bottles has one extra section that was added by the objcopy(1) incantation, let's see it:

$ readelf -x '.gnu_debuglink' green-bottles

Hex dump of section '.gnu_debuglink':
  0x00000000 67726565 6e2d626f 74746c65 732e6465 green-bottles.de
  0x00000010 62756700 90b06f1c                   bug...o.

The .gnu_debuglink section contain the basename(3) of the .debug file and its CRC32. The .gnu_debuglink section is used to properly pick the correct .debug file from the DEBUGDIR directory (we'll see how it will work later when we will invoke the GNU debugger).

Regarding the sections in the .debug file all of them are preserved but several have no data, we can check that by invoking:

$ readelf `seq -f '-x %g' 0 37` green-bottles.debug
$ readelf `seq -f '-x %g' 0 31` green-bottles

...and comparing their respective output.

Now that everything should be clearer we can just try to invoke it through gdb(1) and see what happens:

$ gdb ./green-bottles
GNU gdb (GDB) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64--netbsd".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./green-bottles...Reading symbols from /tmp/green-bottles/green-bottles.debug...done.
done.
(gdb) b main
Breakpoint 1 at 0xac0: file green-bottles.c, line 29.
(gdb) b sing_green_bottles
Breakpoint 2 at 0x940: file green-bottles.c, line 5.
(gdb) run
Starting program: /tmp/green-bottles/green-bottles

Breakpoint 1, main () at green-bottles.c:29
29      {
(gdb) n
32              for (i = 10; i > 0; i--) {
(gdb) n
33                      sing_green_bottles(i);
(gdb) print i
$1 = 10
(gdb) cont
Continuing.

Breakpoint 2, sing_green_bottles (n=10) at green-bottles.c:5
5       {
(gdb) bt
#0  sing_green_bottles (n=10) at green-bottles.c:5
#1  0x00000000b7802ad7 in main () at green-bottles.c:33
[... we can now looks and debug it as we wish! ...]

So we can see that the green-bottles.debug file is loaded from the same directory where green-bottles program was present (in our case /tmp/green-bottles/ but if a corresponding file .debug is not found gdb look for it in the DEBUGDIR, i.e. /usr/libdata/debug/; e.g. for /usr/bin/yes it will look for debug symbols in /usr/libdata/debug//usr/bin/yes.debug). This is the same for all other programs and libraries.

A look to what MKDEBUG and MKDEBUGLIB do

NetBSD already provides MKDEBUG and MKDEBUGLIB mk.conf(5) variables to achieve the separation of the debug symbols. They respectively split symbols from programs and libraries.

The implementation to do that is in src/share/mk/bsd.prog.mk (for programs) and src/share/mk/bsd.lib.mk (for libraries). Several global variables used are defined in src/share/mk/bsd.own.mk.

bsd.prog.mk

In bsd.prog.mk:58 if MKDEBUG is defined and not "no" [sic] the -g flag is added to CFLAGS.

In bsd.prog.mk:310 the internal __progdebuginstall make target is defined to install the .debug file for the respective program. It is then called from bsd.prog.mk:589 and bsd.prog.mk:604 (respectively for MKUPDATE == "no" and MKUPDATE != "no", please note the dependency operators ! vs : for the two cases).

In bsd.prog.mk:437 _PROGDEBUG.${_P} is defined as ${PROGNAME.${_P}}.debug, inside a for loop. ${_P} is just an element of the ${PROGS} and ${PROGS_CXX} lists. E.g.: for src/bin/echo echo is the PROG value. bsd.prog.mk turns single-program PROG and PROG_CXX variable into the multi-word PROGS and PROGS_CXX variables.

In bsd.prog.mk:545 there is the most important part. After checking if _PROGDEBUG.${_P} is defined a ${_PROGDEBUG.${_P}} target is defined and ${OBJCOPY} is invoked two times. In the first incantation the ${_PROGDEBUG.${_P}} file (containing the strip debug symbols) is generated for ${_P}. The second incantation is needed to get rid of (now no more needed) debug symbols from ${_P} and --add-gnu-debuglink add a .gnu_debuglink section to ${_P} containing the filename of the ${_PROGDEBUG.${_P}}; e.g. for echo it will be echo.debug (plus the CRC32 of echo.debug - padded as needed). Regarding other options used by ${OBJCOPY} we should note the -p option needed to preserve dates and -R is added in order to be sure to update the .gnu_debuglink section.

For a gentler introduction and to understand why these steps are needed please read (gdb.info)Separate Debug Files (you can just use info(1), i.e. info '(gdb.info)Separate Debug Files').

bsd.lib.mk

The logic and objcopy(1) incantation are similar to the ones used in bsd.prog.mk. The most interesting part is in bsd.lib.mk:622. Apart the *.debug files if MKDEBUGLIB is defined and not "no" [sic] also *_g.a archives are created for the respective libraries archives (although they are stored directly in the several lib/ directories not in /usr/libdata/debug/).

bsd.own.mk

In bsd.own.mk various DEBUG* variables are defined:

• DEBUGDIR: where *.debug files are stored. Please notice that this is also the place where debugging symbols are looked (for more information please give a look to objcopy(1))
• DEBUGGRP: the -g option passed to install(1) for installing debug symbols
• DEBUGOWN: the -o option passed to install(1) for installing debug symbols
• DEBUGMODE: the -m option passed to install(1) for installing debug symbols

Related works

dpkg

The Debian Developer's Reference written by the Developer's Reference Team has a Best practices for debug packages (section 6.7.9). The logic used is more or less the same of the one used by src/share/mk in NetBSD and described above.

After a quick inspection of dh_strip (part of debhelper package) some interesting ideas to look further are:

• the file(1) logic used in testfile() subroutine
• handling of non-C/C++ programming languages: OCaml native code shared libraries (*.cmxs) and nodejs binaries (*.node)

RPM

The Fedora Project Wiki contains some interesting tips, in particular regarding most common issues that happens in stripping debugging symbols in the Packaging:Debuginfo page. Some of the logic is handled in find-debuginfo.sh.

Another interesting resource is the Releases/FeatureBuildId page. The page discusses what Red Hat have done regarding using the .note.gnu.build-id section and why have done them.

(Yet another) interesting idea adopted by Fedora developers is the Features/MiniDebugInfo. More information regarding MiniDebugInfo are also present in (gdb.info)MiniDebugInfo. Please note that this is not completely related to stripping debugging symbols (indeed the MiniDebugInfo is directly stored in program/library!) but can be considered in order to provide better .core (both in the pkgsrc and NetBSD cases).

Mark J. Wielaard presented in FOSDEM 2016 a talk that summarizes many of the thematics discussed in this diary. Abstract, video recording and more resources are available in the FOSDEM website correspective event page: Where are your symbols, debuginfo and sources?. Apart his talk a very interesting reading is his blog post regarding the talk. In the blog post there are a lot of interesting information, all worth to be taken in consideration also for the pkgsrc case.

Conclusion

In this blog post we have learned what's happening when we use MKDEBUG* mk.conf(5) variables and how everything works.

We have also gave a quick look to other related works, in particular RPM and dpkg package managers.

If you are curious on what I'm doing right now and you would like to also look at the code you can give a look to the git pkgsrc repository repository fork in the debugpkg branch.

Apart the several references discussed above if you would like to learn more about several aspects that wasn't discussed there... Introduction to the DWARF Debugging Format written by Michael Eager is a good starting point for DWARF (debugging data format); you can also use objdump -g to show these information in the *.debug files. Regarding GDB a gentle introduction to it is Using GNU's GDB Debugger by Peter Jay Salzman.

I would like to thanks Google for organizing Google Summer of Code and The NetBSD Foundation, without them I would not be able to work on this project!

A particular and big thank you goes to my mentors David Maxwell, Jöerg Sonnenberger, Taylor R. Campbell, Thomas Klausner and William J. Coldwell for the invaluable help, guidance and feedbacks they're providing!

References

• The ELF Object File Format: Introduction, Eric Youngdale
• The ELF Object File Format by Dissection, Eric Youngdale
• Tool Interface Standard (TIS) Executable and Linking Format (ELF) Specification Version 1.2, TIS Committee
• DWARF Debugging Information Format Version 4, DWARF Debugging Information Format Committee
• Introduction to the DWARF Debugging Format, Michael Eager
• Debugging with GDB Tenth Edition for GDB Version 7.10.1, Free Software Foundation, Inc.
• Using GNU's GDB Debugger, Peter Jay Salzman
• Debian Developer's Reference, Developer's Reference Team
• Where are your Symbols, Debuginfo and Sources?, Mark J. Wielaard
• make(1)
• elf(5)
• file(1)
• gcc(1)
• readelf(1)
• objdump(1)
• objcompy(1)
• gdb(1)
• src/share/bsd.README, 1.353
• src/share/bsd.prog.mk, 1.299
• src/share/bsd.lib.mk, 1.367
• src/share/bsd.own.mk, 1.927

For the 10th time The NetBSD Foundation was selected for the GSoC 2016!

Now that we're near the first mid-term evaluation and have written the code during these weeks it's also the right time to start writing some reports regarding our projects in this series of blog posts.

About Split debug symbols for pkgsrc builds GSoC project

As part of Split debug symbols for pkgsrc builds GSoC project I'm working to provide support for pkgsrc packages for splitted packages that just contain debug symbols for their correspondent package (e.g. for the foo-0.1.2.tgz package there will be a corresponding foo-0.1.2-debugpkg.tgz package that just contains stripped debug symbols of all the former binaries and libraries installed by foo-0.1.2).

If you're more curious and you would like to know more information about it please take a look to the proposal.

Introduction

In this blog post we will learn how debug information are stored and stripped off from the programs and/or libraries. We will first write a simple program and a Makefile to analyze what MKDEBUG* flags in NetBSD do. Then we will take a look more in depth to how everything is implemented in the various src/share/*.mk files and at the end we will give a look to related works already implemented in RPM and dpkg.

A pretty long list of references is also provided for the most curiouses readers!

A quick introduction to ELF and how debug information are stored/stripped off

In order to become familiar with ELF format a good starting point are Object file and Executable and Linkable Format pages from Wikipedia, the free encyclopedia.

Trying to describe ELF format is not easy in short terms so, it is strongly suggested to read the nice article series written by Eric Youngdale for Linux Journal: The ELF Object File Format: Introduction and The ELF Object File Format by Dissection. Please note that these two resources should be enough to completely understand this blog post!

After reading the above resources we have just learned that every programs and libraries in NetBSD (and several other Unix-like operating systems) uses the ELF format. There are four types of ELF object files:

• executable
• relocatable
• shared
• core

For more information regarding them please give a look to elf(5).

We are interested to understand what happens when we compile the programs/libraries with debugging options (basically the -g option).

NetBSD already supports everything out of the box and so we can quickly start looking at it just writing a simple Makefile and a program that will print the lyrics of the famous Ten Green Bottles song! To avoid all the hassle of providing (multiple times!) the right flags to the compiler and manually invoke the right tool we can just write a very simple Makefile that will do everything for us:

$ cat green-bottles/Makefile
#   $NetBSD$

NOMAN=  # defined

PROG=   green-bottles

.include <bsd.prog.mk>

Now that we have the Makefile we can start writing the green-bottles PROGram (please note that all the green bottles accidentally fall were properly recycled during the writing of this article):

$ cat green-bottles/green-bottles.c 
#include <stdio.h>

void
sing_green_bottles(int n)
{
    const char *numbers[] = { "no more", "one", "two", "three", "four", "five",
        "six", "seven", "eight", "nine", "ten" };

    if ((1 <= n) && (n <= 10)) {
        printf("%s green bottle%s hanging on the wall\n",
            numbers[n], n > 1 ? "s" : "");
        printf("%s green bottle%s hanging on the wall\n",
            numbers[n], n > 1 ? "s" : "");
        printf("and if %s green bottle should accidentally fall,\n",
            n > 2 ? "one" : "that");
        printf("there'll be %s green bottles hanging on the wall.\n",
            numbers[n - 1]);
    }

    return;
}


/*
 * Sing the famous `Ten Green Bottles' song.
 */
int
main(void)
{
    int i;

    for (i = 10; i > 0; i--) {
        sing_green_bottles(i);
    }

    return 0;
}

OK! Now everything is ready and if we just invoke make(1) we'll build the program. However, we would like to inspect what's happening behind the scenes, so we'll look at each steps. Please note that right now it is not important that you'll understand everything because we'll look at what make(1) magic do in more details later.

First, we compile the C program to generate the relocatable object file, i.e. green-bottles.o:

$ cd green-bottles/
$ make green-bottles.o
#   compile  green-bottles/green-bottles.o
gcc -O2 -fPIE    -std=gnu99   -Werror     -c    green-bottles.c
ctfconvert -g -L VERSION green-bottles.o

Let's see what file(1) says regarding it:

$ file green-bottles.o
green-bottles.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

In order to get more information we can use readelf(1) tool provided by the binutils (GNU binary utilities), e.g. via readelf -h (the -h option is used to just print the file headers, if you would like to get more information you can use the -a option instead):

$ readelf -h green-bottles.o
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          2816 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           64 (bytes)
  Number of section headers:         17
  Section header string table index: 13

We can see the 17 sections always via readelf (-S option). Now let's recompile it but via the debugging options turned on:

$ make green-bottles.o MKDEBUG=yes
#   compile  green-bottles/green-bottles.o
gcc -O2 -fPIE  -g   -std=gnu99   -Werror     -c    green-bottles.c
ctfconvert -g -L VERSION -g green-bottles.o

If we are careful we can see that unlike the previous make incantation now the -g option is passed to the compiler... Let's see if we can inspect that via readelf:

$ readelf -h green-bottles.o
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          6424 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           64 (bytes)
  Number of section headers:         29
  Section header string table index: 25

We can note several differences compared to the previous relocatable file compiled without MKDEBUG:

• Start of section headers (previously 2816, now 6424)
• Number of section headers (previously 17, now 29)
• Section header string table index (previously 13, now 25)

If we compare the sections between the two relocatable files (tips: using: readelf -WS green-bottles.o | sed -nEe 's/^ \[ *([0-9]+)\] ([^ ]*) .*/\2/p' is a possible way to do it) we can observe the following new ELF sections:

• .debug_info: contains main DWARF DIEs (Debugging Information Entry)
• .debug_abbrev: contains abbreviations used in .debug_info section
• .debug_loc: contains location expressions
• .debug_aranges: contains a table for lookup by addresses of program entities (i.e. data objects, types, functions)
• .debug_ranges: contains address ranges referenced by DIEs
• .debug_line: contains line number program
• .debug_str: contains all strings referenced by .debug_info
• other .rela.debug_*

It's time to finally build the program:

$ make green-bottles
rm -f .gdbinit
touch .gdbinit
#      link  green-bottles/green-bottles
gcc     -pie  -shared-libgcc      -o green-bottles  green-bottles.o  -Wl,-rpath-link,/lib  -L=/lib
ctfmerge -t -g -L VERSION -o green-bottles green-bottles.o

We can observe:

$ readelf -h green-bottles
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x730
  Start of program headers:          64 (bytes into file)
  Start of section headers:          6448 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         7
  Size of section headers:           64 (bytes)
  Number of section headers:         31
  Section header string table index: 27

...and for its counterpart compiled via MKDEBUG=yes:

$ readelf -h green-bottles
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x730
  Start of program headers:          64 (bytes into file)
  Start of section headers:          8304 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         7
  Size of section headers:           64 (bytes)
  Number of section headers:         38
  Section header string table index: 34

Not so surprisingly the number of the 7 extra sections are exactly the .debug_* ones!

Now that it's clear the difference between the program compiled with/without -g option let's see what happen when the debug symbols are stripped off the program:

$ make green-bottles.debug MKDEBUG=yes
#    create  green-bottles/green-bottles.debug
(  objcopy --only-keep-debug green-bottles green-bottles.debug  && objcopy --strip-debug -p -R .gnu_debuglink  --add-gnu-debuglink=green-bottles.debug green-bottles  ) || (rm -f green-bottles.debug; false)

We can try to describe what happened with an image:

The first objcopy(1) incantation generate the green-bottles.debug file. The second objcopy(1) incantation strip the debug symbols off green-bottles (now that they're stored in green-bottles.debug they are no more needed) and add the .gnu_debuglink ELF section to it.

Let's quickly look them via file(1):

$ file green-bottles green-bottles.debug
green-bottles:       ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/libexec/ld.elf_so, for NetBSD 7.99.29, not stripped
green-bottles.debug: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter *empty*, for NetBSD 7.99.29, not stripped

Using readelf we can note that now green-bottles has 32 sections and green-bottles.debug has 38 sections. green-bottles has one extra section that was added by the objcopy(1) incantation, let's see it:

$ readelf -x '.gnu_debuglink' green-bottles

Hex dump of section '.gnu_debuglink':
  0x00000000 67726565 6e2d626f 74746c65 732e6465 green-bottles.de
  0x00000010 62756700 90b06f1c                   bug...o.

The .gnu_debuglink section contain the basename(3) of the .debug file and its CRC32. The .gnu_debuglink section is used to properly pick the correct .debug file from the DEBUGDIR directory (we'll see how it will work later when we will invoke the GNU debugger).

Regarding the sections in the .debug file all of them are preserved but several have no data, we can check that by invoking:

$ readelf `seq -f '-x %g' 0 37` green-bottles.debug
$ readelf `seq -f '-x %g' 0 31` green-bottles

...and comparing their respective output.

Now that everything should be clearer we can just try to invoke it through gdb(1) and see what happens:

$ gdb ./green-bottles
GNU gdb (GDB) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64--netbsd".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./green-bottles...Reading symbols from /tmp/green-bottles/green-bottles.debug...done.
done.
(gdb) b main
Breakpoint 1 at 0xac0: file green-bottles.c, line 29.
(gdb) b sing_green_bottles
Breakpoint 2 at 0x940: file green-bottles.c, line 5.
(gdb) run
Starting program: /tmp/green-bottles/green-bottles

Breakpoint 1, main () at green-bottles.c:29
29      {
(gdb) n
32              for (i = 10; i > 0; i--) {
(gdb) n
33                      sing_green_bottles(i);
(gdb) print i
$1 = 10
(gdb) cont
Continuing.

Breakpoint 2, sing_green_bottles (n=10) at green-bottles.c:5
5       {
(gdb) bt
#0  sing_green_bottles (n=10) at green-bottles.c:5
#1  0x00000000b7802ad7 in main () at green-bottles.c:33
[... we can now looks and debug it as we wish! ...]

So we can see that the green-bottles.debug file is loaded from the same directory where green-bottles program was present (in our case /tmp/green-bottles/ but if a corresponding file .debug is not found gdb look for it in the DEBUGDIR, i.e. /usr/libdata/debug/; e.g. for /usr/bin/yes it will look for debug symbols in /usr/libdata/debug//usr/bin/yes.debug). This is the same for all other programs and libraries.

A look to what MKDEBUG and MKDEBUGLIB do

NetBSD already provides MKDEBUG and MKDEBUGLIB mk.conf(5) variables to achieve the separation of the debug symbols. They respectively split symbols from programs and libraries.

The implementation to do that is in src/share/mk/bsd.prog.mk (for programs) and src/share/mk/bsd.lib.mk (for libraries). Several global variables used are defined in src/share/mk/bsd.own.mk.

bsd.prog.mk

In bsd.prog.mk:58 if MKDEBUG is defined and not "no" [sic] the -g flag is added to CFLAGS.

In bsd.prog.mk:310 the internal __progdebuginstall make target is defined to install the .debug file for the respective program. It is then called from bsd.prog.mk:589 and bsd.prog.mk:604 (respectively for MKUPDATE == "no" and MKUPDATE != "no", please note the dependency operators ! vs : for the two cases).

In bsd.prog.mk:437 _PROGDEBUG.${_P} is defined as ${PROGNAME.${_P}}.debug, inside a for loop. ${_P} is just an element of the ${PROGS} and ${PROGS_CXX} lists. E.g.: for src/bin/echo echo is the PROG value. bsd.prog.mk turns single-program PROG and PROG_CXX variable into the multi-word PROGS and PROGS_CXX variables.

In bsd.prog.mk:545 there is the most important part. After checking if _PROGDEBUG.${_P} is defined a ${_PROGDEBUG.${_P}} target is defined and ${OBJCOPY} is invoked two times. In the first incantation the ${_PROGDEBUG.${_P}} file (containing the strip debug symbols) is generated for ${_P}. The second incantation is needed to get rid of (now no more needed) debug symbols from ${_P} and --add-gnu-debuglink add a .gnu_debuglink section to ${_P} containing the filename of the ${_PROGDEBUG.${_P}}; e.g. for echo it will be echo.debug (plus the CRC32 of echo.debug - padded as needed). Regarding other options used by ${OBJCOPY} we should note the -p option needed to preserve dates and -R is added in order to be sure to update the .gnu_debuglink section.

For a gentler introduction and to understand why these steps are needed please read (gdb.info)Separate Debug Files (you can just use info(1), i.e. info '(gdb.info)Separate Debug Files').

bsd.lib.mk

The logic and objcopy(1) incantation are similar to the ones used in bsd.prog.mk. The most interesting part is in bsd.lib.mk:622. Apart the *.debug files if MKDEBUGLIB is defined and not "no" [sic] also *_g.a archives are created for the respective libraries archives (although they are stored directly in the several lib/ directories not in /usr/libdata/debug/).

bsd.own.mk

In bsd.own.mk various DEBUG* variables are defined:

• DEBUGDIR: where *.debug files are stored. Please notice that this is also the place where debugging symbols are looked (for more information please give a look to objcopy(1))
• DEBUGGRP: the -g option passed to install(1) for installing debug symbols
• DEBUGOWN: the -o option passed to install(1) for installing debug symbols
• DEBUGMODE: the -m option passed to install(1) for installing debug symbols

Related works

dpkg

The Debian Developer's Reference written by the Developer's Reference Team has a Best practices for debug packages (section 6.7.9). The logic used is more or less the same of the one used by src/share/mk in NetBSD and described above.

After a quick inspection of dh_strip (part of debhelper package) some interesting ideas to look further are:

• the file(1) logic used in testfile() subroutine
• handling of non-C/C++ programming languages: OCaml native code shared libraries (*.cmxs) and nodejs binaries (*.node)

RPM

The Fedora Project Wiki contains some interesting tips, in particular regarding most common issues that happens in stripping debugging symbols in the Packaging:Debuginfo page. Some of the logic is handled in find-debuginfo.sh.

Another interesting resource is the Releases/FeatureBuildId page. The page discusses what Red Hat have done regarding using the .note.gnu.build-id section and why have done them.

(Yet another) interesting idea adopted by Fedora developers is the Features/MiniDebugInfo. More information regarding MiniDebugInfo are also present in (gdb.info)MiniDebugInfo. Please note that this is not completely related to stripping debugging symbols (indeed the MiniDebugInfo is directly stored in program/library!) but can be considered in order to provide better .core (both in the pkgsrc and NetBSD cases).

Mark J. Wielaard presented in FOSDEM 2016 a talk that summarizes many of the thematics discussed in this diary. Abstract, video recording and more resources are available in the FOSDEM website correspective event page: Where are your symbols, debuginfo and sources?. Apart his talk a very interesting reading is his blog post regarding the talk. In the blog post there are a lot of interesting information, all worth to be taken in consideration also for the pkgsrc case.

Conclusion

In this blog post we have learned what's happening when we use MKDEBUG* mk.conf(5) variables and how everything works.

We have also gave a quick look to other related works, in particular RPM and dpkg package managers.

If you are curious on what I'm doing right now and you would like to also look at the code you can give a look to the git pkgsrc repository repository fork in the debugpkg branch.

Apart the several references discussed above if you would like to learn more about several aspects that wasn't discussed there... Introduction to the DWARF Debugging Format written by Michael Eager is a good starting point for DWARF (debugging data format); you can also use objdump -g to show these information in the *.debug files. Regarding GDB a gentle introduction to it is Using GNU's GDB Debugger by Peter Jay Salzman.

I would like to thanks Google for organizing Google Summer of Code and The NetBSD Foundation, without them I would not be able to work on this project!

A particular and big thank you goes to my mentors David Maxwell, Jöerg Sonnenberger, Taylor R. Campbell, Thomas Klausner and William J. Coldwell for the invaluable help, guidance and feedbacks they're providing!

References

• The ELF Object File Format: Introduction, Eric Youngdale
• The ELF Object File Format by Dissection, Eric Youngdale
• Tool Interface Standard (TIS) Executable and Linking Format (ELF) Specification Version 1.2, TIS Committee
• DWARF Debugging Information Format Version 4, DWARF Debugging Information Format Committee
• Introduction to the DWARF Debugging Format, Michael Eager
• Debugging with GDB Tenth Edition for GDB Version 7.10.1, Free Software Foundation, Inc.
• Using GNU's GDB Debugger, Peter Jay Salzman
• Debian Developer's Reference, Developer's Reference Team
• Where are your Symbols, Debuginfo and Sources?, Mark J. Wielaard
• make(1)
• elf(5)
• file(1)
• gcc(1)
• readelf(1)
• objdump(1)
• objcompy(1)
• gdb(1)
• src/share/bsd.README, 1.353
• src/share/bsd.prog.mk, 1.299
• src/share/bsd.lib.mk, 1.367
• src/share/bsd.own.mk, 1.927

A recent discussion on the port-vax mailing list brought a problem with the default installation method (when booting from CD, which typically is the easiest way) to my attention: it would not work on machines with 16 MB RAM or less.

So, can we do better? Looking at the size of a GENERIC kernel:

   text    data     bss     dec     hex filename
2997389   67748  173044 3238181  316925 netbsd

it seems we can not easily go below 4 MB (and for other reasons we would need to compile the bootloader differently for that anyway). But 16MB is still quite a difference, so it should work.

Now at the time I started this quest, I only had one VAX machine in real hardware - a VaxStation 4000 M96a, one of the fastest machines, and with 128 MB RAM well equipped. This is nice if you try to natively compile modern gcc, but I did not feel like fiddling with my hardware to create a better test environment for small RAM installations.

Like a year (or so) ago, when I fixed the VAX primary boot blocks (with lots of help from various vaxperts on the port-vax mailing list), SIMH, found in pkgsrc as emulators/simh, proved helpful. Testing various configurations I found an emulated VAX 11/780 with 8 MB to be the smallest I could get working.

The first step of the tuning was obvious: the CD image used a ramdisk based kernel, with the ramdisk containing all of the install system. At the same time, most of the CD was unused. We already use different schemes on i386, amd64 and sparc64 - so I cloned the sparc64 one and adjusted it to VAX. Now we use the GENERIC kernel on CD and mount the ISO9660 filesystem on the CD itself as root file system. The VAX boot loader already could deal with this, only a minor fix was needed for the kernel to recognize some variants of CD drives as boot device.

The resulting CD did boot, but did not go far in userland. The CD did only contain a (mostly) empty /dev directory (without /dev/console), which causes init(8) to mount a tmpfs on /dev and run the MAKEDEV script there. But to my surprise, on the 11/780 mfs was used instead of tmpfs - and we will see why soon. Next step in preparation of the userland for the installer is creating additional tmpfs instances to deal with the read-only nature of the CD used as root. This did not work at all, the mount attempts simply failed - and the installer was very unhappy, as it could not create files in /tmp for example.

I checked, but tmpfs was part of the VAX GENERIC kernel. I tried the install CD on a simulated MicroVAX 3900 with 64 MB of RAM - and to my surprise all of /dev and the three additional tmpfs instances created later worked (as well as the installation procedure). I checked the source (stupid me) and then found the documentation: tmpfs reserved a hard coded 4 MB of RAM for the system. With the GENERIC kernel booted on a 8 MB machine, we had slightly less than 4 MB RAM free, so tmpfs never worked.

One step back - this explained why /dev ended up as a mfs instead of tmpfs. The MAKEDEV code is written to deal with kernels that do include tmpfs, but also with those that do not: it tried tmpfs, and falls back to mfs if that does not work. This made me think, I could do the same (but without even trying tmpfs): I changed the install CD scripts to use mfs instead of tmpfs. The main difference is: mfs uses a userland process to manage the swappable memory. However, we do not have any swap space yet. Checking when sysinst enables swapping for the first time, I found: it never did on VAX. Duh! I added the missing calls to machine dependent code in sysinst, but of course the installer can only enable swap after partitioning is done (and a swap partition got created).

Testing showed: we did not get far enough with four mfs instances. So let us try with fewer. One we do not need is the /dev one: I changed the CD content creation code to pre-populate /dev on the CD. This is not possible with all filesystems, including the original ISO9660 one, but with the so-called Rockridge Extensions it works. We know that it is a modern NetBSD kernel mounting the CD - so support for those extensions is always present. I made some errors and hit some bugs (that got fixed) on the way there, but soon the CD booted without creating a mfs (nor tmpfs) for /dev.

Still, three mfs instances did not survive until sysinst enabled swapping. The userland part was killed once the kernel ran out of memory. I needed tmpfs working with less than 4 MB memory free. After a slight detour and some discussion on the tech-kern mailing list, I changed tmpfs to deal (and only reserve a dynamically scaled amount of memory calculated bv the UVM memory management). With this change, a current install CD just works, and installation completes successful.

The following is just the start of the installation process, the sysinst part afterwards is standard stuff and left out for brevity.

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014                 
    The NetBSD Foundation, Inc.  All rights reserved.   
Copyright (c) 1982, 1986, 1989, 1991, 1993           
    The Regents of the University of California.  All rights reserved.
                                                                      
NetBSD 6.99.43 (GENERIC) #1: Thu Jun  5 22:01:14 CEST 2014
        martin@night-owl.duskware.de:/usr/obj/vax/usr/src/sys/arch/vax/compile/GENERIC
VAX 11/780
total memory = 8188 KB
avail memory = 3884 KB
mainbus0 (root)       
cpu0 at mainbus0: KA80, S/N 1234(0), hardware ECO level 7(112)
cpu0: 4KB L1 cachen, no FPA                                   
sbi0 at mainbus0           
mem0 at sbi0 tr1: standard
mem1 at sbi0 tr2: standard
uba1 at sbi0 tr3: DW780   
dz1 at uba1 csr 160100 vec 304 ipl 15
mtc0 at uba1 csr 174500 vec 774 ipl 15
mscpbus0 at mtc0: version 5 model 5   
mscpbus0: DMA burst size set to 4  
uda0 at uba1 csr 172150 vec 770 ipl 15
mscpbus1 at uda0: version 3 model 6   
mscpbus1: DMA burst size set to 4  
de0 at uba1 csr 174510 vec 120 ipl 15: delua, hardware address 08:00:2b:cc:dd:ee
mt0 at mscpbus0 drive 0: TU81                                                  
mt1 at mscpbus0 drive 1: TU81
mt2 at mscpbus0 drive 2: TU81
mt3 at mscpbus0 drive 3: TU81
ra0 at mscpbus1 drive 0: RA92
ra1 at mscpbus1 drive 1: RA92
racd0 at mscpbus1 drive 3: RRD40
ra0: size 2940951 sectors       
ra1: no disk label: size 2940951 sectors
racd0: size 1331200 sectors             
boot device: racd0         
root on racd0a dumps on racd0b
root file system type: cd9660 
init: kernel secur           

You are using a serial console, we do not know your terminal emulation.
Please select one, typical values are:

        vt100
        ansi
        xterm

Terminal type (just hit ENTER for 'vt220'): xterm
                                                                                
 NetBSD/vax 6.99.43                                                             
                                                                                
 This menu-driven tool is designed to help you install NetBSD to a hard disk,   
 or upgrade an existing NetBSD system, with a minimum of work.                  
 In the following menus type the reference letter (a, b, c, ...) to select an   
 item, or type CTRL+N/CTRL+P to select the next/previous item.                  
 The arrow keys and Page-up/Page-down may also work.                            
 Activate the current selection from the menu by typing the enter key.          


                +---------------------------------------------+
                |>a: Installation messages in English         |
                | b: Installation auf Deutsch                 |
                | c: Mensajes de instalacion en castellano    |
                | d: Messages d'installation en français      |
                | e: Komunikaty instalacyjne w jezyku polskim |
                +---------------------------------------------+

Overall this improved NetBSD to better deal with small memory systems. The VAX specific install changes can be brought over to other ports as well, but sometimes changes to the bootloader will be needed.

Julian Djamil Fagir wrote a blog post about his GSoC project

As one of five, I've been chosen for participating in Google Summer Of Code (GSoC) this year for NetBSD. My project is to write a binary upgrade tool for NetBSD, optionally with a “live update” functionality.

Why an upgrade tool? – Yes, updating currently is easy. You download the set tarballs from a mirror, unpack the kernel, reboot, unpack the rest, reboot, and done. But this is an exhausting procedure, and you have to know that there are actually updates, and what they affect.

read more

After spending last year on improving ARM test coverage (and then fixing bugs when found), which greatly improved ARM test results, I now turned to MIPS. I used to have some SGI O2 machines, but for some (yet unclear) reason, none of them powers up any more. I also had an alchemy base MeshCube, but that broke too.

Some time ago, Ingenics donated a CI20 board to me and I am in the process of getting that testable. Michael Lorenz did most of the needed work already, but there are issues with the network driver, which make automatic test runs hard.

When a few days ago cavium/octeon support was added to NetBSD-current, I just had to buy an ERLite-3 device:

This is probably the cheapest MIPS64 hardware currently available. It is in-store at many customer electronics shops all over the world.

The ERLite-3 uses a big-endian dual-core octeon chipset, has external serial console (via a cisco console cable) and three gigE ethernet ports. It also features an internal (built in) USB hard disk. It can be configured to boot the NetBSD kernel from that usb disk, or load it via tftp from another server. But booting from internal "disk" plus multiple gigE ports makes it an ideal device for a NetBSD based home or small office firewall, DNS cache, DHCP server setup.

From the NetBSD point of view this device is as plug&play as you can get. Connect the serial console cable, reboot it, press Ctrl-C during early boot and get to the u-boot prompt. Prepare a user land and kernel, like:

build.sh -m evbmips64-eb sets
build.sh -m evbmips64-eb kernel=ERLITE

The kernel build will produce a "netbsd" and "netbsd.elf32" file. Extract the created sets in the NFS root directory, cd to the dev directory there and run "sh MAKEDEV all". Put "netbsd" into the NFS root directory. Copy "netbsd.elf32" to the tftp server directory (I renamed mine to "erlite.elf32") and then go back to the edge router console.

dhcp
tftp $loadaddr erlite.elf32
bootoctlinux

and your kernel should boot. (Never mind the funny name of the boot command).

The obligatory dmesg:

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 7.99.15 (ERLITE) #1: Wed May  6 21:40:41 CEST 2015
        martin@night-owl.duskware.de:/usr/src/sys/arch/evbmips/compile/ERLITE
total memory = 512 MB
avail memory = 490 MB
timecounter: Timecounters tick every 10.000 msec
mainbus0 (root)
cpu0 at mainbus0: 500.00MHz (hz cycles = 5000000, delay divisor = 500)
cpu0: Cavium CN50xx (0xd0601) Rev. 1 with software emulated floating point
cpu0: 64 TLB entries, 512TB (49-bit) VAs, 512TB (49-bit) PAs, 256MB max page size
cpu0: 32KB/128B 4-way set-associative L1 instruction cache
cpu0: 16KB/128B 64-way set-associative write-back coherent L1 data cache
iobus0 at mainbus0
iobus0: initializing POW
iobus0: initializing FPA
com0 at iobus0: address=0x0001180000000800: ns16650, no ERS, working fifo
com0: console
com at iobus0: address=0x0001180000000c00 not configured
octeon_rnm0 at iobus0: address=0x0001180040000000
octeon_rnm0: random number generator enabled: 1hz
octeon_twsi at iobus0: address=0x0001180000001000 not configured
octeon_mpi at iobus0: address=0x0001070000001000 not configured
octeon_gmx0 at iobus0: address=0x0001180008000000
cnmac0 at octeon_gmx0: address=0x0001180008000000: RGMII
cnmac0: Ethernet address 04:18:d6:f0:4b:e4
atphy0 at cnmac0 phy 7: Atheros AR8035 10/100/1000 PHY, rev. 2
atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX-FDX, 1000baseT-FDX, auto
cnmac1 at octeon_gmx0: address=0x0001180008000000: RGMII
cnmac1: Ethernet address 04:18:d6:f0:4b:e5
atphy1 at cnmac1 phy 6: Atheros AR8035 10/100/1000 PHY, rev. 2
atphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX-FDX, 1000baseT-FDX, auto
cnmac2 at octeon_gmx0: address=0x0001180008000000: RGMII
cnmac2: Ethernet address 04:18:d6:f0:4b:e6
atphy2 at cnmac2 phy 5: Atheros AR8035 10/100/1000 PHY, rev. 2
atphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX-FDX, 1000baseT-FDX, auto
dwctwo0 at iobus0: address=0x0001180068000000
usb0 at dwctwo0: USB revision 2.0
bootbus0 at mainbus0
timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
timecounter: Timecounter "mips3_cp0_counter" frequency 500000000 Hz quality 100
uhub0 at usb0: vendor 0000 DWC2 root hub, class 9/0, rev 2.00/1.00, addr 1
uhub0: 1 port with 1 removable, self powered
umass0 at uhub0 port 1 configuration 1 interface 0
umass0: vendor 13fe USB DISK 2.0, rev 2.00/1.00, addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, 1 lun per target
sd0 at scsibus0 target 0 lun 0: <, USB DISK 2.0, PMAP> disk removable
sd0: 3824 MB, 959 cyl, 255 head, 32 sec, 512 bytes/sect x 7831552 sectors
boot device: 
root device: cnmac0
dump device: 
file system (default generic): 
root on cnmac0
mountroot: trying nfs...
nfs_boot: trying DHCP/BOOTP
cnmac0: link state UP (was UNKNOWN)
cnmac0: link state DOWN (was UP)
cnmac0: link state UP (was DOWN)
nfs_boot: DHCP next-server: 192.168.150.188
nfs_boot: my_domain=duskware.de
nfs_boot: my_addr=192.168.150.192
nfs_boot: my_mask=255.255.254.0
nfs_boot: gateway=192.168.151.1
root on 192.168.150.188:/hosts/erlite
root time: 0x554ad8bc
root file system type: nfs
kern.module.path=/stand/evbmips/7.99.15/modules
WARNING: no TOD clock present
WARNING: using filesystem time
WARNING: CHECK AND RESET THE DATE!
init path (default /sbin/init): 
init: copying out path `/sbin/init' 11
pid 1(init): ABI set to N32 (e_flags=0x20000027)

The port to octeon (thanks IIJ!) is new, but already quite complete. The second cpu core is not yet started, but I hope this will be fixed very soon. No MIPS has been part of the automatic test runs recently, so there is some fallout, as expected. On first try I got several core files, among others from pkg_info, pkg_admin and gdb. The latter makes analyzing the crashes a bit more challenging, but give me a few days ;-}

The 10th pkgsrcCon is happening on the weekend of July 4th and 5th 2015 in Berlin. Developers, contributors, and users are all welcome to attend.

More details can be found on the pkgsrcCon 2015 website.

Call for presentations

Everyone is welcome to make a presentation. So please do! If you already have title or topic please send an email to wiedi@frubar.net.

I look forward to seeing you there!

Last month I have worked on features of the Process Plugin on NetBSD and support for threads in core(5) files.

What has been done in NetBSD

I've managed to achieve the following accomplishments:

Introduction of PT_SETSTEP and PT_CLEARSTEP

This allows to:

• singlestep particular threads,
• combine PT_STEP with PT_SYSCALL,
• combine PT_STEP and emission of a signal.

There are equivalent operations in FreeBSD with the same names.

Introduction of helper macro PTRACE_BREAKPOINT_ASM

This code was prepared by Nick Hudson and it was used in ATF tests to verify behavior of software breakpoints.

Addition of new sysctl(2) functions

Add new defines in sysctl(2) on amd64 and i386 ports. These values are defined in <x86/cpu.h>:

• CPU_FPU_SAVE (15)
  

     int: FPU Instructions layout
     * to use this, CPU_OSFXSR must be true
     * 0: FSAVE
     * 1: FXSAVE
     * 2: XSAVE
     * 3: XSAVEOPT
  

• CPU_FPU_SAVE_SIZE (16)
  

     int: FPU Instruction layout size
  

• CPU_XSAVE_FEATURES (17)
  

     quad: FPU XSAVE features
  

• Bump CPU_MAXID from 15 to 18.

These values are useful to get FPU (floating point unit) properties in e.g. a debugger. This information is required to properly implement FPR (floating point register) tracer operations on x86 processors.

Corrections in ptrace(2) man-page

Few mistakes were corrected to make the documentation more correct.

ATF tests cleanup in ptrace(2)

There were added new tests for new ptrace(2) operations (PT_SETSTEP and PT_CLEARSTEP).

Also several tests were updated to reflect the current state of "successfully passed" and "expected failure". This is important to mark issues that are already known and quickly catch new regressions in future changes.

F_GETPATH in fcntl(2)

It was decided that NetBSD will not introduce new fcntl(2) function for compatibility with certain other systems. This means that once LLDB will require this feature, we will need to introduce a workaround in the project.

What has been done in LLDB

The NetBSD Process Plugin in LLDB acquired new capabilities. Additionally enhancements in LLDB were developed such as handling threads in core(5) files.

Floating point support

The x86_64 architecture supports in default properties FXSAVE processor instructions. The FXSAVE feature allows to operate over floating point registers. A thread state (context) is composed of (and not restricted to) general and floating point registers.

The NetBSD Process Plugin acquired the functionality to read these registers and optionally set new values for them.

Watchpoint support

A programmer can use hardware assisted watchpoints to stop execution of a tracee whenever a certain variable or instruction was read/written/executed. The support for this feature has been implemented on NetBSD with ptrace(2) operations PT_SETDBREGS and PT_GETDBREGS. These operations are now available in the LLDB Process plugin.

Threads support in core(5) files

I've included support for LWPs in core(5) files. This means that larger programs with threads, like Firefox that emitted coredump for some reason (usually during crash) can be investigated postmortem.

Demo

I've prepared a recording with the script(1) utility from the NetBSD base system. To replay it:

script -p ./firefox-core.typescript

This recording shows a debugging session of a Firefox core(5) file.

(I was kind to prepare a Linux version of the NetBSD script(1) here).

Plan for the next milestone

The plan for the next milestone is continuing development of threads in the NetBSD Process Plugin. I will need to work more on correctness of ptrace(2) calls as new issues were detected in setups with threads that resulted in crashes.

There is also ongoing work on a new build node running NetBSD-current (prerelease of 8) and building LLVM+Clang+LLDB. I'm working on enabling unit tests to catch functional regressions quickly. The original LLDB node cluster was privately funded by myself in the last two years and has been switched to a machine hosted by The NetBSD Foundation.

To keep this machine up and running (8 CPU, 24 GB RAM) community support through donations is required. This is crucial to actively maintain the LLVM toolchain (Clang, LLDB and others) on NetBSD.

This work was sponsored by The NetBSD Foundation.

The NetBSD Foundation is a non-profit organization and welcomes any donations to help us continue funding projects and services to the open-source community. Please consider visiting the following URL, and chip in what you can:

http://netbsd.org/donations/#how-to-donate

Last month I have worked on features of the Process Plugin on NetBSD and support for threads in core(5) files.

What has been done in NetBSD

I've managed to achieve the following accomplishments:

Introduction of PT_SETSTEP and PT_CLEARSTEP

This allows to:

• singlestep particular threads,
• combine PT_STEP with PT_SYSCALL,
• combine PT_STEP and emission of a signal.

There are equivalent operations in FreeBSD with the same names.

Introduction of helper macro PTRACE_BREAKPOINT_ASM

This code was prepared by Nick Hudson and it was used in ATF tests to verify behavior of software breakpoints.

Addition of new sysctl(2) functions

Add new defines in sysctl(2) on amd64 and i386 ports. These values are defined in <x86/cpu.h>:

• CPU_FPU_SAVE (15)
  

     int: FPU Instructions layout
     * to use this, CPU_OSFXSR must be true
     * 0: FSAVE
     * 1: FXSAVE
     * 2: XSAVE
     * 3: XSAVEOPT
  

• CPU_FPU_SAVE_SIZE (16)
  

     int: FPU Instruction layout size
  

• CPU_XSAVE_FEATURES (17)
  

     quad: FPU XSAVE features
  

• Bump CPU_MAXID from 15 to 18.

These values are useful to get FPU (floating point unit) properties in e.g. a debugger. This information is required to properly implement FPR (floating point register) tracer operations on x86 processors.

Corrections in ptrace(2) man-page

Few mistakes were corrected to make the documentation more correct.

ATF tests cleanup in ptrace(2)

There were added new tests for new ptrace(2) operations (PT_SETSTEP and PT_CLEARSTEP).

Also several tests were updated to reflect the current state of "successfully passed" and "expected failure". This is important to mark issues that are already known and quickly catch new regressions in future changes.

F_GETPATH in fcntl(2)

It was decided that NetBSD will not introduce new fcntl(2) function for compatibility with certain other systems. This means that once LLDB will require this feature, we will need to introduce a workaround in the project.

What has been done in LLDB

The NetBSD Process Plugin in LLDB acquired new capabilities. Additionally enhancements in LLDB were developed such as handling threads in core(5) files.

Floating point support

The x86_64 architecture supports in default properties FXSAVE processor instructions. The FXSAVE feature allows to operate over floating point registers. A thread state (context) is composed of (and not restricted to) general and floating point registers.

The NetBSD Process Plugin acquired the functionality to read these registers and optionally set new values for them.

Watchpoint support

A programmer can use hardware assisted watchpoints to stop execution of a tracee whenever a certain variable or instruction was read/written/executed. The support for this feature has been implemented on NetBSD with ptrace(2) operations PT_SETDBREGS and PT_GETDBREGS. These operations are now available in the LLDB Process plugin.

Threads support in core(5) files

I've included support for LWPs in core(5) files. This means that larger programs with threads, like Firefox that emitted coredump for some reason (usually during crash) can be investigated postmortem.

Demo

I've prepared a recording with the script(1) utility from the NetBSD base system. To replay it:

script -p ./firefox-core.typescript

This recording shows a debugging session of a Firefox core(5) file.

(I was kind to prepare a Linux version of the NetBSD script(1) here).

Plan for the next milestone

The plan for the next milestone is continuing development of threads in the NetBSD Process Plugin. I will need to work more on correctness of ptrace(2) calls as new issues were detected in setups with threads that resulted in crashes.

There is also ongoing work on a new build node running NetBSD-current (prerelease of 8) and building LLVM+Clang+LLDB. I'm working on enabling unit tests to catch functional regressions quickly. The original LLDB node cluster was privately funded by myself in the last two years and has been switched to a machine hosted by The NetBSD Foundation.

To keep this machine up and running (8 CPU, 24 GB RAM) community support through donations is required. This is crucial to actively maintain the LLVM toolchain (Clang, LLDB and others) on NetBSD.

This work was sponsored by The NetBSD Foundation.

The NetBSD Foundation is a non-profit organization and welcomes any donations to help us continue funding projects and services to the open-source community. Please consider visiting the following URL, and chip in what you can:

http://netbsd.org/donations/#how-to-donate

Coming soon we have a new set of kernel synchronization routines - localcount(9) - which provide a medium-weight reference-counting mechanism. From the manual page, "During normal operations, localcounts do not need the interprocessor synchronization associated with atomic_ops(3) atomic memory operations, and (unlike psref(9)) localcount references can be held across sleeps and can migrate between CPUs. Draining a localcount requires more expensive interprocessor synchronization than atomic_ops(3) (similar to psref(9)). And localcount references require eight bytes of memory per object per-CPU, significantly more than atomic_ops(3) and almost always more than psref(9)."

We'll be adding localcount(9) reference counting to the device driver cdevsw and bdevsw structures, to ensure that a (modular) device driver cannot be removed while it is active. Modular drivers with initializers for these structures need to be modified to initialize their localcount members, using the DEVSW_MODULE_INIT macro (this change is mandatory for all loadable drivers). To take advantage of the reference counting, the drivers also need to replace all calls to bdevsw_lookup() and cdevsw_lookup() with bdevsw_lookup_acquire() and cdevsw_lookup_acquire() respectively, and then release the reference using bdevsw_release() and cdevsw_release().

We'll also be using localcount(9) to provide reference-counting of individual device units, to prevent a unit from being destroyed while it is active. To implement device unit reference-counting, all calls to device_lookup(), device_find_by_driver_unit(), and device_lookup_private() need to be replaced by their corresponding *_acquire() variant; when the caller is finished using the device, it must release the reference using device_release().

More details and examples can be seen by examining the prg-localcount2 branch in cvs including the new localcount(9) manual page!

Coming soon we have a new set of kernel synchronization routines - localcount(9) - which provide a medium-weight reference-counting mechanism. From the manual page, "During normal operations, localcounts do not need the interprocessor synchronization associated with atomic_ops(3) atomic memory operations, and (unlike psref(9)) localcount references can be held across sleeps and can migrate between CPUs. Draining a localcount requires more expensive interprocessor synchronization than atomic_ops(3) (similar to psref(9)). And localcount references require eight bytes of memory per object per-CPU, significantly more than atomic_ops(3) and almost always more than psref(9)."

We'll be adding localcount(9) reference counting to the device driver cdevsw and bdevsw structures, to ensure that a (modular) device driver cannot be removed while it is active. Modular drivers with initializers for these structures need to be modified to initialize their localcount members, using the DEVSW_MODULE_INIT macro (this change is mandatory for all loadable drivers). To take advantage of the reference counting, the drivers also need to replace all calls to bdevsw_lookup() and cdevsw_lookup() with bdevsw_lookup_acquire() and cdevsw_lookup_acquire() respectively, and then release the reference using bdevsw_release() and cdevsw_release().

We'll also be using localcount(9) to provide reference-counting of individual device units, to prevent a unit from being destroyed while it is active. To implement device unit reference-counting, all calls to device_lookup(), device_find_by_driver_unit(), and device_lookup_private() need to be replaced by their corresponding *_acquire() variant; when the caller is finished using the device, it must release the reference using device_release().

More details and examples can be seen by examining the prg-localcount2 branch in cvs including the new localcount(9) manual page!

We are very happy to announce that the selection process in this year's Summer of Code with its bargaining of slots and what student gets assigned to which project is over. As a result, the following students will take on their projects:

• Leonardo Taccari will work add multi-packages support to pkgsrc.
• Maya Rashish will work on the LFS cleanup.
• Utkarsh Anand will make Anita support multiple virtual machine systems and more architectures within them to improve testing coverage.

What follows now is a community bonding period until May 30th, followed by a coding period over the summer (it's Summer of Code, after all ) until August 21st, evaluations, code submission and an announcement of the results on September 6th 2017.

Good luck to all our students and their mentors - we look forward to your work results, and welcome you to The NetBSD Project!

We are very happy to announce that the selection process in this year's Summer of Code with its bargaining of slots and what student gets assigned to which project is over. As a result, the following students will take on their projects:

• Leonardo Taccari will work add multi-packages support to pkgsrc.
• Maya Rashish will work on the LFS cleanup.
• Utkarsh Anand will make Anita support multiple virtual machine systems and more architectures within them to improve testing coverage.

What follows now is a community bonding period until May 30th, followed by a coding period over the summer (it's Summer of Code, after all ) until August 21st, evaluations, code submission and an announcement of the results on September 6th 2017.

Good luck to all our students and their mentors - we look forward to your work results, and welcome you to The NetBSD Project!

QEMU - the FAST! processor emulator - is a generic, Open Source, machine emulator and virtualizer. It defines state of the art in modern virtualization.

This software has been developed for multiplatform environments with support for NetBSD since virtually forever. It's the primary tool used by the NetBSD developers and release engineering team. It is run with continuous integration tests for daily commits and execute regression tests through the Automatic Test Framework (ATF).

Since the projects keep researching and developing support for various modern trends in computing, the gap between the QEMU featureset in NetBSD and Linux diverged due to lack of active NetBSD maintenance resulted in breaking the default build.

The QEMU developers warned the Open Source community - with version 2.9 of the emulator - that they will eventually drop support for suboptimally supported hosts if nobody will step in and take the maintainership to refresh the support. This warning was directed to major BSDs, Solaris, AIX and Haiku.

Thankfully the NetBSD position has been filled - making NetBSD to restore official maintenance.

The current roadmap in QEMU/NetBSD is as follows:

• address all build failures [all patches sent to review, part of them already merged upstream],
• address all build warnings,
• restore the QEMU setup to run regression tests on NetBSD.

With the goal to move on to the maintenance mode, catching up with regressions, adding NetBSD node in the regression tests cluster and reducing the featureset gap. There are various missing functions on NetBSD, including: resurrecting user-mode emulation, suboptimal kernel aio(3) support, hugepagefs support, hardware assisted virtualization, passthrough PCI and SRIOV.

This effort is spare time activity - as of now without commercial support - and possible thanks to unloading the developer (myself) from more urgently pending tasks in NetBSD thanks to the contract for enhancing debuggers in business hours.

QEMU - the FAST! processor emulator - is a generic, Open Source, machine emulator and virtualizer. It defines state of the art in modern virtualization.

This software has been developed for multiplatform environments with support for NetBSD since virtually forever. It's the primary tool used by the NetBSD developers and release engineering team. It is run with continuous integration tests for daily commits and execute regression tests through the Automatic Test Framework (ATF).

Since the projects keep researching and developing support for various modern trends in computing, the gap between the QEMU featureset in NetBSD and Linux diverged due to lack of active NetBSD maintenance resulted in breaking the default build.

The QEMU developers warned the Open Source community - with version 2.9 of the emulator - that they will eventually drop support for suboptimally supported hosts if nobody will step in and take the maintainership to refresh the support. This warning was directed to major BSDs, Solaris, AIX and Haiku.

Thankfully the NetBSD position has been filled - making NetBSD to restore official maintenance.

The current roadmap in QEMU/NetBSD is as follows:

• address all build failures [all patches sent to review, part of them already merged upstream],
• address all build warnings,
• restore the QEMU setup to run regression tests on NetBSD.

With the goal to move on to the maintenance mode, catching up with regressions, adding NetBSD node in the regression tests cluster and reducing the featureset gap. There are various missing functions on NetBSD, including: resurrecting user-mode emulation, suboptimal kernel aio(3) support, hugepagefs support, hardware assisted virtualization, passthrough PCI and SRIOV.

This effort is spare time activity - as of now without commercial support - and possible thanks to unloading the developer (myself) from more urgently pending tasks in NetBSD thanks to the contract for enhancing debuggers in business hours.