Le 04/12/2022 à 05:50, Fangrui Song a écrit : > On Mon, Nov 14, 2022 at 4:46 PM Fangrui Song <maskray@xxxxxxxxxx> wrote: >> >> On 2022-11-14, Christophe Leroy wrote: >>> >>> >>> Le 28/09/2022 à 07:25, Fangrui Song a écrit : >>>> On Sat, Sep 10, 2022 at 12:53 AM Fangrui Song <maskray@xxxxxxxxxx> wrote: >>>>> >>>>> On 2022-08-30, Fangrui Song wrote: >>>>>> The actual intention is that no dynamic relocation exists. However, some >>>>>> GNU ld ports produce unneeded R_*_NONE. (If a port is not care enough to >>>>>> determine the exact .rel[a].dyn size, the trailing zeros become R_*_NONE >>>>>> relocations. E.g. powerpc64le ld as of 2.38 has the issue with >>>>>> defconfig.) R_*_NONE are generally no-op in the dynamic loaders. So just >>>>>> ignore them. >>>>>> >>>>>> With the change, we can remove ARCH_REL_TYPE_ABS. ARCH_REL_TYPE_ABS is a >>>>>> bit misnomer as ports may check RELAVETIVE/GLOB_DAT/JUMP_SLOT which are >>>>>> not called "absolute relocations". (The patch is motivated by the arm64 >>>>>> port missing R_AARCH64_RELATIVE.) >>>>>> >>>>>> While here, replace "egrep" with "grep" as "egrep" is deprecated in GNU >>>>>> grep 3.7. >>>>>> >>>>>> Signed-off-by: Fangrui Song <maskray@xxxxxxxxxx> >>>>>> --- >>>>>> [...] >>>>>> >>>>> >>>>> Ping. >>>> >>>> Ping^2 :) >>> >>> Can you explain which ARCH_REL_TYPE_ABS can be removed with this change ? >>> How is the verification done if ARCH_REL_TYPE_ABS is removed ? >> >> All ARCH_REL_TYPE_ABS relocation types can be removed. As explained, the >> real intention is to check no dynamic relocation, and this is done by >> the new Well, there was a typo in my question, I wanted to ask 'why', not 'which'. >> >> cmd_vdso_check = if $(READELF) -rW $@ | grep -v _NONE | grep -q "R_\w*_"; \ >> >> in this patch. >> >> grep -v _NONE is to work around some GNU ld ports (and likely older releases >> of some ports even if their latest versions are fixed) which produce >> unneeded R_*_NONE dynamic relocations. > > Ping :) Ok, that seems to work on powerpc. Reviewed-by: Christophe Leroy <christophe.leroy@xxxxxxxxxx>