Re: prelink issue with ppc64?

[Mark Hatle <mark.hatle@windriver.com>]

On 8/4/11 9:03 AM, Kumar Gala wrote:
> 
> On Aug 4, 2011, at 12:37 AM, Kumar Gala wrote:
> 
>>
>> On Aug 3, 2011, at 10:09 AM, Mark Hatle wrote:
>>
>>> On 8/3/11 9:53 AM, Kumar Gala wrote:
>>>>
>>>> On Aug 3, 2011, at 9:37 AM, Mark Hatle wrote:
>>>>
>>>>> On 8/3/11 12:35 AM, Kumar Gala wrote:
>>>>>> If prelink gets a chance to properly run I get a rootfs that does:
>>>>>>
>>>>>> /sbin/init: relocation error: /lib64/libc.so.6: symbol _rtld_global_ro, version GLIBC_PRIVATE not defined in file ld64.so.1 with link time reference
>>>>>>
>>>>>> if 'baselib' is set to /lib we get:
>>>>>>
>>>>>> /local/home/galak/git/poky/build-p5020/tmp/sysroots/x86_64-linux/usr/sbin/prelink: /sbin/init.sysvinit: Using /lib/ld64.so.1, not /lib64/ld64.so.1 as dynamic linker
>>>>>>
>>>>>> if 'baselib' is set to /lib64 we get:
>>>>>>
>>>>>> Assigned virtual address space slots for libraries:
>>>>>> /lib64/ld64.so.1                                             00000080f4910000-00000080f49473d0
>>>>>> /lib64/libc.so.6                                             00000080f4950000-00000080f4afe090
>>>>>> /lib64/libdl.so.2                                            00000080f4b10000-00000080f4b23520
>>>>>> /lib64/libcrypt.so.1                                         00000080f4b10000-00000080f4b57708
>>>>>> /lib64/libutil.so.1                                          00000080f4b10000-00000080f4b234a0
>>>>>> Would prelink /lib64/ld-2.13.so
>>>>>> Would prelink /lib64/libc-2.13.so
>>>>>>
>>>>>> Not sure what prelink is doing but it seems to breaking things.  Any ideas?
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> I'm also concerned that we use /etc/prelink.conf when invoking prelink.
>>>>>
>>>>> Prelinker is being run within the rootfs, so the /etc/prelink.conf being used is
>>>>> the one inside of the image -- NOT the system version.
>>>>
>>>> Is this because of psuedo or something else?
>>>
>>> In the cross prelinker, we pass in the --root=<image>.  This instructs the
>>> cross-prelinker to prefix <image> to most paths.
>>>
>>>>> I would suspect that the cross-prelinker rtld emulation is likely setup for the
>>>>> LSB style library paths and may be causing some of the problems.
>>>
>>> You can run the cross-prelinker's rtld emulation by running the prelink-rtld
>>> program located in build/tmp-eglibc/work/x86_64-linux/usr/sbin/prelink-rtld
>>>
>>> Passing --root=<path> will setup the sysroot path for reference, adding in
>>> --target-paths will allow you to pass further arguments as referenced on the
>>> sysroot.
>>>
>>> So prelink-rtld --root=/foo/bar/build/sysroot/image --target-paths /sbin/init
>>>
>>> Should give you back an ldd like syntax within the sysroot, for /sbin/init.
>>> (without --target-paths, you need to specify the full path to the /sbin/init..
>>> this is useful when running the rtld against items outside of the image.)
>>>
>>>>>
>>>>> I'd suggest simply disabling prelink and getting everything to work first.. once
>>>>> it does we can work through any prelinker issues.  (Prelink on PPC64 hasn't been
>>>>> tested within the oe-core environment.. so it could very well have issues beyond
>>>>> the ld.so path.)
>>>>
>>>> Everything else is working, so prelink is what fails for me (at least for a simple minimal) build.
>>>>
>>>> any suggestions on how to try and debug further, who might be more familiar with prelink and what its doing?  When I ran readelf -a on ld-2.13.so after prelink was getting weird results, not sure if thats normal or not.
>>>
>>> I'm the prelink maintainer for Yocto, however I know more about the way the
>>> cross-prelinker functionality works then how the ELF specific prelink functions
>>> work.  I've been relying on the upstream prelink project to manage the
>>> individual architecture/ABI prelink standards.
>>>
>>> My suggestion is to disable cross-prelinking, and revert to the upstream prelink
>>> project -- run the binary on the target and see if it fails in the same way.  If
>>> it does, then we know it's a deeper problem then the cross prelink integration.
>>>
>>> You can pull down the git repository:  git://git.yoctoproject.org/prelink-cross.git
>>>
>>> The "master" branch is identical to the upstream SVN branch.  The
>>> "cross_prelink" branch is the current state of integration.
>>
>> So running prelink on target seems ok.  I used the version from prelink_git.bb.
>>
>> - k
> 
> I get the following output when running cross_prelink by hand:
> 
> prelink: /lib64/libc.so.6: Recorded 1 dependencies, now seeing -1
> 
> I noticed this as well (in dmesg):
> 
> prelink-rtld[14492]: segfault at 289986a94 ip 0000000000408de2 sp 00007fff65ad3c10 error 4 in prelink-rtld[400000+e000]

That could explain it..  interesting that prelink didn't see the failure.

I'd suggest running w/ -v and see if that will tell you what it was processing
at the time.  Also collect a core and run me a back trace.  (You should create a
bug on bugzilla.yoctoproject.org.. add that info and assign it to me..  I'll try
to reproduce it or at least trace through the code and see what may have lead to
the failure.)

--Mark

> - k