[Qemu-discuss] raspi2 unable to mount root fs using latest raspbian image

[Jacob Yundt]

This could be related to a recent post[1], but I'm unable to boot the
latest raspbian stretch image ("2017-09-07-raspbian-stretch-lite.img")
using 2.11.0-rc2 (or master).

I'm using these args:

./qemu-system-arm -M raspi2 -kernel ~/stretch/kernel7.img -append "ro
earlyprintk loglevel=8 dwc_otg.lpm_enable=0 root=PARTUUID=11eccc69-02
elevator=deadline fsck.repair=yes rootfstype=ext4
console=ttyAMA0,115200 debug rootwait" -dtb
~/stretch/bcm2709-rpi-2-b.dtb -serial stdio -sd
~/stretch/2017-09-07-raspbian-stretch-lite.img


And I end up with this panic:

[3.414873] Waiting for root device PARTUUID=11eccc69-02...
[3.432500] mmc0: host does not support reading read-only switch,
assuming write-enable
[3.433265] mmc0: new SDHC card at address 4567
[3.437952] mmcblk0: mmc0:4567 QEMU! 1.73 GiB
[3.447732]  mmcblk0: p1 p2
[3.448958] mmcblk0: p2 size 3528040 extends beyond EOD, truncated
[3.551639] EXT4-fs (mmcblk0p2): bad geometry: block count 441005
exceeds size of device (440960 blocks)
[3.555863] List of all partitions:
[3.556767] 01004096 ram0 [3.557104]  (driver?)
[3.557369] 01014096 ram1 [3.557601]  (driver?)
[3.557801] 01024096 ram2 [3.558025]  (driver?)
[3.558223] 01034096 ram3 [3.558446]  (driver?)
[3.558640] 01044096 ram4 [3.558860]  (driver?)
[3.559051] 01054096 ram5 [3.559271]  (driver?)
[3.559453] 01064096 ram6 [3.559667]  (driver?)
[3.559858] 01074096 ram7 [3.560081]  (driver?)
[3.560278] 01084096 ram8 [3.560490]  (driver?)
[3.560681] 01094096 ram9 [3.560892]  (driver?)
[3.561097] 010a4096 ram10 [3.561324]  (driver?)
[3.561520] 010b4096 ram11 [3.561747]  (driver?)
[3.561967] 010c4096 ram12 [3.562282]  (driver?)
[3.562547] 010d4096 ram13 [3.562851]  (driver?)
[3.563126] 010e4096 ram14 [3.563865]  (driver?)
[3.564151] 010f4096 ram15 [3.564437]  (driver?)
[3.564715] b300 1810944 mmcblk0 [3.565314]  driver: mmcblk
[3.565924]   b301   42811 mmcblk0p1 11eccc69-01[3.566267]
[3.566440]   b302 1763840 mmcblk0p2 11eccc69-02[3.566751]
[3.566986] No filesystem could mount root, tried: [3.567299]  ext4
[3.567481]
[3.568053] Kernel panic - not syncing: VFS: Unable to mount root
fs on unknown-block(179,2)
[3.568643] CPU: 3 PID: 1 Comm: swapper/0 Tainted: GW
4.9.41-v7+ #1023
[3.569145] Hardware name: BCM2835
[3.569535] [<8010fb3c>] (unwind_backtrace) from [<8010c058>]
(show_stack+0x20/0x24)
[3.570357] [<8010c058>] (show_stack) from [<80455f84>]
(dump_stack+0xd4/0x118)
[3.571222] [<80455f84>] (dump_stack) from [<80209a28>] (panic+0xf0/0x274)
[3.571925] [<80209a28>] (panic) from [<80b01464>]
(mount_block_root+0x268/0x2b4)
[3.572639] [<80b01464>] (mount_block_root) from [<80b016c0>]
(mount_root+0x124/0x12c)
[3.573387] [<80b016c0>] (mount_root) from [<80b01860>]
(prepare_namespace+0x198/0x1e0)
[3.573929] [<80b01860>] (prepare_namespace) from [<80b00fe8>]
(kernel_init_freeable+0x2b4/0x2c8)
[3.574390] [<80b00fe8>] (kernel_init_freeable) from [<8071446c>]
(kernel_init+0x18/0x124)
[3.574805] [<8071446c>] (kernel_init) from [<80108148>]
(ret_from_fork+0x14/0x2c)
[3.575710] CPU1: stopping
[3.576110] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW
4.9.41-v7+ #1023
[3.576650] Hardware name: BCM2835
[3.577035] [<8010fb3c>] (unwind_backtrace) from [<8010c058>]
(show_stack+0x20/0x24)
[3.577692] [<8010c058>] (show_stack) from [<80455f84>]
(dump_stack+0xd4/0x118)
[3.578281] [<80455f84>] (dump_stack) from [<8010e1e4>]
(handle_IPI+0x2a4/0x2c4)
[3.578857] [<8010e1e4>] (handle_IPI) from [<801014e0>]
(bcm2836_arm_irqchip_handle_irq+0x7c/0xac)
[3.579654] [<801014e0>] (bcm2836_arm_irqchip_handle_irq) from
[<8071a47c>] (__irq_svc+0x5c/0x7c)
[3.580249] Exception stack(0xba94bf58 to 0xba94bfa0)
[3.580730] bf40:
 baf50470
