[OE-core] [RFC] libgcrypt.so.20.0.1' has relocations in .text [textrel]
Andrea Adami
andrea.adami at gmail.com
Sat Jul 26 22:42:06 UTC 2014
On Sun, Jul 27, 2014 at 12:26 AM, Andrea Adami <andrea.adami at gmail.com> wrote:
> On Sat, Jul 26, 2014 at 11:30 PM, Andrea Adami <andrea.adami at gmail.com> wrote:
>> On Sat, Jul 26, 2014 at 6:33 PM, Khem Raj <raj.khem at gmail.com> wrote:
>>> On Fri, Jul 25, 2014 at 3:21 PM, Andrea Adami <andrea.adami at gmail.com> wrote:
>>>> Hi, somehow this QA is repeatedly here:
>>>>
>>>> andrea at mizar:/oe/oe-core/build$ bitbake core-image-base
>>>> Loading cache: 100% |###########################################| ETA: 00:00:00
>>>> Loaded 2519 entries from dependency cache.
>>>> Parsing recipes: 100% |#########################################| Time: 00:00:07
>>>> Parsing of 2066 .bb files complete (2065 cached, 1 parsed). 2519
>>>> targets, 115 skipped, 0 masked, 0 errors.
>>>> NOTE: Resolving any missing task queue dependencies
>>>>
>>>> Build Configuration:
>>>> BB_VERSION = "1.23.1"
>>>> BUILD_SYS = "x86_64-linux"
>>>> NATIVELSBSTRING = "Ubuntu-14.04"
>>>> TARGET_SYS = "arm-oe-linux-gnueabi"
>>>> MACHINE = "poodle"
>>>> DISTRO = "nodistro"
>>>> DISTRO_VERSION = "nodistro.0"
>>>> TUNE_FEATURES = "arm armv5 thumb dsp"
>>>> TARGET_FPU = "soft"
>>>> meta = "master:188545ba82119d75f80dde322a73712ce1f0f762"
>>>> meta-initramfs = "master:1060b4a157c5854f071f0dd7b48d55faeef3f818"
>>>> meta-handheld = "master:b61b450a0639aaac6f17ec4656950e28545c90e0"
>>>> meta-oe
>>>> meta-networking = "master:1060b4a157c5854f071f0dd7b48d55faeef3f818"
>>>> meta-opie = "master:369016695601cea46915fe47de1d86d31dd9acd7"
>>>>
>>>> NOTE: Preparing runqueue
>>>> NOTE: Executing SetScene Tasks
>>>> NOTE: Executing RunQueue Tasks
>>>> NOTE: validating kernel config, see log.do_kernel_configcheck for details
>>>> WARNING: QA Issue: ELF binary
>>>> '/oe/oe-core/build/tmp-eglibc/work/armv5te-oe-linux-gnueabi/libgcrypt/1.6.1-r0/packages-split/libgcrypt/usr/lib/libgcrypt.so.20.0.1'
>>>> has relocations in .text [textrel]
>>>> NOTE: Tasks Summary: Attempted 2368 tasks of which 1071 didn't need to
>>>> be rerun and all succeeded.
>>>>
>>>> A quick inspection of the configurations shows th elibs are compiled
>>>> -fPIC -DPIC so one common cause seems ruled out.
>>>>
>>>> But I'm confused after reading
>>>> http://lists.gnupg.org/pipermail/gnupg-devel/2014-January/028163.html
>>>>
>>>
>>> Generally you use -fpic thats sufficient and optimal in most cases and
>>> on most architectures, in some cases when GOT is really larger than
>>> ABI limits you can use -fPIC it makes difference on architectures like
>>> ppc
>>> where it will use 3 instructions to access larger GOT whereas -fpic
>>> will use 1 instruction.
>>>
>>> For this case it could be that there is some assembly file which is
>>> not getting the right flags, try adding --enable-noexecstack thru
>>> EXTRA_OECONF and see if that helps.
>>>
>>>
>>
>>
>> Thanks for the hint but that doesn't help.
>>
>> I think we have a bug in the check in insane.bbclass: it matches
>> TEXTREL 0x00000000
>> in the output of objdump -p
>>
>
> The check is valid!
> Seems there are problems with the sources:
>
> root at poodle:/# ./scanelf ./libgcrypt.so.20.0.1
> TYPE FILE
> ET_DYN ./libgcrypt.so.20.0.1
> root at poodle:/# ./scanelf -lpqt ./libgcrypt.so.20.0.1
> TEXTREL ./libgcrypt.so.20.0.1
> root at poodle:/# ./scanelf -qT ./libgcrypt.so.20.0.1
> libgcrypt.so.20.0.1: (memory/data?) [0x25D70] in (optimized out:
> previous $a) [0x25878]
> libgcrypt.so.20.0.1: (memory/data?) [0x26270] in (optimized out:
> previous _gcry_cast5_arm_decrypt_block) [0x25D78]
> libgcrypt.so.20.0.1: (memory/data?) [0x26B4C] in (optimized out:
> previous _gcry_cast5_arm_enc_blk2) [0x26278]
> libgcrypt.so.20.0.1: (memory/data?) [0x277E0] in (optimized out:
> previous _gcry_cast5_arm_dec_blk2) [0x26F10]
> libgcrypt.so.20.0.1: (memory/data?) [0x2CE18] in (optimized out:
> previous $a) [0x2C4B0]
> libgcrypt.so.20.0.1: (memory/data?) [0x2DFC0] in (optimized out:
> previous _gcry_aes_arm_decrypt_block) [0x2D658]
> libgcrypt.so.20.0.1: (memory/data?) [0x3F624] in (optimized out:
> previous $a) [0x3EA50]
> libgcrypt.so.20.0.1: (memory/data?) [0x4063C] in (optimized out:
> previous _gcry_camellia_arm_decrypt_block) [0x3FA70]
> ./libgcrypt.so.20.0.1
> root at poodle:/#
>
>
> Dissection with objdump:
>
> 00025878 <_gcry_cast5_arm_encrypt_block>:
> 25878: e92d5ff2 push {r1, r4, r5, r6, r7, r8, r9,
> sl, fp, ip, lr}
> 2587c: e59f74ec ldr r7, [pc, #1260] ; 25d70
> <_gcry_cast5_arm_encrypt_block+0x4f8>
> 25880: e3a0bfff mov fp, #1020 ; 0x3fc
>
>
> 00025d78 <_gcry_cast5_arm_decrypt_block>:
> 25d78: e92d5ff2 push {r1, r4, r5, r6, r7, r8, r9,
> sl, fp, ip, lr}
> 25d7c: e59f74ec ldr r7, [pc, #1260] ; 26270
> <_gcry_cast5_arm_decrypt_block+0x4f8>
> 25d80: e3a0bfff mov fp, #1020 ; 0x3fc
>
> 00026278 <_gcry_cast5_arm_enc_blk2>:
> 26278: e52de004 push {lr} ; (str lr, [sp, #-4]!)
> 2627c: e59f78c8 ldr r7, [pc, #2248] ; 26b4c
> <_gcry_cast5_arm_enc_blk2+0x8d4>
> 26280: e3a0bfff mov fp, #1020 ; 0x3fc
>
> 00026f10 <_gcry_cast5_arm_dec_blk2>:
> 26f10: e59f78c8 ldr r7, [pc, #2248] ; 277e0
> <_gcry_cast5_arm_dec_blk2+0x8d0>
> 26f14: e3a0bfff mov fp, #1020 ; 0x3fc
>
> 0002c4b0 <_gcry_aes_arm_encrypt_block>:
> 2c4b0: e92d5ff0 push {r4, r5, r6, r7, r8, r9, sl, fp, ip, lr}
> 2c4b4: e3120003 tst r2, #3
> 2c4b8: 0a00001c beq 2c530 <_gcry_aes_arm_encrypt_block+0x80>
> 2c4bc: e5d24000 ldrb r4, [r2]
>
> 0002d658 <_gcry_aes_arm_decrypt_block>:
> 2d658: e92d5ff0 push {r4, r5, r6, r7, r8, r9, sl, fp, ip, lr}
> 2d65c: e3120003 tst r2, #3
> 2d660: 0a00001c beq 2d6d8 <_gcry_aes_arm_decrypt_block+0x80>
>
> 0003ea50 <_gcry_camellia_arm_encrypt_block>:
> 3ea50: e92d5ff2 push {r1, r4, r5, r6, r7, r8, r9,
> sl, fp, ip, lr}
> 3ea54: e59fcbc8 ldr ip, [pc, #3016] ; 3f624
> <_gcry_camellia_arm_encrypt_block+0xbd4>
> 3ea58: e3a0e0ff mov lr, #255 ; 0xff
>
> 0003fa70 <_gcry_camellia_arm_decrypt_block>:
> 3fa70: e92d5ff2 push {r1, r4, r5, r6, r7, r8, r9,
> sl, fp, ip, lr}
> 3fa74: e59fcbc0 ldr ip, [pc, #3008] ; 4063c
> <_gcry_camellia_arm_decrypt_block+0xbcc>
> 3fa78: e3a0e0ff mov lr, #255 ; 0xff
>
>
> Any idea? Seems there is smthg wrong with cast5, aes, camellia
>
> Cheers
>
> Andrea
>
>
>
>> andrea at mizar:/oe/oe-core/build$ ./arm-oe-linux-gnueabi-objdump -p
>> ./libgcrypt.so.20.0.1
>>
>> ./libgcrypt.so.20.0.1: file format elf32-littlearm
>>
>> Program Header:
>> 0x70000001 off 0x00091450 vaddr 0x00091450 paddr 0x00091450 align 2**2
>> filesz 0x00000008 memsz 0x00000008 flags r--
>> LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**15
>> filesz 0x0009145c memsz 0x0009145c flags r-x
>> LOAD off 0x0009145c vaddr 0x0009945c paddr 0x0009945c align 2**15
>> filesz 0x00004618 memsz 0x00004904 flags rw-
>> DYNAMIC off 0x00091a28 vaddr 0x00099a28 paddr 0x00099a28 align 2**2
>> filesz 0x00000110 memsz 0x00000110 flags rw-
>> NOTE off 0x000000f4 vaddr 0x000000f4 paddr 0x000000f4 align 2**2
>> filesz 0x00000024 memsz 0x00000024 flags r--
>> STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**4
>> filesz 0x00000000 memsz 0x00000000 flags rwx
>>
>> Dynamic Section:
>> NEEDED libgpg-error.so.0
>> NEEDED libcap.so.2
>> NEEDED libc.so.6
>> SONAME libgcrypt.so.20
>> INIT 0x00004c00
>> FINI 0x00073660
>> INIT_ARRAY 0x0009945c
>> INIT_ARRAYSZ 0x00000004
>> FINI_ARRAY 0x00099460
>> FINI_ARRAYSZ 0x00000004
>> GNU_HASH 0x00000118
>> STRTAB 0x00001ce0
>> SYMTAB 0x00000b70
>> STRSZ 0x000010d7
>> SYMENT 0x00000010
>> PLTGOT 0x00099b38
>> PLTRELSZ 0x00000238
>> PLTREL 0x00000011
>> JMPREL 0x000049c8
>> REL 0x00003040
>> RELSZ 0x00001988
>> RELENT 0x00000008
>> TEXTREL 0x00000000
>> VERDEF 0x00002fe8
>> VERDEFNUM 0x00000002
>> VERNEED 0x00003020
>> VERNEEDNUM 0x00000001
>> VERSYM 0x00002db8
>> RELCOUNT 0x00000329
>>
>> Version definitions:
>> 1 0x01 0x0f84f3d0 libgcrypt.so.20
>> 2 0x00 0x0e5e9c66 GCRYPT_1.6
>>
>> Version References:
>> required from libc.so.6:
>> 0x0d696914 0x00 03 GLIBC_2.4
>> private flags = 5000202: [Version5 EABI] [soft-float ABI] [has entry point]
>>
>> andrea at mizar:/oe/oe-core/build$
>>
>>
>>
>>>> Worth opening a bug?
>>>>
>>>> Cheers
>>>>
>>>> Andrea
>>>> --
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core at lists.openembedded.org
>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
Seems fixed upstream
http://lists.gnupg.org/pipermail/gnupg-commits/2014-May/010496.html
Cheers
Andrea
More information about the Openembedded-core
mailing list