[PATCH v3] elf: Add DL_ADDRESS_WITHOUT_RELOC [BZ #33088]

H.J. Lu hjl.tools@gmail.com
Fri Jun 20 00:03:33 GMT 2025


On Fri, Jun 20, 2025 at 5:39 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Fri, Jun 20, 2025 at 1:38 AM Alexander Monakov <amonakov@ispras.ru> wrote:
> >
> >
> >
> > On Tue, 17 Jun 2025, H.J. Lu wrote:
> >
> > > On Mon, Jun 16, 2025 at 6:06 PM Florian Weimer <fweimer@redhat.com> wrote:
> > > >
> > > > * Alexander Monakov:
> > > >
> > > > > On Mon, 16 Jun 2025, Florian Weimer wrote:
> > > > >
> > > > >> * Alexander Monakov:
> > > > >>
> > > > >> > On Mon, 16 Jun 2025, Florian Weimer wrote:
> > > > >> >
> > > > >> >> > @@ -428,7 +429,7 @@ static ElfW(Addr) _dl_start_final (void *arg,
> > > > >> >> >
> > > > >> >> >  /* These are defined magically by the linker.  */
> > > > >> >> >  extern const ElfW(Ehdr) __ehdr_start attribute_hidden;
> > > > >> >> > -extern char _end[] attribute_hidden;
> > > > >> >> > +extern char _end attribute_hidden;
> > > > >> >>
> > > > >> >> Can you avoid this change (which may have unintended side effects on
> > > > >> >> other architectures) if you use
> > > > >> >>
> > > > >> >> > +  ({ __typeof (+var) _result = var; asm ("" : "+r"(_result)); _result; })
> > > > >> >>
> > > > >> >> in the definition of DL_ADDRESS_WITHOUT_RELOC?
> > > > >> >
> > > > >> > It won't work, but __auto_type, available since gcc-4.9 and clang-3.8,
> > > > >> > will:
> > > > >> >
> > > > >> >   __auto_type _result = val;
> > > > >> >
> > > > >> > or something like '__typeof(0 ? val : 0)' can be used for
> > > > >> > array-to-pointer decay inside of typeof.
> > > > >>
> > > > >> Why doesn't it work?  Shouldn't the + trigger decay from array to
> > > > >> pointer?
> > > > >
> > > > > In C++ it would, but not in C.
> > > >
> > > > Meh.  Awkward.
> > > >
> > > > >> Maybe it needs another one?
> > > > >
> > > > > Another plus?
> > > >
> > > > Yes, that's what I meant, but I was thinking about asm operand.
> > > >
> > > > But if we can use __auto_type, that's a fine solution.
> > > >
> > > > Thanks,
> > > > Florian
> > > >
> > >
> > > Here is the v3 patch with
> > >
> > > /* Evaluate EXPR without run-time relocation for it.  EXPR should be an
> > >    array, an address of an object, or a string literal.  */
> > > #define DL_ADDRESS_WITHOUT_RELOC(expr) \
> > >   ({ \
> > >      __typeof (*(expr)) *_result = (expr); \
> > >      asm ("" : "+r" (_result)); \
> > >      _result; \
> > >    })
> >
> > Can you reveal what issue came up with __auto_type when you tried it, please?
> >
> > (as an aside, we could use __typeof(val+0) for pointer decay here)
> >
> > As for this patch, the real requirement is that the argument to the macro
> > designates an address of a symbol that is reachable with PC-relative
> > addressing, i.e. an unnamed literal or an entity with hidden visibility.
> >
> > With that in mind, I think the macro argument is misnamed, and the comment is
> > inaccurate. Furthermore, I wonder if it wouldn't be cleaner to pass the symbol
> > as the macro argument, and take its address internally:
> >
> > /* Find the address of SYM in a manner that avoids creating a run-time
> >    relocation.  SYM should be reachable with PC-relative addressing, i.e.
> >    be an unnamed literal or an entity with hidden visibility.  */
> > #define DL_ADDRESS_WITHOUT_RELOC(sym) \
> >   ({ \
> >      __auto_type _result = &(sym);    \
> >      asm ("" : "+r" (_result));       \
> >      _result;                         \
> >   )}
>
> "__auto_type _result = &(sym);"  doesn't work with:
>
> +  _dl_rtld_map.l_map_start
> +    = (ElfW(Addr)) DL_ADDRESS_WITHOUT_RELOC (&__ehdr_start);
> +  _dl_rtld_map.l_map_end
> +    = (ElfW(Addr)) DL_ADDRESS_WITHOUT_RELOC (_end);
>
> I am testing this:
>
> /* Evaluate EXPR without run-time relocation for it.  EXPR should be an
>    array, an address of an object, or a string literal.  */
> #define DL_ADDRESS_WITHOUT_RELOC(expr) \
>   ({ \
>      __auto_type _result = (expr); \
>      asm ("" : "+r" (_result)); \
>      _result; \
>    })
>
>


Here is the v4 patch:

https://patchwork.sourceware.org/project/glibc/list/?series=48777

-- 
H.J.


More information about the Libc-alpha mailing list