This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix lazy setting for PLTREL overlap cpus.


On Wed, Apr 4, 2012 at 12:17 AM, David Miller <davem@davemloft.net> wrote:
> From: "Carlos O'Donell" <carlos@systemhalted.org>
> Date: Wed, 4 Apr 2012 00:07:14 -0400
>
>> If on sparc32/sparc64 you have *never* had overlap then stop defining
>> ELF_MACHINE_PLTREL_OVERLAP at all and that's one less target to worry
>> about and one more step closer to the eventual removal of this code.
>
> I've always had overlap, and so does powerpc. ?For us the JMPREL
> always sits in last slots of the DT_REL(A). ?For example:
>
> davem@nunsaram:~/src$ readelf -d /lib/sparc-linux-gnu/libc.so.6
> ?...
> ?0x00000002 (PLTRELSZ) ? ? ? ? ? ? ? ? ? 204 (bytes)
> ?...
> ?0x00000017 (JMPREL) ? ? ? ? ? ? ? ? ? ? 0x203c0
> ?0x00000007 (RELA) ? ? ? ? ? ? ? ? ? ? ? 0x1517c
> ?0x00000008 (RELASZ) ? ? ? ? ? ? ? ? ? ? 45840 (bytes)
> ?...
>
> What I was saying is that I've never seen is the JMPREL being in the
> _middle_ of DT_REL(A), ie. having non-JMPREL entries both before
> and after the JMPREL ones.
>
> Ie. (JMPREL + PLTRELSZ) == (RELA + RELASZ)
>
> That's why I'm saying we don't need 3 ranges, but rather just 2.

Ah! I misread what you said. Yes, in that case, if we can *show* that
s390, power, and tile do the same then we can cleanup the code.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]