Patchwork eglibc: Fix for dynamic linker broken offset

login
register
mail settings
Submitter Andrei Dinu
Date Sept. 24, 2012, 11:26 a.m.
Message ID <1348485983-8294-1-git-send-email-andrei.adrianx.dinu@intel.com>
Download mbox | patch
Permalink /patch/37109/
State New
Headers show

Comments

Andrei Dinu - Sept. 24, 2012, 11:26 a.m.
Solution provided by Donn Seeley in bug 1443:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1443

worked when testing with core-image-sato-sdk for qemuarm.

[YOCTO #2577]

Signed-off-by: Andrei Dinu <andrei.adrianx.dinu@intel.com>
---
 .../eglibc-2.16/0001-R_ARM_TLS_DTPOFF32.patch      |   27 ++++++++++++++++++++
 meta/recipes-core/eglibc/eglibc_2.16.bb            |    3 ++-
 2 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-core/eglibc/eglibc-2.16/0001-R_ARM_TLS_DTPOFF32.patch
Phil Blundell - Sept. 24, 2012, 11:30 a.m.
On Mon, 2012-09-24 at 14:26 +0300, Andrei Dinu wrote:
> +-	    *reloc_addr += sym->st_value;
> ++	    *reloc_addr = sym->st_value;

That patch looks slightly dubious to me.  Are you sure this doesn't
introduce any regressions elsewhere?

p.
Andrei Dinu - Sept. 24, 2012, 12:40 p.m.
On 09/24/2012 02:30 PM, Phil Blundell wrote:
> On Mon, 2012-09-24 at 14:26 +0300, Andrei Dinu wrote:
>> +-	    *reloc_addr += sym->st_value;
>> ++	    *reloc_addr = sym->st_value;
> That patch looks slightly dubious to me.  Are you sure this doesn't
> introduce any regressions elsewhere?
>
> p.
>
>
I have insufficient data to affirm that it doesn't introduces regressions.

Regards,

Andrei Dinu
Saul Wold - Sept. 24, 2012, 2:34 p.m.
On 09/24/2012 04:26 AM, Andrei Dinu wrote:
> Solution provided by Donn Seeley in bug 1443:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1443
>
> worked when testing with core-image-sato-sdk for qemuarm.
>
> [YOCTO #2577]
>
> Signed-off-by: Andrei Dinu <andrei.adrianx.dinu@intel.com>
> ---
>   .../eglibc-2.16/0001-R_ARM_TLS_DTPOFF32.patch      |   27 ++++++++++++++++++++
>   meta/recipes-core/eglibc/eglibc_2.16.bb            |    3 ++-
>   2 files changed, 29 insertions(+), 1 deletion(-)
>   create mode 100644 meta/recipes-core/eglibc/eglibc-2.16/0001-R_ARM_TLS_DTPOFF32.patch
>
> diff --git a/meta/recipes-core/eglibc/eglibc-2.16/0001-R_ARM_TLS_DTPOFF32.patch b/meta/recipes-core/eglibc/eglibc-2.16/0001-R_ARM_TLS_DTPOFF32.patch
> new file mode 100644
> index 0000000..520c699
> --- /dev/null
> +++ b/meta/recipes-core/eglibc/eglibc-2.16/0001-R_ARM_TLS_DTPOFF32.patch
> @@ -0,0 +1,27 @@
> +Upstream-Status: Pending
> +
> +From 73890569c5048aef34d9a6f08907895a53211d72 Mon Sep 17 00:00:00 2001
> +From: Andrei Dinu <andrei.adrianx.dinu@intel.com>
> +Date: Mon, 24 Sep 2012 10:21:49 +0300
> +Subject: [PATCH] updated version
> +
You don't need this email headers here, but a better description of why 
would be good.

Sau!

> +Signed-off-by: Andrei Dinu <andrei.adrianx.dinu@intel.com>
> +---
> + .../libc/ports/sysdeps/arm/dl-machine.h            |    2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +ndex 8d905e8..dcfa71e 100644
> +--- libc.orig/ports/sysdeps/arm/dl-machine.h
> ++++ libc/ports/sysdeps/arm/dl-machine.h
> +@@ -503,7 +503,7 @@ elf_machine_rel (struct link_map *map, const Elf32_Rel *reloc,
> +
> + 	case R_ARM_TLS_DTPOFF32:
> + 	  if (sym != NULL)
> +-	    *reloc_addr += sym->st_value;
> ++	    *reloc_addr = sym->st_value;
> + 	  break;
> +
> + 	case R_ARM_TLS_TPOFF32:
> +--
> +1.7.9.5
> +
> diff --git a/meta/recipes-core/eglibc/eglibc_2.16.bb b/meta/recipes-core/eglibc/eglibc_2.16.bb
> index 78dc44a..b1f03c7 100644
> --- a/meta/recipes-core/eglibc/eglibc_2.16.bb
> +++ b/meta/recipes-core/eglibc/eglibc_2.16.bb
> @@ -3,7 +3,7 @@ require eglibc.inc
>   SRCREV = "20393"
>
>   DEPENDS += "gperf-native kconfig-frontends-native"
> -PR = "r9"
> +PR = "r10"
>   PR_append = "+svnr${SRCPV}"
>
>   EGLIBC_BRANCH="eglibc-2_16"
> @@ -29,6 +29,7 @@ SRC_URI = "svn://www.eglibc.org/svn/branches/;module=${EGLIBC_BRANCH};protocol=h
>              file://0001-eglibc-menuconfig-support.patch \
>              file://0002-eglibc-menuconfig-hex-string-options.patch \
>              file://0003-eglibc-menuconfig-build-instructions.patch \
> +           file://0001-R_ARM_TLS_DTPOFF32.patch \
>             "
>   LIC_FILES_CHKSUM = "file://LICENSES;md5=98a1128c4b58120182cbea3b1752d8b9 \
>         file://COPYING;md5=393a5ca445f6965873eca0259a17f833 \
>
Phil Blundell - Sept. 28, 2012, 9:52 a.m.
On Mon, 2012-09-24 at 15:40 +0300, Andrei Dinu wrote:
> On 09/24/2012 02:30 PM, Phil Blundell wrote:
> > On Mon, 2012-09-24 at 14:26 +0300, Andrei Dinu wrote:
> >> +-	    *reloc_addr += sym->st_value;
> >> ++	    *reloc_addr = sym->st_value;
> > That patch looks slightly dubious to me.  Are you sure this doesn't
> > introduce any regressions elsewhere?
> >
> >
> I have insufficient data to affirm that it doesn't introduces regressions.

Presumably it does at least pass the eglibc and binutils testsuites,
right?

p.
Mark Hatle - Sept. 28, 2012, 1:57 p.m.
On 9/28/12 4:52 AM, Phil Blundell wrote:
> On Mon, 2012-09-24 at 15:40 +0300, Andrei Dinu wrote:
>> On 09/24/2012 02:30 PM, Phil Blundell wrote:
>>> On Mon, 2012-09-24 at 14:26 +0300, Andrei Dinu wrote:
>>>> +-	    *reloc_addr += sym->st_value;
>>>> ++	    *reloc_addr = sym->st_value;
>>> That patch looks slightly dubious to me.  Are you sure this doesn't
>>> introduce any regressions elsewhere?
>>>
>>>
>> I have insufficient data to affirm that it doesn't introduces regressions.
>
> Presumably it does at least pass the eglibc and binutils testsuites,
> right?

That patch is a workaround for an ARM issue related to thread local storage and 
TLS offsets during runtime and prelinking.

See https://bugzilla.yoctoproject.org/show_bug.cgi?id=1443

Note, this is simply a workaround and not a final solution as it hasn't been 
vetted upstream.

--Mark

> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Khem Raj - Sept. 28, 2012, 2 p.m.
On Fri, Sep 28, 2012 at 6:57 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
> On 9/28/12 4:52 AM, Phil Blundell wrote:
>>
>> On Mon, 2012-09-24 at 15:40 +0300, Andrei Dinu wrote:
>>>
>>> On 09/24/2012 02:30 PM, Phil Blundell wrote:
>>>>
>>>> On Mon, 2012-09-24 at 14:26 +0300, Andrei Dinu wrote:
>>>>>
>>>>> +-          *reloc_addr += sym->st_value;
>>>>> ++          *reloc_addr = sym->st_value;
>>>>
>>>> That patch looks slightly dubious to me.  Are you sure this doesn't
>>>> introduce any regressions elsewhere?
>>>>
>>>>
>>> I have insufficient data to affirm that it doesn't introduces
>>> regressions.
>>
>>
>> Presumably it does at least pass the eglibc and binutils testsuites,
>> right?
>
>
> That patch is a workaround for an ARM issue related to thread local storage
> and TLS offsets during runtime and prelinking.
>
> See https://bugzilla.yoctoproject.org/show_bug.cgi?id=1443
>
> Note, this is simply a workaround and not a final solution as it hasn't been
> vetted upstream.

Thats ok however we do have infra to run eglibc testsuite in cross env
so if that was done would have answered Phil's question

http://sakrah.dontexist.org/?p=6

>
> --Mark
>
>
>> p.
>>
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Phil Blundell - Sept. 28, 2012, 2:02 p.m.
On Fri, 2012-09-28 at 08:57 -0500, Mark Hatle wrote:
> On 9/28/12 4:52 AM, Phil Blundell wrote:
> > On Mon, 2012-09-24 at 15:40 +0300, Andrei Dinu wrote:
> >> On 09/24/2012 02:30 PM, Phil Blundell wrote:
> >>> On Mon, 2012-09-24 at 14:26 +0300, Andrei Dinu wrote:
> >>>> +-	    *reloc_addr += sym->st_value;
> >>>> ++	    *reloc_addr = sym->st_value;
> >>> That patch looks slightly dubious to me.  Are you sure this doesn't
> >>> introduce any regressions elsewhere?
> >>>
> >> I have insufficient data to affirm that it doesn't introduces regressions.
> >
> > Presumably it does at least pass the eglibc and binutils testsuites,
> > right?
> 
> That patch is a workaround for an ARM issue related to thread local storage and 
> TLS offsets during runtime and prelinking.
> 
> See https://bugzilla.yoctoproject.org/show_bug.cgi?id=1443
> 
> Note, this is simply a workaround and not a final solution as it hasn't been 
> vetted upstream.

Right, I understand that.  But this doesn't really answer the question
"does the workaround break anything else?".

p.
Mark Hatle - Sept. 28, 2012, 2:35 p.m.
On 9/28/12 9:02 AM, Phil Blundell wrote:
> On Fri, 2012-09-28 at 08:57 -0500, Mark Hatle wrote:
>> On 9/28/12 4:52 AM, Phil Blundell wrote:
>>> On Mon, 2012-09-24 at 15:40 +0300, Andrei Dinu wrote:
>>>> On 09/24/2012 02:30 PM, Phil Blundell wrote:
>>>>> On Mon, 2012-09-24 at 14:26 +0300, Andrei Dinu wrote:
>>>>>> +-	    *reloc_addr += sym->st_value;
>>>>>> ++	    *reloc_addr = sym->st_value;
>>>>> That patch looks slightly dubious to me.  Are you sure this doesn't
>>>>> introduce any regressions elsewhere?
>>>>>
>>>> I have insufficient data to affirm that it doesn't introduces regressions.
>>>
>>> Presumably it does at least pass the eglibc and binutils testsuites,
>>> right?
>>
>> That patch is a workaround for an ARM issue related to thread local storage and
>> TLS offsets during runtime and prelinking.
>>
>> See https://bugzilla.yoctoproject.org/show_bug.cgi?id=1443
>>
>> Note, this is simply a workaround and not a final solution as it hasn't been
>> vetted upstream.
>
> Right, I understand that.  But this doesn't really answer the question
> "does the workaround break anything else?".

In my testing no.  But I never integrated it with OE, so I never ran the test 
suite Khem was referring to.

--Mark

> p.
>
>
Khem Raj - Sept. 28, 2012, 2:50 p.m.
On Sep 28, 2012, at 7:35 AM, Mark Hatle <mark.hatle@windriver.com> wrote:

> In my testing no.  But I never integrated it with OE, so I never ran the test suite Khem was referring to.

anyhow provided I have time I will try to run regressions on beagle bone and see what I get.
Phil Blundell - Sept. 28, 2012, 2:57 p.m.
On Fri, 2012-09-28 at 09:35 -0500, Mark Hatle wrote:
> On 9/28/12 9:02 AM, Phil Blundell wrote:
> > On Fri, 2012-09-28 at 08:57 -0500, Mark Hatle wrote:
> >> On 9/28/12 4:52 AM, Phil Blundell wrote:
> >>> On Mon, 2012-09-24 at 15:40 +0300, Andrei Dinu wrote:
> >>>> On 09/24/2012 02:30 PM, Phil Blundell wrote:
> >>>>> On Mon, 2012-09-24 at 14:26 +0300, Andrei Dinu wrote:
> >>>>>> +-	    *reloc_addr += sym->st_value;
> >>>>>> ++	    *reloc_addr = sym->st_value;
> >>>>> That patch looks slightly dubious to me.  Are you sure this doesn't
> >>>>> introduce any regressions elsewhere?
> >>>>>
> >>>> I have insufficient data to affirm that it doesn't introduces regressions.
> >>>
> >>> Presumably it does at least pass the eglibc and binutils testsuites,
> >>> right?
> >>
> >> That patch is a workaround for an ARM issue related to thread local storage and
> >> TLS offsets during runtime and prelinking.
> >
> > Right, I understand that.  But this doesn't really answer the question
> > "does the workaround break anything else?".
> 
> In my testing no.  But I never integrated it with OE, so I never ran the test 
> suite Khem was referring to.

I think the testsuite Khem mentioned is just eglibc's builtin tests; it
isn't actually specific to OE.  What did your testing consist of?

p.
Mark Hatle - Sept. 28, 2012, 3:02 p.m.
On 9/28/12 9:57 AM, Phil Blundell wrote:
> On Fri, 2012-09-28 at 09:35 -0500, Mark Hatle wrote:
>> On 9/28/12 9:02 AM, Phil Blundell wrote:
>>> On Fri, 2012-09-28 at 08:57 -0500, Mark Hatle wrote:
>>>> On 9/28/12 4:52 AM, Phil Blundell wrote:
>>>>> On Mon, 2012-09-24 at 15:40 +0300, Andrei Dinu wrote:
>>>>>> On 09/24/2012 02:30 PM, Phil Blundell wrote:
>>>>>>> On Mon, 2012-09-24 at 14:26 +0300, Andrei Dinu wrote:
>>>>>>>> +-	    *reloc_addr += sym->st_value;
>>>>>>>> ++	    *reloc_addr = sym->st_value;
>>>>>>> That patch looks slightly dubious to me.  Are you sure this doesn't
>>>>>>> introduce any regressions elsewhere?
>>>>>>>
>>>>>> I have insufficient data to affirm that it doesn't introduces regressions.
>>>>>
>>>>> Presumably it does at least pass the eglibc and binutils testsuites,
>>>>> right?
>>>>
>>>> That patch is a workaround for an ARM issue related to thread local storage and
>>>> TLS offsets during runtime and prelinking.
>>>
>>> Right, I understand that.  But this doesn't really answer the question
>>> "does the workaround break anything else?".
>>
>> In my testing no.  But I never integrated it with OE, so I never ran the test
>> suite Khem was referring to.
>
> I think the testsuite Khem mentioned is just eglibc's builtin tests; it
> isn't actually specific to OE.  What did your testing consist of?
>

We have a battery of application tests which more or less consist of running all 
of the binaries on the system and looking for minimal reasonable behavior for 
each.  (Other apps get more exhaustive testing of course.)

Also the reported case of libust/librcu was verified as well.

I'm not sure if it was run, but typically we also run the LTP test suite and LSB 
test suite..  (but I didn't personally use it.)

--Mark

> p.
>
>
Phil Blundell - Oct. 2, 2012, 4:50 p.m.
On Fri, 2012-09-28 at 15:34 +0300, Andrei Dinu wrote:
> > Presumably it does at least pass the eglibc and binutils testsuites,
> > right?
> >
> Can u give me a location where i can find these test suites and how can 
> i run them?

They're included in the eglibc and binutils distributions.  I think Khem
posted a recipe for running the tests under qemu fairly recently, or you
could run them on the target directly.

p.

Patch

diff --git a/meta/recipes-core/eglibc/eglibc-2.16/0001-R_ARM_TLS_DTPOFF32.patch b/meta/recipes-core/eglibc/eglibc-2.16/0001-R_ARM_TLS_DTPOFF32.patch
new file mode 100644
index 0000000..520c699
--- /dev/null
+++ b/meta/recipes-core/eglibc/eglibc-2.16/0001-R_ARM_TLS_DTPOFF32.patch
@@ -0,0 +1,27 @@ 
+Upstream-Status: Pending
+
+From 73890569c5048aef34d9a6f08907895a53211d72 Mon Sep 17 00:00:00 2001
+From: Andrei Dinu <andrei.adrianx.dinu@intel.com>
+Date: Mon, 24 Sep 2012 10:21:49 +0300
+Subject: [PATCH] updated version
+
+Signed-off-by: Andrei Dinu <andrei.adrianx.dinu@intel.com>
+---
+ .../libc/ports/sysdeps/arm/dl-machine.h            |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+ndex 8d905e8..dcfa71e 100644
+--- libc.orig/ports/sysdeps/arm/dl-machine.h
++++ libc/ports/sysdeps/arm/dl-machine.h
+@@ -503,7 +503,7 @@ elf_machine_rel (struct link_map *map, const Elf32_Rel *reloc,
+ 
+ 	case R_ARM_TLS_DTPOFF32:
+ 	  if (sym != NULL)
+-	    *reloc_addr += sym->st_value;
++	    *reloc_addr = sym->st_value;
+ 	  break;
+ 
+ 	case R_ARM_TLS_TPOFF32:
+-- 
+1.7.9.5
+
diff --git a/meta/recipes-core/eglibc/eglibc_2.16.bb b/meta/recipes-core/eglibc/eglibc_2.16.bb
index 78dc44a..b1f03c7 100644
--- a/meta/recipes-core/eglibc/eglibc_2.16.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.16.bb
@@ -3,7 +3,7 @@  require eglibc.inc
 SRCREV = "20393"
 
 DEPENDS += "gperf-native kconfig-frontends-native"
-PR = "r9"
+PR = "r10"
 PR_append = "+svnr${SRCPV}"
 
 EGLIBC_BRANCH="eglibc-2_16"
@@ -29,6 +29,7 @@  SRC_URI = "svn://www.eglibc.org/svn/branches/;module=${EGLIBC_BRANCH};protocol=h
            file://0001-eglibc-menuconfig-support.patch \
            file://0002-eglibc-menuconfig-hex-string-options.patch \
            file://0003-eglibc-menuconfig-build-instructions.patch \
+           file://0001-R_ARM_TLS_DTPOFF32.patch \
           "
 LIC_FILES_CHKSUM = "file://LICENSES;md5=98a1128c4b58120182cbea3b1752d8b9 \
       file://COPYING;md5=393a5ca445f6965873eca0259a17f833 \