insane: Rationalise phdrs-based QA checks

Submitted by Phil Blundell on Oct. 15, 2012, 10:32 a.m.

Details

Message ID 1350297128.3259.132.camel@phil-desktop
State New
Headers show

Commit Message

Phil Blundell Oct. 15, 2012, 10:32 a.m.
On Sun, 2012-10-14 at 14:45 -0700, Saul Wold wrote:
> On 10/01/2012 10:29 AM, Phil Blundell wrote:
> > Various different QA checks are based on essentially the same data from
> > the ELF program headers.  Calling objdump to extract it repeatedly is
> > inefficient, particularly if the shell is involved.  Instead, let's
> > cache the output from objdump inside the qa.elf object and allow it to
> > be reused by multiple tests.
> >
> > Also, using objdump instead of scanelf to check for bad RPATHs (in the
> > same way that the useless-rpaths check was doing already) allows the
> > dependency on pax-utils-native to be dropped.
> >
> This seems to be failing for a QemuArm build of world, specifically 
> lsbsetup, quilt, sysvinit, and foomatic-filters seems like its failing 
> on symlinks.

I wasn't able to complete a build of world successfully due to some
unrelated-looking breakage in xserver-xorg, but I did reproduce this
problem by building quilt by hand.  The attached patch fixes it for me.

thanks

p.

Patch hide | download patch | download mbox

From 0aa4c262ded3e9d9da8293d899cd6ec28b4f60bb Mon Sep 17 00:00:00 2001
From: Phil Blundell <philb@gnu.org>
Date: Mon, 15 Oct 2012 11:28:00 +0100
Subject: [PATCH] insane: Don't try to run objdump on symlinks

If the link is absolute then we might end up reading from a host binary
or a nonexistent path, neither of which will produce useful results and
may result in objdump failure and python backtrace spew.  If the link
does point to a binary within the installation root then we will scan the
pointed-to file at some point anyway so there is no need to do it again.

Signed-off-by: Phil Blundell <pb@pbcl.net>
---
 meta/classes/insane.bbclass |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 2b48419..71a9a58 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -157,6 +157,9 @@  def package_qa_check_rpath(file,name, d, elf, messages):
     if not elf:
         return
 
+    if os.path.islink(file):
+        return
+
     bad_dirs = [d.getVar('TMPDIR', True) + "/work", d.getVar('STAGING_DIR_TARGET', True)]
     bad_dir_test = d.getVar('TMPDIR', True)
 
@@ -186,6 +189,9 @@  def package_qa_check_useless_rpaths(file, name, d, elf, messages):
     if not elf:
         return
 
+    if os.path.islink(file):
+        return
+
     libdir = d.getVar("libdir", True)
     base_libdir = d.getVar("base_libdir", True)
 
-- 
1.7.10.4


Comments

Saul Wold Oct. 16, 2012, 6:29 p.m.
On 10/15/2012 03:32 AM, Phil Blundell wrote:
> On Sun, 2012-10-14 at 14:45 -0700, Saul Wold wrote:
>> On 10/01/2012 10:29 AM, Phil Blundell wrote:
>>> Various different QA checks are based on essentially the same data from
>>> the ELF program headers.  Calling objdump to extract it repeatedly is
>>> inefficient, particularly if the shell is involved.  Instead, let's
>>> cache the output from objdump inside the qa.elf object and allow it to
>>> be reused by multiple tests.
>>>
>>> Also, using objdump instead of scanelf to check for bad RPATHs (in the
>>> same way that the useless-rpaths check was doing already) allows the
>>> dependency on pax-utils-native to be dropped.
>>>
>> This seems to be failing for a QemuArm build of world, specifically
>> lsbsetup, quilt, sysvinit, and foomatic-filters seems like its failing
>> on symlinks.
>
> I wasn't able to complete a build of world successfully due to some
> unrelated-looking breakage in xserver-xorg, but I did reproduce this
> problem by building quilt by hand.  The attached patch fixes it for me.
>
This is better, but I found another failure:

