Re: Bug#1042980: gnome-shell: FTBFS on mips64el, mipsel: perf-* tests fail

Simon McVittie <[email protected]> 于2023年8月4日周五 19:26写道：
>
> Control: forwarded -1 https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6877
>
> On Fri, 04 Aug 2023 at 15:50:32 +0800, YunQiang Su wrote:
> > 156   if (rpath)
> > 157     paths = g_strsplit (strtab + rpath->d_un.d_val, ":", -1);
> > 158   else
> > 159     paths = g_strsplit (strtab + runpath->d_un.d_val, ":", -1);
> >      // <- segfault here due to
>
> Thanks, that's very useful information.
>
> After some printf debugging on eller, I think what is happening here is
> that GNOME Shell is assuming that the d_un.d_val of the DT_STRTAB is
> an absolute pointer, but on mips64el for whatever reason it's only an
> offset, and it needs to be added to the base address of the executable
> to get a real pointer.
>
> If I understand correctly, the value in the header in the binary on-disk
> is just an offset, and on most architectures the dynamic linker overwrites
> the offset with (base_address + offset) during loading/relocation - but
> for whatever reason, mips64el isn't doing that.
>

Yes. It is this case. I guess it should be a glibc's bug, while during years,
it is a feature now (;
We cannot change this behaviour now.

I am working on a patch for it, the real base address can be get by:
    ((getauxval(AT_PHDR) >> 8) <<8)

> Instead of doing this low-level ELF manipulation, I'm testing a patch which
> uses an environment variable to propagate the search path into the
> executable - that seems less likely to go wrong on unusual architectures.
>
>     smcv



-- 
YunQiang Su