Simon McVittie <s...@debian.org> 于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