From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11876 invoked by alias); 1 Jul 2009 15:09:50 -0000 Received: (qmail 11858 invoked by uid 22791); 1 Jul 2009 15:09:49 -0000 X-SWARE-Spam-Status: No, hits=-0.3 required=5.0 tests=AWL,BAYES_00,SARE_BAYES_5x8,SARE_BAYES_6x8,SARE_BAYES_7x8 X-Spam-Check-By: sourceware.org Received: from eu1sys200aog108.obsmtp.com (HELO eu1sys200aog108.obsmtp.com) (207.126.144.125) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 01 Jul 2009 15:09:40 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob108.postini.com ([207.126.147.11]) with SMTP ID DSNKSkt8MGWGItnJHN/XU5ZECj3xGuWKMsBr@postini.com; Wed, 01 Jul 2009 15:09:39 UTC Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 81A07126 for ; Wed, 1 Jul 2009 15:09:36 +0000 (GMT) Received: from mail1.ctn.st.com (mail1.ctn.st.com [164.130.116.128]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 3AADF4C408 for ; Wed, 1 Jul 2009 15:09:36 +0000 (GMT) Received: from ctn000509 (mdt-dhcp26.ctn.st.com [10.52.139.26]) by mail1.ctn.st.com (MOS 3.8.7a) with ESMTP id DBQ84593 (AUTH arcidiaf); Wed, 1 Jul 2009 17:09:37 +0200 (CEST) From: Filippo ARCIDIACONO To: Subject: RE: [PATCH] Add TLS support for SH architecture. Date: Wed, 01 Jul 2009 15:09:00 -0000 Message-ID: <004901c9fa5d$f2cf1550$1a8b340a@st.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact prelink-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: prelink-owner@sourceware.org X-SW-Source: 2009-q3/txt/msg00002.txt.bz2 > -----Original Message----- > From: prelink-owner@sourceware.org > [mailto:prelink-owner@sourceware.org] On Behalf Of Jakub Jelinek > Sent: Wednesday, July 01, 2009 10:55 AM > To: Filippo ARCIDIACONO > Cc: prelink@sourceware.org > Subject: Re: [PATCH] Add TLS support for SH architecture. >=20 > On Wed, Jul 01, 2009 at 03:03:09AM -0400, Filippo ARCIDIACONO wrote: > > This patch extend the prelink tool also for sh architecture > adding the > > tls support, and fixes some architecture specific issue. > > The fix in the sh_undo_prelink_rela function is needed to > restore all > > the GOT entries to the original value. > > In the prelink stage GOT[1] has been set to the first plt > entry just > > after the plt header (This is the necessary code to jump at PLT[0]). > > To retrieve the other ones we need to add (28 * n) byte to > the first > > one, where n is the n-th entry of the PLTn (n =3D 0,1,2,...). > > The fix in src/dwarf2.c avoid assertion fail at line 808 for=20 > > layout[12], cxx[12] and undosyslibs tests. > >=20 > > --- a/src/dwarf2.c > > +++ b/src/dwarf2.c > > @@ -789,6 +789,13 @@ adjust_dwarf2_aranges (DSO *dso, > GElf_Addr start, GElf_Addr adjust) > > } > >=20=20 > > ptr +=3D 6; > > +#ifdef __SH4__ > > +/* > > + * This fix skips padding to avoid assertion fail at line 808 for > > + * layout[12], cxx[12] and undosyslibs tests. > > + */ > > + ptr +=3D 8; > > +#endif > > while (ptr < endcu) > > { > > addr =3D read_ptr (ptr); >=20 Hi Jakub, firstly thanks for reviewing this patch. > This change is not acceptable. Sometimes prelink is used as a cross=20 > tool, so host macros shouldn't make a difference on target behavior. You're right, indeed I did not think to prelink to be used as cross Tool; t= hat would be an interesting thing anyway. > Also, if you really need to skip another 8 bytes, it doesn't seem SH=20 > is using valid DWARF2/3 .debug_aranges, there really should be just 6=20 > bytes skipped here (one byte address_size, one byte segment_size, 4=20 > bytes padding to 16 byte boundary (the tuples are supposed to be=20 > aligned to twice the pointer > size) and the aranges entries start right after that. I don't see=20 > anything in GCC that would suggest SH is treated differently. >=20 I looked again at the test failure, indeed it seems the problem is in our l= ibstdc++, While all other DSOs have a valid dwarf2 .debug_aranges. Our libstdc++ .debug_aranges seems to be not valid. readelf --debug-dump=3Daranges ./libstdc++.so.6 The section .debug_aranges contains: Length: 1028=20 Version: 2=20=20=20=20 Offset into .debug_info: 0x0=20=20 Pointer Size: 4=20=20=20=20 Segment Size: 0=20=20=20=20 Address Length 00000000 00000000 <----- Spurious 8 bytes I skipped 319c7b00 00000020 319c7b20 00000020 319c7b40 00000054 319c7b94 00000040 319c7bd4 00000012 : : I'll have a look at binutils. So I agree with you to discard this part of t= he patch. > So, which compiler are you testing with, if it is not GCC, are you=20 > sure you aren't breaking prelink support for GCC on this arch? And in=20 > any case assembly output from the compiler with -dA for the=20 > .debug_aranges section to show what those 8 bytes are. >=20 > Also, I'd like to understand those other non-TLS non-testsuite=20 > changes, are you saying prelink as is never really worked on any SH,=20 > or just the SH variant you are testing on behaves differently from the=20 > one it has been used on before (my memory is weak, it has been many=20 > years, so I don't remember well who tested prelink on which of the=20 > embedded arches I didn't have any access to). Which other changes (other than dwarf2.c) are you referring to? >=20 > > --- a/testsuite/reloc8.sh > > +++ b/testsuite/reloc8.sh > > @@ -8,6 +8,9 @@ NOCOPYRELOC=3D-Wl,-z,nocopyreloc case "`uname -m`" in > > x86_64|s390*) if file reloc1lib1.so | grep -q 64-bit; then=20 > > NOCOPYRELOC=3D; fi;; esac > > +case "`uname -m`" in > > + sh4) NOCOPYRELOC=3D; > > +esac >=20 > This certainly should go into the same case, no need to call uname -m=20 > the second time. >=20 > > --- a/testsuite/reloc9.sh > > +++ b/testsuite/reloc9.sh > > @@ -8,6 +8,9 @@ NOCOPYRELOC=3D-Wl,-z,nocopyreloc case "`uname -m`" in > > x86_64|s390*) if file reloc1lib1.so | grep -q 64-bit; then=20 > > NOCOPYRELOC=3D; fi;; esac > > +case "`uname -m`" in > > + sh4) NOCOPYRELOC=3D; > > +esac I'll review both. >=20 > Likewise. >=20 > Jakub >=20 Regards, Filippo.