elf: sort tunables list from ld.so

elf: sort tunables list from ld.so

[DJ Delorie]

sort output from "ld.so --list-tunables"

diff --git a/elf/dl-tunables.c b/elf/dl-tunables.c
index 147cc4cf23..f79fa0827e 100644
--- a/elf/dl-tunables.c
+++ b/elf/dl-tunables.c
@@ -357,9 +357,28 @@ __tunables_init (char **envp)
 void
 __tunables_print (void)
 {
-  for (int i = 0; i < array_length (tunable_list); i++)
+  int i, j;
+  int sortmap [array_length (tunable_list)];
+
+  for (i = 0; i < array_length (tunable_list); i++)
+    sortmap [i] = i;
+  /* Quick bubble sort is sufficient.  */
+  for (i = 0; i < array_length (tunable_list) - 1; i++)
+    for (j = i+1; j < array_length (tunable_list); j++)
+      {
+	const char *ni = tunable_list[sortmap[i]].name;
+	const char *nj = tunable_list[sortmap[j]].name;
+	if (strcmp (ni, nj) > 0)
+	  {
+	    int t = sortmap[i];
+	    sortmap[i] = sortmap[j];
+	    sortmap[j] = t;
+	  }
+      }
+
+  for (i = 0; i < array_length (tunable_list); i++)
     {
-      const tunable_t *cur = &tunable_list[i];
+      const tunable_t *cur = &tunable_list[sortmap[i]];
       if (cur->type.type_code == TUNABLE_TYPE_STRING
 	  && cur->val.strval.str == NULL)
 	_dl_printf ("%s:\n", cur->name);

Re: elf: sort tunables list from ld.so

[DJ Delorie]

So this fails on 32-bit builds because "strcmp" can't be used as-is in
ld.so (er, sln/ldconfig at least), and dl-tunables.c is shared between
ld.so and libc.a

* I could add a local strcmp

* Maybe there's a #define or #include that auto-switches between the two

* __tunables_print() is only used by ld.so; it could be moved there or
  to a separate file

* drop the idea of sorting the printout :-P

Opinions?


gcc -m32 -o /build/elf/ldconfig -nostdlib -nostartfiles -static -static-pie -Wl,-z,pack-relative-relocs    /build/csu/rcrt1.o /build/csu/crti.o `gcc -m32  --print-file-name=crtbeginS.o` /build/elf/ldconfig.o /build/elf/cache.o /build/elf/chroot_canon.o /build/elf/readlib.o /build/elf/static-stubs.o /build/elf/stringtable.o /build/elf/xmalloc.o /build/elf/xstrdup.o   -Wl,--start-group /build/libc.a -lgcc  -Wl,--end-group `gcc -m32  --print-file-name=crtendS.o` /build/csu/crtn.o
/usr/bin/ld: /build/libc.a(dl-tunables.o): unsupported non-PIC call to IFUNC `strcmp'

Re: elf: sort tunables list from ld.so

[Andreas Schwab]

On Jun 07 2024, DJ Delorie wrote:

> /usr/bin/ld: /build/libc.a(dl-tunables.o): unsupported non-PIC call to IFUNC `strcmp'

Add sysdeps/i386/i686/multiarch/rtld-strcmp.c

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: elf: sort tunables list from ld.so

[Florian Weimer]

* DJ Delorie:

> So this fails on 32-bit builds because "strcmp" can't be used as-is in
> ld.so (er, sln/ldconfig at least), and dl-tunables.c is shared between
> ld.so and libc.a
>
> * I could add a local strcmp
>
> * Maybe there's a #define or #include that auto-switches between the two
>
> * __tunables_print() is only used by ld.so; it could be moved there or
>   to a separate file
>
> * drop the idea of sorting the printout :-P
>
> Opinions?

Can we sort during generation of dl-tunable_list.h?
It would fix bug 30027, too.

Thanks,
Florian

Re: elf: sort tunables list from ld.so

[DJ Delorie]

Florian Weimer <fweimer@redhat.com> writes:
> Can we sort during generation of dl-tunable_list.h?
> It would fix bug 30027, too.

It would also create an ongoing "we changed tunables id" situation, as
every new tunable would renumber other tunables.

But if awk is already doing that, sorting is at least predictable ;-)

Re: elf: sort tunables list from ld.so

[Florian Weimer]

* DJ Delorie:

> Florian Weimer <fweimer@redhat.com> writes:
>> Can we sort during generation of dl-tunable_list.h?
>> It would fix bug 30027, too.
>
> It would also create an ongoing "we changed tunables id" situation, as
> every new tunable would renumber other tunables.
>
> But if awk is already doing that, sorting is at least predictable ;-)

It's only doing that on hash resizing.

The other problem we have is that there is currently no way to signal a
missing tunable.

Thanks,
Florian