Continuing debugging the broken build, if we look at the first few
instructions of sha256_block_data_order:
0x004160c0 <+0>: subw r3, pc, #3
0x004160c4 <+4>: ldr.w r12, [pc, #-36] ; 0x4160a4
0x004160c8 <+8>: ldr.w r12, [r3, r12]
This looks similar to before - the intention being that %r3 is loaded
with the address of the start of the function, %r12 is loaded with the
offset of OPENSSL_armcap_P from the start of the function, then %r12 is
loaded with the value of OPENSSL_armcap_P.
However, the first instruction is broken - the #3 should be a #4.
Stepping past it produces this state:
(gdb) info registers
r0 0x4b7558 4945240
r1 0x4b7580 4945280
r2 0x1 1
r3 0x4160c1 4284609
r4 0x4b7558 4945240
r5 0xfffef44c 4294898764
r6 0x0 0
r7 0x4b7580 4945280
r8 0x3 3
r9 0xfffef44c 4294898764
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0xfffef3b8 0xfffef3b8
lr 0x414387 4277127
pc 0x4160c4 0x4160c4 <sha256_block_data_order+4>
cpsr 0x40080030 1074266160
(gdb) p sha256_block_data_order
$1 = {<text variable, no debug info>} 0x4160c0 <sha256_block_data_order>
Now, %r3 is the address of the start of the function, off-by-1.
Continuing to step through demonstrates that we load the wrong value in
to %r12, and this causes the non-NEON code path to be executed, which
somehow doesn't work.
If I step past these first 3 instructions, and then write the expected
value of OPENSSL_armcap_P in to %r12, the test completes successfully:
(gdb) info registers
r0 0x4b7558 4945240
r1 0x4b7580 4945280
r2 0x1 1
r3 0x4160c1 4284609
r4 0x4b7558 4945240
r5 0xfffef44c 4294898764
r6 0x0 0
r7 0x4b7580 4945280
r8 0x3 3
r9 0xfffef44c 4294898764
r10 0x0 0
r11 0x0 0
r12 0x1000000 16777216
sp 0xfffef3b8 0xfffef3b8
lr 0x414387 4277127
pc 0x4160cc 0x4160cc <sha256_block_data_order+12>
cpsr 0x40080030 1074266160
(gdb) set $r12 = 3
(gdb) info registers
r0 0x4b7558 4945240
r1 0x4b7580 4945280
r2 0x1 1
r3 0x4160c1 4284609
r4 0x4b7558 4945240
r5 0xfffef44c 4294898764
r6 0x0 0
r7 0x4b7580 4945280
r8 0x3 3
r9 0xfffef44c 4294898764
r10 0x0 0
r11 0x0 0
r12 0x3 3
sp 0xfffef3b8 0xfffef3b8
lr 0x414387 4277127
pc 0x4160cc 0x4160cc <sha256_block_data_order+12>
cpsr 0x40080030 1074266160
(gdb) cont
Continuing.
Testing SHA-256 .
Breakpoint 1, EVP_Digest (data=0x47f38c, count=56, md=0xfffef44c
"\272x\026\277\217\001\317\352AA@\336]\256\"#\260\003a\243\226\027z\234\264\020\377a\362",
size=0x0, type=0x4aff00 <sha256_md>, impl=0x0)
at digest.c:353
353 digest.c: No such file or directory.
(gdb)
Yay!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1729850
Title:
artful openssl FTBFS on armhf
Status in binutils package in Ubuntu:
New
Status in gcc-7 package in Ubuntu:
New
Status in openssl package in Ubuntu:
New
Bug description:
openssl FTBFS on artful armhf with the following:
../util/shlib_wrap.sh ./sha256t
Testing SHA-256
TEST 1 of 3 failed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1729850/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
