Bug 15122 - [2.17] Libraries in ld.so.cache ignored by ld-linux-armhf.so.3 on armv6l
Summary: [2.17] Libraries in ld.so.cache ignored by ld-linux-armhf.so.3 on armv6l
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: dynamic-link (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Wilhelm Eger
URL:
Keywords: glibc_2.17
Depends on:
Blocks:
 
Reported: 2013-02-08 17:31 UTC by Carlos O'Donell
Modified: 2014-06-13 18:52 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments
Patch (883 bytes, patch)
2013-04-29 20:26 UTC, Wilhelm Eger
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos O'Donell 2013-02-08 17:31:49 UTC
Backport fix for BZ15006.
Comment 1 Carlos O'Donell 2013-02-08 17:46:28 UTC
It has been requested that the patch for BZ15006 be packported to 2.17.

In progress...
Comment 2 Wilhelm Eger 2013-04-25 09:33:51 UTC
Hi there,

I think I am hit by this problem on Gentoo, see here:

https://forums.gentoo.org/viewtopic-t-957538.html

If you need help with testing, I would be more than happy to help you. Gentoo would make testing easy anyway. I tried to apply your patch from here:

http://sourceware.org/ml/libc-alpha/2013-02/msg00120.html

Altough it applied nicely to the glibc-2.17 source, it broke compilation.
Comment 3 Carlos O'Donell 2013-04-25 16:01:00 UTC
I've run out of time to backport this. I'm not currently working on this, but I plan to get back to it. I'm happy to have someone else do the backport of BZ15006 to the 2.17 branch.
Comment 4 Wilhelm Eger 2013-04-26 13:13:22 UTC
Unfortunately, I am not a real programmer. I can digg into code a little bit and I can patch, compile etc.

What would be necessary for backporting apart from the mentioned patch?
Comment 5 Carlos O'Donell 2013-04-26 15:53:13 UTC
(In reply to comment #4)
> Unfortunately, I am not a real programmer. I can digg into code a little bit
> and I can patch, compile etc.
> 
> What would be necessary for backporting apart from the mentioned patch?

Build and test glibc for ARM e.g. $SRC/configure; make; make -k check > check.log; grep 'Error' check.log; and make sure that the set of errors before and after the patch are the same.

That shows that your backport introduced no regressions.

Then attach the patch to this issue.

Does that help?

You can do some manual testing like this:
http://sourceware.org/glibc/wiki/Testing/Builds

You can also email libc-help@sourceware.org with problems you have building glibc for ARM.
Comment 6 Wilhelm Eger 2013-04-29 11:38:11 UTC
Well, I did the tests, compiled with and without patch applied with the following command:

mkdir build_XXX
cd build_XXX
../glibc_XXX/configure --prefix=/usr
LANG="C" make -j6 && make -k check > check.log 2>&1

The ouput of the grep command:

build_clean # grep Error check.log
make[2]: *** [/root/build_clean/math/test-fenv.out] Error 1
make[1]: *** [math/tests] Error 2
make[2]: [/root/build_clean/posix/annexc.out] Error 1 (ignored)
make[2]: [/root/build_clean/conform/run-conformtest.out] Error 1 (ignored)
make: *** [check] Error 2

build_patch # grep Error check.log
make[2]: *** [/root/build_patch/math/test-fenv.out] Error 1
make[1]: *** [math/tests] Error 2
make[2]: [/root/build_patch/posix/annexc.out] Error 1 (ignored)
make[2]: [/root/build_patch/conform/run-conformtest.out] Error 1 (ignored)
make: *** [check] Error 2

So no regression here.

From build_clean/chek.log

[...]
ISO...
ISO99...
  Total number of tests   : 2933
  Number of failed tests  :    6 ( <1%)
  Number of skipped tests :    0 (  0%)
ISO11...
  Total number of tests   : 3023
  Number of failed tests  :    8 ( <1%)
  Number of skipped tests :    2 ( <1%)
POSIX...
XPG3...
  Total number of tests   : 3993
  Number of failed tests  :  165 (  4%)
  Number of skipped tests :   89 (  2%)
XPG4...
  Total number of tests   : 4175
  Number of failed tests  :   26 ( <1%)
  Number of skipped tests :   10 ( <1%)
UNIX98...
  Total number of tests   : 4701
  Number of failed tests  :   13 ( <1%)
  Number of skipped tests :    6 ( <1%)
XOPEN2K...
  Total number of tests   : 6825
  Number of failed tests  :   16 ( <1%)
  Number of skipped tests :    5 ( <1%)
XOPEN2K8...
  Total number of tests   : 7083
  Number of failed tests  :   14 ( <1%)
  Number of skipped tests :    1 ( <1%)
POSIX2008...
  Total number of tests   : 6305
  Number of failed tests  :   11 ( <1%)
  Number of skipped tests :    0 (  0%)
[...]

and from build_patch/check.log

[...]
ISO...
ISO99...
  Total number of tests   : 2933
  Number of failed tests  :    6 ( <1%)
  Number of skipped tests :    0 (  0%)
ISO11...
  Total number of tests   : 3023
  Number of failed tests  :    8 ( <1%)
  Number of skipped tests :    2 ( <1%)
POSIX...
XPG3...
  Total number of tests   : 3993
  Number of failed tests  :  165 (  4%)
  Number of skipped tests :   89 (  2%)
XPG4...
  Total number of tests   : 4175
  Number of failed tests  :   26 ( <1%)
  Number of skipped tests :   10 ( <1%)
UNIX98...
  Total number of tests   : 4701
  Number of failed tests  :   13 ( <1%)
  Number of skipped tests :    6 ( <1%)
XOPEN2K...
  Total number of tests   : 6825
  Number of failed tests  :   16 ( <1%)
  Number of skipped tests :    5 ( <1%)
XOPEN2K8...
  Total number of tests   : 7083
  Number of failed tests  :   14 ( <1%)
  Number of skipped tests :    1 ( <1%)
POSIX2008...
  Total number of tests   : 6305
  Number of failed tests  :   11 ( <1%)
  Number of skipped tests :    0 (  0%)
[...]

So it looks good, doesn't it?
Comment 7 Carlos O'Donell 2013-04-29 14:47:00 UTC
(In reply to comment #6)
> build_patch # grep Error check.log
> make[2]: *** [/root/build_patch/math/test-fenv.out] Error 1

This test, while failing in both runs, may actually have a different number of failures internally.

> So it looks good, doesn't it?

Can you please compare the test-fenv.out output and make sure it's the same set of errors?

Otherwise your patch looks it hasn't regressed anything.

Can you confirm that the built glibc fixes your issues regarding ld.so.cache ignoring unmarked binaries?
Comment 8 Wilhelm Eger 2013-04-29 14:51:21 UTC
> Can you please compare the test-fenv.out output and make sure it's the same set
> of errors?

~ # diff -u ./build_patch/math/test-fenv.out ./build_clean/math/test-fenv.out
~ #

They are the same.
 
> Otherwise your patch looks it hasn't regressed anything.

Well, great, but it is actually your patch from the recent version. I haven't changed anything.
 
> Can you confirm that the built glibc fixes your issues regarding ld.so.cache
> ignoring unmarked binaries?

I have modified the glibc ebuild and am currently building it on my Gentoo box. After testing it, I will come back to you and let you know.
Comment 9 Carlos O'Donell 2013-04-29 14:58:00 UTC
(In reply to comment #8)
> > Can you please compare the test-fenv.out output and make sure it's the same set
> > of errors?
> 
> ~ # diff -u ./build_patch/math/test-fenv.out ./build_clean/math/test-fenv.out
> ~ #
> 
> They are the same.

Excellent.

> > Otherwise your patch looks it hasn't regressed anything.
> 
> Well, great, but it is actually your patch from the recent version. I haven't
> changed anything.

Thank you for your work. Nobody knew what, if anything, had to change for the backport to work.

You've just confirmed that it backports without any conflicts, requires no change, and introduces no regressions. 

That's quite a bit of work and so far you're doing great.

> > Can you confirm that the built glibc fixes your issues regarding ld.so.cache
> > ignoring unmarked binaries?
> 
> I have modified the glibc ebuild and am currently building it on my Gentoo box.
> After testing it, I will come back to you and let you know.

I look forward to signing off on your patch.

The last step is asking David Miller if we can install the patch.

David is the 2.17 release branch manager so he gets the last ack here.
Comment 10 Wilhelm Eger 2013-04-29 16:58:55 UTC
> I look forward to signing off on your patch.

I can confirm that the patch solved the ld.so.cache problems on my system.

System is: Unstable Gentoo, Odroid U2 (ARM Cortex A9), armv7a-hardfoat-linux-gnueabi, kernel 3.0.74

I will report this downstream as well. Thanks for your help and the patch. It is a great relief for me to have a working system again and it was a pleasure to work with you.
Comment 11 Wilhelm Eger 2013-04-29 19:12:50 UTC
Just saw that they confirmed it downstream independently as well:

https://bugs.gentoo.org/show_bug.cgi?id=454200
Comment 12 Carlos O'Donell 2013-04-29 19:20:31 UTC
(In reply to comment #10)
> > I look forward to signing off on your patch.
> 
> I can confirm that the patch solved the ld.so.cache problems on my system.
> 
> System is: Unstable Gentoo, Odroid U2 (ARM Cortex A9),
> armv7a-hardfoat-linux-gnueabi, kernel 3.0.74
> 
> I will report this downstream as well. Thanks for your help and the patch. It
> is a great relief for me to have a working system again and it was a pleasure
> to work with you.

Excellent. Could you please attach the patch to this issue?

I'll get Dave to ack it and then I'll check it in for you (or cherry-pick if the cherry-pick is identical).
Comment 13 Wilhelm Eger 2013-04-29 20:26:22 UTC
Created attachment 7008 [details]
Patch
Comment 14 David S. Miller 2013-04-29 21:04:25 UTC
I'm fine with this going into 2.17
Comment 15 Carlos O'Donell 2013-05-22 20:38:21 UTC
Fixed with:

commit 2b863a1b2dcbe2589d27646447d9ef88f9beffa5
Author: Wilhelm Eger <wilhelm.eger@googlemail.com>
Date:   Wed May 22 16:33:03 2013 -0400

    Backport fixes for BZ #15006 from master.
    
    Resolved backport request BZ #15122.
    
    Assume all unmarked objects are compatible with all ABI variants.
    Such objects may have been generated in a transitional period when
    ABI tags were not added to all objects.
    
    ---
    
    2013-02-08  Carlos O'Donell  <carlos@redhat.com>
    
        [BZ #15006]
        * sysdeps/generic/ldconfig.h: Define FLAG_ARM_LIBSF.
        * elf/cache.c (print_entry): Add FLAG_ARM_LIBSF support.
    
    ports/
    
    2013-02-08  Carlos O'Donell  <carlos@redhat.com>
    
        [BZ #15006]
        * sysdeps/unix/sysv/linux/arm/dl-cache.h
        [__ARM_PCS_VFP] (_dl_cache_check_flags): Allow plain FLAG_ELF_LIBC6.
        [!__ARM_PCS_VFP] (_dl_cache_check_flags): Likewise.
        * sysdeps/unix/sysv/linux/arm/readelflib.c (process_elf_file):
        Set FLAG_ARM_LIBSF for soft-float ABI otherwise just FLAG_ELF_LIBC6.