Re: [PATCH] relocate_sdk.py: fix lib path error

[Laurentiu Palcu <laurentiu.palcu@intel.com>]

On Thu, Jun 12, 2014 at 06:14:46PM +0800, yzhu1 wrote:
> On 06/06/2014 08:22 PM, Khem Raj wrote:
> 
> 
> 
>     On Friday, June 6, 2014, <rongqing.li@windriver.com> wrote:
> 
>         From: yzhu1 <yanjun.zhu@windriver.com>
> 
>         In centos 5.9 32bit, ld lib does not contain some flags, so ld
>         lib is not parsed. So correct lib path is not got from ld lib.
> 
> 
>     Can you explain with examples what's going on here ?
> 
> Hi,
> 
> Before relocate_sdk.sh is executed, it needs the parameters: path/
> ld-linux-x86-64.so.2 path/dmesg.util-linux path/kill.util-linux path/
> reset.util-linux .....
> The file list (path/dmesg.util-linux path/kill.util-linux path/reset.util-linux
> .....) is collected by "grep '\(executable\|dynamically linked\)'".
> 
> So "dynamically linked" is very import to the file ld-linux-x86-64.so.2. But in
> redhat 5.9(32 bit)
> 
> This file is as below:
> 
> ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped
> 
> In Ubuntu 12.04 (64bit)
> 
> This file is as below:
> 
> ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically
> linked, BuildID[sha1]=0xbb8c5184d8d41f31093193a2ec8d3f6f10964cd2, stripped
> 
> In this case, we can find in Ubuntu 12.04(64 bit), the flag "dynamically
> linked" is present, so ld-linux-x86-64.so.2 can be included in the file list.
> relocate_sdk.py can work according to the information from
> ld-linux-x86-64.so.2. But in redhat 5.9(32bit), the flag does not exist.
> relocate_sdk.py can not get the information from ld-linux-x86-64.so.2 since
> this file is not included in the file list.
> 
> The same error occurs on redhat6.0(32 bit).
> 
> So the direct solution to this defect is to force this file
> ld-linux-x86-64.so.2 exist in file list.
> 
> If any problem, please feel free to let me know.

This looks like a 'file' display issue. It has nothing to do with the
dynamic loader itself. However, the dynamic loader is the reason you
spotted the problem because it wasn't relocated and all the other
dynamically linked binaries depend on it...

Originally, all executable files were selected no matter if they were
scripts or other non-elf files. The relocation script checked for the
ELF magic number anyway and it moved on if the file was not ELF
format.

But, the following commit added this 'file' dependency for detecting
executables:

commit 65535bff09afd21b6d9f129651df6c70570c3aa0
Author: yzhu1 <yanjun.zhu@windriver.com>
Date:   Tue Nov 26 08:38:28 2013 +0000

    populate_sdk: verify executable or dynamically linked library

My guess is that this commit was not the right fix for the problem it
describes. In fact, I just had a better look, and I spotted the problem
you were experiencing with empty files:

in scripts/relocate_sdk.py, in get_arch(), we check for the ELF magic
number and we do a read(16). Hence, if the file was zero sized, this
read would fail...

I suggest you add a check in relocate_sdk.py and make sure the file size is
bigger than the e_ident size (which is 16). Then, you can safely revert
65535bff09afd21b6d9f129651df6c70570c3aa0. Also, the current patch would no
longer be needed.

laurentiu