> ERROR: Error executing a python function in /intel/distro/meta/recipes-devtools/qemu/qemu_1.2.0.bb:
> ExecutionError: Execution of '/intel/poky/builds/world/tmp/sysroots/x86_64-linux/usr/bin/armv5te-poky-linux-gnueabi/arm-poky-linux-gnueabi-objdump -p /intel/poky/builds/world/tmp/work/armv5te-poky-linux-gnueabi/qemu-1.2.0-r3/packages-split/qemu/usr/share/qemu/palcode-clipper' failed with exit code 1:
> /intel/poky/builds/world/tmp/sysroots/x86_64-linux/usr/bin/armv5te-poky-linux-gnueabi/arm-poky-linux-gnueabi-objdump: /intel/poky/builds/world/tmp/work/armv5te-poky-linux-gnueabi/qemu-1.2.0-r3/packages-split/qemu/usr/share/qemu/palcode-clipper: File format not recognized
>

When I run file:
/intel/poky/builds/world/tmp/work/armv5te-poky-linux-gnueabi/qemu-1.2.0-r3/packages-split/qemu/usr/share/qemu/palcode-clipper: 
ELF 64-bit LSB executable, Alpha (unofficial), version 1 (SYSV), 
statically linked, not stripped

I was building qemuarm, but I had a done a qemuppc build earlier also.

Sau!

> thanks
>
> p.
>
Phil Blundell Oct. 16, 2012, 7:14 p.m.
On Tue, 2012-10-16 at 11:29 -0700, Saul Wold wrote:
> On 10/15/2012 03:32 AM, Phil Blundell wrote:
> > On Sun, 2012-10-14 at 14:45 -0700, Saul Wold wrote:
> >> On 10/01/2012 10:29 AM, Phil Blundell wrote:
> >>> Various different QA checks are based on essentially the same data from
> >>> the ELF program headers.  Calling objdump to extract it repeatedly is
> >>> inefficient, particularly if the shell is involved.  Instead, let's
> >>> cache the output from objdump inside the qa.elf object and allow it to
> >>> be reused by multiple tests.
> >>>
> >>> Also, using objdump instead of scanelf to check for bad RPATHs (in the
> >>> same way that the useless-rpaths check was doing already) allows the
> >>> dependency on pax-utils-native to be dropped.
> >>>
> >> This seems to be failing for a QemuArm build of world, specifically
> >> lsbsetup, quilt, sysvinit, and foomatic-filters seems like its failing
> >> on symlinks.
> >
> > I wasn't able to complete a build of world successfully due to some
> > unrelated-looking breakage in xserver-xorg, but I did reproduce this
> > problem by building quilt by hand.  The attached patch fixes it for me.
> >
> This is better, but I found another failure:
> 
> > ERROR: Error executing a python function in /intel/distro/meta/recipes-devtools/qemu/qemu_1.2.0.bb:
> > ExecutionError: Execution of '/intel/poky/builds/world/tmp/sysroots/x86_64-linux/usr/bin/armv5te-poky-linux-gnueabi/arm-poky-linux-gnueabi-objdump -p /intel/poky/builds/world/tmp/work/armv5te-poky-linux-gnueabi/qemu-1.2.0-r3/packages-split/qemu/usr/share/qemu/palcode-clipper' failed with exit code 1:
> > /intel/poky/builds/world/tmp/sysroots/x86_64-linux/usr/bin/armv5te-poky-linux-gnueabi/arm-poky-linux-gnueabi-objdump: /intel/poky/builds/world/tmp/work/armv5te-poky-linux-gnueabi/qemu-1.2.0-r3/packages-split/qemu/usr/share/qemu/palcode-clipper: File format not recognized
> >
> 
> When I run file:
> /intel/poky/builds/world/tmp/work/armv5te-poky-linux-gnueabi/qemu-1.2.0-r3/packages-split/qemu/usr/share/qemu/palcode-clipper: 
> ELF 64-bit LSB executable, Alpha (unofficial), version 1 (SYSV), 
> statically linked, not stripped
> 
> I was building qemuarm, but I had a done a qemuppc build earlier also.

Well, that's a bit weird.  It seems as though you have somehow gotten an
Alpha binary installed, which isn't appropriate for either qemuarm or
qemuppc.  In fact I don't think we support alpha in oe-core at all so
it's a bit of a mystery how it would have been built in the first place.

On the one hand, this is a genuine problem and it's good that the QA
check is diagnosing it.  On the other hand, it probably oughtn't to be
diagnosing it by means of an objdump failure (and I think there is
already a dedicated check for wrong ELF arch anyway).  So probably the
right thing to do is just trap exceptions around running objdump and
ignore any files that it doesn't understand.

p.