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

[christos%astron.com@localhost (Christos Zoulas)]

In article <41374F8E-3989-407A-ADF1-D60B914D89C8%mac.com@localhost>,
Rob Newberry  <robthedude%mac.com@localhost> wrote:
>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
>:-).

$ fgrep ELF_NOTE_TYPE /usr/include/sys/exec_elf.h 
#define ELF_NOTE_TYPE_ABI_TAG           1
#define ELF_NOTE_TYPE_GNU_HWCAP         2
#define ELF_NOTE_TYPE_GNU_BUILD_ID      3
#define ELF_NOTE_TYPE_SUSE_TAG  1
#define ELF_NOTE_TYPE_SUSE_VERSION_TAG  0x45537553      /* SuSE in LE */
#define ELF_NOTE_TYPE_GO_BUILDID_TAG    4
#define ELF_NOTE_TYPE_NETBSD_TAG        1
#define ELF_NOTE_TYPE_CHECKSUM_TAG      2
#define ELF_NOTE_TYPE_PAX_TAG           3
#define ELF_NOTE_TYPE_MARCH_TAG         5
#define ELF_NOTE_TYPE_MCMODEL_TAG       6

So there is no 0 and no 7 tags that we know. What does readelf -n say
about this? Perhaps crunchgen does not do the right things with notes?

christos

>
>Rob
>
>
>