That is the important finding.
That it can be made to work even though the kernel that is running the module was not built for that purpose.
Mind is still in a deep fog, but play with od a bit.
An example of /bin/chrt in the K3-3.2.1 file (this can be done on your host system):
Code:
core2quad bin $ file chrt
chrt: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped
core2quad bin $ od -a x2 -t x1 chrt | less
0000000 del E L F soh soh soh nul nul nul nul nul nul nul nul nul
7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
0000020 stx nul ( nul soh nul nul nul l ack nul nul 4 nul nul nul
02 00 28 00 01 00 00 00 6c 86 00 00 34 00 00 00
0000040 h syn nul nul stx nul nul eot 4 nul sp nul bel nul ( nul
68 16 00 00 02 00 00 04 34 00 20 00 07 00 28 00
0000060 gs nul sub nul soh nul nul p nul dc3 nul nul nul dc3 nul nul
1d 00 1a 00 01 00 00 70 80 13 00 00 80 93 00 00
Pick a few that you have in both the Amazon image build and in the Buildroot output. Avoiding links to busybox <[:]
What is needed is to find a distinguishing byte sequence so that the binfmt_misc offset/string/mask can be set to tell the difference.
objdump, with selection of options, can help, as in:
Code:
core2quad bin $ objdump -s -h chrt | less
chrt: file format elf32-littlearm
Sections:
Idx Name Size VMA LMA File off Algn
0 .interp 00000013 00008114 00008114 00000114 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .note.ABI-tag 00000020 00008128 00008128 00000128 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
The .interp section should alway be the first, which **might** mean that its file offset will always be the same (114).
I included the .note.ABI-tag section because that may be a good place to put our AmazonHack mark if we need one.
Using readelf, we can get another view of the same information:
Code:
core2quad bin $ readelf -x 1 chrt
Hex dump of section '.interp':
0x00008114 2f6c6962 2f6c642d 6c696e75 782e736f /lib/ld-linux.so
0x00008124 2e3300 .3.
core2quad bin $ readelf -x 2 chrt
Hex dump of section '.note.ABI-tag':
0x00008128 04000000 10000000 01000000 474e5500 ............GNU.
0x00008138 00000000 02000000 06000000 0e000000 ................
I admit, I have never done this before, and we may have to stumble into the actual procedure to make it work.
Then in the "wrapper script" that binfmt_misc calls would use a utility to list the "NEEDED" library names and build the options to our set in /mnt/us