[3.581219] bf60:   ba94a000 80c0312c 0002
80c03198 80c15f08 80c15f08
[3.581669] bf80:  ba94bfb4 80c040a4 ba94bfa8 80108a54
80108a58 6013 
[3.582182] [<8071a47c>] (__irq_svc) from [<80108a58>]
(arch_cpu_idle+0x34/0x4c)
[3.582616] [<80108a58>] (arch_cpu_idle) from [<80719bc4>]
(default_idle_call+0x34/0x48)
[3.583116] [<80719bc4>] (default_idle_call) from [<80161df0>]
(cpu_startup_entry+0xe4/0x160)
[3.583666] [<80161df0>] (cpu_startup_entry) from [<8010dcf0>]
(secondary_start_kernel+0x130/0x13c)
[3.584686] [<8010dcf0>] (secondary_start_kernel) from [<0010196c>]
(0x10196c)
[3.585478] CPU0: stopping
[3.585938] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW
4.9.41-v7+ #1023
[3.586425] Hardware name: BCM2835
[3.586757] [<8010fb3c>] 

Re: [Qemu-discuss] s390x user-mode working example

[Alex Kashchenko]

On 11/24/2017 12:52 PM, Thomas Huth wrote:

On 24.11.2017 12:19, Alex Kashchenko wrote:

Unfortunately, I just found that OpenJDK's JIT requires newer
instruction set than z900:

$ ./s390x-linux-user/qemu-s390x
~/jdk9/build/linux-s390x-normal-server-release/images/jdk/bin/java -version
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (vm_version_s390.hpp:367), pid=26037, tid=26039
#  guarantee((_features[0] & GnrlInstrExtFacilityMask) ==
GnrlInstrExtFacilityMask) failed: We no more support older than z10.


That looks like it is missing the so-called "general instruction
extension facility". You might be lucky - that's one of the extensions
that can already be enabled for testing purposes with the "qemu" CPU:
Try to start QEMU with the "-cpu qemu,ginste=true" parameter.
If it then still complains about missing facilities, try "-cpu help" to
list all recognized feature flags.


"-cpu qemu,ginste=true" helps to pass the check from previous email.



The following features can already be enabled with the "qemu" CPU (list
has been copy-n-pasted from the sources, but I hope you'll be able to
map it to the output of "-cpu help", too):

