[PATCH v2 0/9] ld: Implement DT_RELR for x86

H.J. Lu hjl.tools@gmail.com
Thu Jan 13 03:00:28 GMT 2022


On Wed, Jan 12, 2022 at 6:54 PM Fangrui Song <i@maskray.me> wrote:
>
> On 2022-01-09, Alexander Monakov wrote:
> >On Sat, 8 Jan 2022, Fangrui Song wrote:
> >
> >> Thank you so much for the heroic work.
> >> I cannot think of other items.
> >
> >I am bummed that Rich Felker's solution for compatibility (sane diagnostic
> >for loading a new PIE/DSO with old ld.so) was not accepted:
> >https://sourceware.org/pipermail/libc-alpha/2021-November/133313.html
> >
> >(add just one new relocation to indicate presence of SHT_RELR)
> >
> >It would have been a nice solution that works the same across all OS'es,
> >without requiring changes in ld.so. Was there something wrong with it?
> >
> >Alexander
>
> Hi Alexander, I think the .gnu.version_r approach is better.
> For FreeBSD/musl/etc, there is no version node called GLIBC_2*,
> ld.bfd -z pack-relative-relocs will not add anything.
>
> For a relocation approach, every psABI needs to define which relocation
> type is used as the available indicator (something like
> R_*_GNU_VTENTRY). It's too much work for something only glibc needs.
>
>
>
> Now that the ld patch series has landed on
> https://sourceware.org/git/?p=binutils-gdb.git, what's the next step for the
> glibc patch? The current diff I have is
> https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/relr
> I think making ld.so/libc.so themselves compatible with DT_RELR can
> be separate changes (I personally do not know enough ld.so to contribute
> it...)

It is too late for glibc 2.35.  It should go in after 2.35 is branched.
My DT_RELR branch is based on your patch:

https://gitlab.com/x86-glibc/glibc/-/commits/users/hjl/relr/master

My branch requires -z pack-relative-relocs to enable DT_RELR
and supports zero DT_RELA/DT_REL values generated by ld.

-- 
H.J.


More information about the Libc-alpha mailing list