Bug 1473

Summary: Prelink causes x86 and qemuarm failures when built on 32bit system
Product: [Yocto Project Subprojects] Cross-prelink Reporter: Saul Wold <sgw>
Component: cross-prelinkAssignee: Mark Hatle <mark.hatle>
Status: RESOLVED FIXED QA Contact:
Severity: critical    
Priority: High CC: richard.purdie, sgw, yp.cp.watcher, yp.watcher
Version: unspecified   
Target Milestone: 1.1 M4   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: ---

Description Saul Wold 2011-09-13 07:18:20 UTC 
When prelinker is enable on 32bit host system, it fails to build correct images for qemux86 and qemuarm.

On qemux86, the image fails to boot with a segfault and kernel panic during the init phase.

Freeing unused kernel memory: 444k freed
usb 1-1: new full speed USB device number 2 using uhci_hcd
INIT: version 2.88 booting
init[1]: segfault at 38 ip 45a0a6c7 sp bfe15e6c error 4 in libc-2.13.so[45995000+15f000]
init[1]: segfault at 16 ip 0804b3c7 sp bfe15ae0 error 4 in init.sysvinit[8048000+7000]
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: init Not tainted 3.0.4-yocto-standard+ #1
Call Trace:
 [<c14e6933>] ? printk+0x1d/0x1f
 [<c14e6838>] panic+0x66/0x144
 [<c1036323>] do_exit+0x733/0x7f0
 [<c10366b4>] do_group_exit+0x34/0xa0
 [<c1044bd0>] get_signal_to_deliver+0x1e0/0x560
 [<c1001dbc>] do_signal+0x6c/0x860
 [<c14e6933>] ? printk+0x1d/0x1f
 [<c14e64be>] ? __bad_area_nosemaphore+0x111/0x120
 [<c14e651d>] ? bad_area+0x37/0x3d
 [<c14ee620>] ? spurious_fault+0xcd/0xcd
 [<c14eea36>] ? do_page_fault+0x416/0x490
 [<c10de31f>] ? vfs_read+0x11f/0x160
 [<c14ee620>] ? spurious_fault+0xcd/0xcd
 [<c10028c7>] do_notify_resume+0x77/0xa0
 [<c14ec4ca>] work_notifysig+0x13/0x19
 [<c14ee620>] ? spurious_fault+0xcd/0xcd
[sudo] password for sgw: 


For qemuarm, it hangs during pslplash before Sato starts.  I do not have more details on which process hangs at this point.

By disabling the prelink process, both pass these issues correctly.
Comment 1 Mark Hatle 2011-09-13 17:08:33 UTC 
I have a potential fix for this issue:


--- a/trunk/src/rtld/rtld.c
+++ b/trunk/src/rtld/rtld.c
@@ -1120,7 +1120,7 @@ process_one_dso (DSO *dso, int host_paths)
                   (size_t) (l->l_map_start - cur_dso_ent->dso->base));
 
           if (l->l_tls_modid)
-            printf (" TLS(0x%Zx, 0x%0*Zx)\n", l->l_tls_modid,
+            printf (" TLS(0x%Zx, 0x%0*Zx)\n", (size_t) l->l_tls_modid,
                     (int) size_pointer,
                     (size_t) l->l_tls_offset);
           else


Initial testing on 32-bit host, targeting x86 and arm targets is positive.
Comment 2 Mark Hatle 2011-09-16 09:01:12 UTC 
Change has been checked in, and appears to be working.