S390_FEAT_DAT_ENH,
S390_FEAT_IDTE_SEGMENT,
S390_FEAT_STFLE,
S390_FEAT_EXTENDED_IMMEDIATE,
S390_FEAT_EXTENDED_TRANSLATION_2,
S390_FEAT_EXTENDED_TRANSLATION_3,
S390_FEAT_LONG_DISPLACEMENT,
S390_FEAT_LONG_DISPLACEMENT_FAST,
S390_FEAT_ETF2_ENH,
S390_FEAT_STORE_CLOCK_FAST,
S390_FEAT_MOVE_WITH_OPTIONAL_SPEC,
S390_FEAT_ETF3_ENH,
S390_FEAT_COMPARE_AND_SWAP_AND_STORE,
S390_FEAT_COMPARE_AND_SWAP_AND_STORE_2,
S390_FEAT_GENERAL_INSTRUCTIONS_EXT,
S390_FEAT_EXECUTE_EXT,
S390_FEAT_FLOATING_POINT_SUPPPORT_ENH,
S390_FEAT_STFLE_45,
S390_FEAT_STFLE_49,
S390_FEAT_LOCAL_TLB_CLEARING,
S390_FEAT_STFLE_53,


Applying all the options from this list:

-cpu 
qemu,ginste=true,dateh=true,idtes=true,stfle=true,eimm=true,etf2=true,etf3=true,ldisp=true,ldisphp=true,etf3eh=true,etf3eh=true,csst=true,csst2=true,ginste=true,exrl=true,fpseh=true,stfle45=true,stfle49=true,ltlbc=true,stfle53=true


still causes the SIGILL during the JVM init though.

Thanks for the list! At least I know now that the problem is not caused 
by some local misconfiguration.


--
-Alex

Re: [Qemu-discuss] s390x user-mode working example

[Thomas Huth]

On 24.11.2017 12:19, Alex Kashchenko wrote:
> Unfortunately, I just found that OpenJDK's JIT requires newer
> instruction set than z900:
> 
> $ ./s390x-linux-user/qemu-s390x
> ~/jdk9/build/linux-s390x-normal-server-release/images/jdk/bin/java -version
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (vm_version_s390.hpp:367), pid=26037, tid=26039
> #  guarantee((_features[0] & GnrlInstrExtFacilityMask) ==
> GnrlInstrExtFacilityMask) failed: We no more support older than z10.

That looks like it is missing the so-called "general instruction
extension facility". You might be lucky - that's one of the extensions
that can already be enabled for testing purposes with the "qemu" CPU:
Try to start QEMU with the "-cpu qemu,ginste=true" parameter.
If it then still complains about missing facilities, try "-cpu help" to
list all recognized feature flags.

The following features can already be enabled with the "qemu" CPU (list
has been copy-n-pasted from the sources, but I hope you'll be able to
map it to the output of "-cpu help", too):

S390_FEAT_DAT_ENH,
S390_FEAT_IDTE_SEGMENT,
S390_FEAT_STFLE,
S390_FEAT_EXTENDED_IMMEDIATE,
S390_FEAT_EXTENDED_TRANSLATION_2,
S390_FEAT_EXTENDED_TRANSLATION_3,
S390_FEAT_LONG_DISPLACEMENT,
S390_FEAT_LONG_DISPLACEMENT_FAST,
S390_FEAT_ETF2_ENH,
S390_FEAT_STORE_CLOCK_FAST,
S390_FEAT_MOVE_WITH_OPTIONAL_SPEC,
S390_FEAT_ETF3_ENH,
S390_FEAT_COMPARE_AND_SWAP_AND_STORE,
S390_FEAT_COMPARE_AND_SWAP_AND_STORE_2,
S390_FEAT_GENERAL_INSTRUCTIONS_EXT,
S390_FEAT_EXECUTE_EXT,
S390_FEAT_FLOATING_POINT_SUPPPORT_ENH,
S390_FEAT_STFLE_45,
S390_FEAT_STFLE_49,
S390_FEAT_LOCAL_TLB_CLEARING,
S390_FEAT_STFLE_53,

 HTH,
  Thomas

Re: [Qemu-discuss] Apple hyphervisor.framework availability

[Paolo Bonzini]

On 24/11/2017 12:58, Brendan Simon (eTRIX) wrote:
> 
> Checked out the `hvf` branch, but it failed the build.  Ran `mkdir build
> ; cd build ; ../configure ; make`
> 
> Am I missing some definitions or command line switches?

