crunch'd programs emit ELF "warnings" at runtime on Raspberry Pi 3

[Rob Newberry <robthedude%mac.com@localhost>]

Short summary:

	- create a normal Raspberry Pi 3 image (a recently created build should be fine, but you need one of the intermediate pieces as well — see below)

		./build.sh -m evbarm -a earmv7hf -u release

	- boot the resulting armv7.img file on a Raspberry Pi 3

	- copy over the “ramdiskbin” file (produced when the above build iterates 
		through "src/distrib/evbarm/instkernel/ramdisk/ramdiskbin”) 

	- try to run the “ramdiskbin” crunch-ed/statically-linked executable

Do you get messages from the kernel?

	[  42.7503189] ./ramdiskbin: Unknown elf note type 0 (unknown tag): [namesz=0, descsz=0 name=]
	[  42.7645439] ./ramdiskbin: Unknown elf note type 7 (unknown tag): [namesz=0, descsz=0 name=]




Longer story:


After several years, I’m (re)familiarizing myself with NetBSD, using a Raspberry Pi 3.  I’m interested in prototyping more deeply embedded systems, so I started playing with crunch’d builds.  I’ve made a lot of progress, but I recently hit a weird thing that “feels” like something someone on this list with more ARM knowledge either would or should know about.  It “seems” like a bug to me, but I don’t know if it’s in the kernel’s handling of ELF files, or in the way crunch-ed programs (or possible simply statically linked programs) are built.

I think the following steps should reproduce it for anyone — and they’re likely steps that you may have done already.

As documented in the Wiki (http://wiki.netbsd.org/ports/evbarm/raspberry_pi/)...

Generate a build that you can run on a Raspberry Pi 3:

	./build.sh -m evbarm -a  earmv7hf -u release

This will create the “armv7.img” file, which you can write to an SD card.

But it ALSO will create a “ramdiskbin” image as part of building an installer (it’ll be in the obj directory for "src/distrib/evbarm/instkernel/ramdisk/ramdiskbin”) — even though on Raspberry Pi 3, it doesn’t really get used because the armv7.img is a full working system.

That “ramdiskbin” image is also a statically-linked, crunch-ed program and serves as an example.  Copy it to the SD card (I was copying it to the MS-DOS partition because the FFS partition hasn’t been re-sized yet).

Now boot up and try to run the “ramdiskbin” program.  Do you get these messages?

	armv7# ./ramdiskbin
	[  42.7503189] ./ramdiskbin: Unknown elf note type 0 (unknown tag): [namesz=0, descsz=0 name=]
	[  42.7645439] ./ramdiskbin: Unknown elf note type 7 (unknown tag): [namesz=0, descsz=0 name=]

These messages are coming from sys/kern/exec_elf.c in netbsd_elf_note.  I’ve zero-knowledge of ELF file format, but as best I can tell the warning is harmless (it’s even removed in non DIAGNOSTIC builds).  But it does seem like there’s a bug somewhere — either the crunch-ed/statically-linked programs are built in a weird way, or the kernel isn’t parsing them properly (possibly because it encounters them so infrequently).

There is one other potential source of the problem.  I’m cross-building from a Mac.  So it’s possible that when you use a Mac to cross-build NetBSD’s source, the resulting tool chain does this.  If no one ELSE sees this problem, then I can try to fire up my NetBSD virtual machine and see if I can reproduce it.  It just takes so long :-).

Rob