No, I've pushed an updated version.

Paolo

Re: [Qemu-discuss] Apple hyphervisor.framework availability

[Brendan Simon (eTRIX)]

On 23/11/17 11:06 pm, Paolo Bonzini wrote:

> On 23/11/2017 12:55, Thomas Huth wrote:
>> On 23.11.2017 08:36, Brendan Simon (eTRIX) wrote:
>>> Hi QEMU devs,
>>>
>>> Just wondering when the accelerator for Apple's hypervisor.framework
>>> (hvf) will hit the git repos to build and try out?
>>>
>>> I get the impression that patches have been submitted, but I can't see
>>> anything in the repos.  Is there a special branch or fork where these
>>> patches reside?
>> According to
>> https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg00415.html
>> there is a branch in Paolo's repository. hvf apparently hasn't been
>> merged into the upstream QEMU git repository yet.
> Right, more testing is welcome.

Checked out the `hvf` branch, but it failed the build.  Ran `mkdir build
; cd build ; ../configure ; make`

Am I missing some definitions or command line switches?


  CC  i386-softmmu/hw/misc/vmport.o
/Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:73:21: error: use
of undeclared identifier 'R_EAX'; did you mean
  'R_RAX'?
    eax = env->regs[R_EAX];
    ^
    R_RAX
/Users/brendan/Sandbox/qemu-bonzini/target/i386/cpu.h:63:5: note:
'R_RAX' declared here
    R_RAX = 0,
    ^
/Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:77:25: error: use
of undeclared identifier 'R_ECX'; did you mean
  'R_RCX'?
    command = env->regs[R_ECX];
    ^
    R_RCX
/Users/brendan/Sandbox/qemu-bonzini/target/i386/cpu.h:64:5: note:
'R_RCX' declared here
    R_RCX = 1,
    ^
/Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:96:19: error: use
of undeclared identifier 'R_EAX'; did you mean
  'R_RAX'?
    cpu->env.regs[R_EAX] = vmport_ioport_read(opaque, addr, 4);
  ^
  R_RAX
/Users/brendan/Sandbox/qemu-bonzini/target/i386/cpu.h:63:5: note:
'R_RAX' declared here
    R_RAX = 0,
    ^
/Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:103:19: error: use
of undeclared identifier 'R_EBX'; did you mean
  'R_RBX'?
    cpu->env.regs[R_EBX] = VMPORT_MAGIC;
  ^
  R_RBX
/Users/brendan/Sandbox/qemu-bonzini/target/i386/cpu.h:66:5: note:
'R_RBX' declared here
    R_RBX = 3,
    ^
/Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:111:19: error: use
of undeclared identifier 'R_EBX'; did you mean
  'R_RBX'?
    cpu->env.regs[R_EBX] = 0x1177;
  ^
  R_RBX
/Users/brendan/Sandbox/qemu-bonzini/target/i386/cpu.h:66:5: note:
'R_RBX' declared here
    R_RBX = 3,
    ^
/Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:121:25: error: use
of undeclared identifier 'R_EAX'; did you mean
  'R_RAX'?
    data[0] = env->regs[R_EAX]; data[1] = env->regs[R_EBX];
    ^
    R_RAX
/Users/brendan/Sandbox/qemu-bonzini/target/i386/cpu.h:63:5: note:
'R_RAX' declared here
    R_RAX = 0,
    ^
/Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:121:53: error: use
of undeclared identifier 'R_EBX'; did you mean
  'R_RBX'?
    data[0] = env->regs[R_EAX]; data[1] = env->regs[R_EBX];
    ^
    R_RBX
/Users/brendan/Sandbox/qemu-bonzini/target/i386/cpu.h:66:5: note:
'R_RBX' declared here
    R_RBX = 3,
    ^
/Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:122:25: error: use
of undeclared identifier 'R_ECX'; did you mean
  'R_RCX'?
    data[2] = env->regs[R_ECX]; data[3] = env->regs[R_EDX];
    ^
    R_RCX
/Users/brendan/Sandbox/qemu-bonzini/target/i386/cpu.h:64:5: note:
'R_RCX' declared here
    R_RCX = 1,
    ^
/Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:122:53: error: use
of undeclared identifier 'R_EDX'; did you mean
  'R_RDX'?
    data[2] = env->regs[R_ECX]; data[3] = env->regs[R_EDX];
    ^
    R_RDX
/Users/brendan/Sandbox/qemu-bonzini/target/i386/cpu.h:65:5: note:
'R_RDX' declared here
    R_RDX = 2,
    ^
/Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:123:25: error: use
of undeclared identifier 'R_ESI'
    data[4] = env->regs[R_ESI]; data[5] = env->regs[R_EDI];
    ^
/Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:123:53: error: use
of undeclared identifier 'R_EDI'; did you mean
  'R_RDI'?
    data[4] = env->regs[R_ESI]; data[5] = env->regs[R_EDI];
    ^
    R_RDI
/Users/brendan/Sandbox/qemu-bonzini/target/i386/cpu.h:70:5: note:
'R_RDI' declared here
    R_RDI = 7,
    ^
/Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:131:15: error: use
of undeclared identifier 'R_EAX'; did you mean
  'R_RAX'?
    env->regs[R_EAX] = data[0]; env->regs[R_EBX] = data[1];
  ^
  R_RAX

Re: [Qemu-discuss] s390x user-mode working example

[Alex Kashchenko]

On 11/24/2017 05:57 AM, Thomas Huth wrote:

On 23.11.2017 22:00, Alex Kashchenko wrote:

Hi,

I am trying to build qemu-s390x-user static binary to run a hello-world
program cross-compiled with gcc-s390x-linux-gnu on linux_x86_64.

I am building qemu with:

./configure --static --disable-werror --target-list=s390x-linux-user
make

and running example with:

QEMU_STRACE=1 ./s390x-linux-user/qemu-s390x path/to/s390x-hello

I tried latest git and a number of v2.x releases without success. Can
see either hang (on first brk call) or various errors for newer versions
and "Illegal instruction" for older ones. Tried on ubuntu 16.04 and
17.10 without success.

The same steps worked for me for ppc64le hello-world.

Any help on this is highly appreciated.


How did you cross-compile your s390x binary? QEMU's CPU emulation only
fully supports the z900 so far (more support is being worked on), so you
should make sure that your program has been compiled for that CPU
architecture, i.e. add "-m64 -march=z900" to your CFLAGS. Does that help?


Thanks for suggestion! I was cross-compiling the example using 
s390x-linux-gnu-gcc without additional flags, but it seems that 
march=z900 is a default for this gcc build. I was able to run simple 
example successfully (with git master build) after deleting 
/etc/ld.so.cache .


My ultimate goal was to cross-compile OpenJDK for s390x and run it 
locally with QEMU-user to be able to smoke-test s390x OpenJDK builds for 
fedora (I am using ubuntu for experiments because of very convenient 
multiarch support in it).


Unfortunately, I just found that OpenJDK's JIT requires newer 
instruction set than z900:


$ ./s390x-linux-user/qemu-s390x 
~/jdk9/build/linux-s390x-normal-server-release/images/jdk/bin/java -version

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (vm_version_s390.hpp:367), pid=26037, tid=26039
#  guarantee((_features[0] & GnrlInstrExtFacilityMask) == 
GnrlInstrExtFacilityMask) failed: We no more support older than z10.

#
# JRE version:  (9.0) (build )
# Java VM: OpenJDK 64-Bit Server VM (9-internal+0-adhoc.u1804.jdk9, 
mixed mode, tiered, compressed oops, g1 gc, linux-s390x)


--
-Alex

Re: [Qemu-discuss] s390x user-mode working example

[Alex Kashchenko]

On 11/24/2017 10:14 AM, Peter Maydell wrote:

On 23 November 2017 at 21:00, Alex Kashchenko  wrote:

Hi,

I am trying to build qemu-s390x-user static binary to run a hello-world
program cross-compiled with gcc-s390x-linux-gnu on linux_x86_64.

I am building qemu with:

./configure --static --disable-werror --target-list=s390x-linux-user
make

and running example with:

QEMU_STRACE=1 ./s390x-linux-user/qemu-s390x path/to/s390x-hello

I tried latest git and a number of v2.x releases without success. Can see
either hang (on first brk call) or various errors for newer versions and
"Illegal instruction" for older ones. Tried on ubuntu 16.04 and 17.10
without success.

The same steps worked for me for ppc64le hello-world.

Any help on this is highly appreciated.


Is your target binary statically linked? If not you'll need
to tell QEMU where the libraries are, or run it in a chroot
with the s390x libraries etc.


No, it is not statically linked, on ubuntu I am installing multiarch 
packet libc6:s390x (goes to /lib/s390x-linux-gnu/libc.so.6 ) for it as a 
dependency.



(You'll also need to make sure
it doesn't pick up the x86 /etc/ld.so.cache, because a glibc
bug means a bigendian dynamic linker crashes when it finds
a littleendian ld.so.cache, whereas same-endian-wrong-arch
just ignores it.)


That was it, on a git master build:

$ QEMU_STRACE=1 ./qemu/s390x-linux-user/qemu-s390x ./a.out
4654 brk(NULL) = 0x00403000
4654 uname(0x4000803102) = 0
4654 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or 
directory)
4654 
mmap(0x0040008030e8,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0x82a168) 
= 0x00400082b000
4654 access("/etc/ld.so.preload",R_OK) = -1 errno=2 (No such file or 
directory)

4654 open("/etc/ld.so.cache",O_RDONLY|O_CLOEXEC) = 3
4654 fstat(3,0x0040008027d0) = 0
4654 mmap(0x0040008026f8,25873,PROT_READ,MAP_PRIVATE,3,0x829098) = 
0x00400082d000

4654 close(3) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=1, si_addr=0x00409088d000} ---
Segmentation fault (core dumped)


Simple example now works fine for me if I delete /etc/ld.so.cache before 
running it.


Thanks for your help!

--
-Alex

Re: [Qemu-discuss] add tci module in android emulator

[Peter Maydell]

On 24 November 2017 at 07:21, jiang00gle  wrote:
> The Qemu is really a good project and the android emulator is
> based on the Qemu. But the version of Qemu in android 4.0 is 0.10
> which has no Tci module.
>
> So, is there any mature solution to add the tci module in emulator
> in Android 4.0 ?

This isn't really the right place to ask about the Android emulator:
it's a separate project that QEMU developers don't generally
have much knowledge of. However, why do you want to use TCI?
TCI is incredibly slow and doesn't really have any good uses
(as well as not actually being properly portable and needing
to be compiled into QEMU rather than being a runtime option);
we're thinking about deleting it upstream at some point.

thanks
-- PMM

Re: [Qemu-discuss] s390x user-mode working example

[Peter Maydell]

On 23 November 2017 at 21:00, Alex Kashchenko  wrote:
> Hi,
>
> I am trying to build qemu-s390x-user static binary to run a hello-world
> program cross-compiled with gcc-s390x-linux-gnu on linux_x86_64.
>
> I am building qemu with:
>
> ./configure --static --disable-werror --target-list=s390x-linux-user
> make
>
> and running example with:
>
> QEMU_STRACE=1 ./s390x-linux-user/qemu-s390x path/to/s390x-hello
>
> I tried latest git and a number of v2.x releases without success. Can see
> either hang (on first brk call) or various errors for newer versions and
> "Illegal instruction" for older ones. Tried on ubuntu 16.04 and 17.10
> without success.
>
> The same steps worked for me for ppc64le hello-world.
>
> Any help on this is highly appreciated.

Is your target binary statically linked? If not you'll need
to tell QEMU where the libraries are, or run it in a chroot
with the s390x libraries etc. (You'll also need to make sure
it doesn't pick up the x86 /etc/ld.so.cache, because a glibc
bug means a bigendian dynamic linker crashes when it finds
a littleendian ld.so.cache, whereas same-endian-wrong-arch
just ignores it.)

thanks
-- PMM