Re: Regression tests fail with musl libc because libpq.so can't be loaded

On Mon, Mar 18, 2024 at 10:34 PM Christophe Pettus <xof@thebuild.com> wrote:
> > On Mar 17, 2024, at 16:20, Thomas Munro <thomas.munro@gmail.com> wrote:
> > We'd
> > still feel free to clobber the memory up to that point (rather than
> > limiting ourselves to the argv space, another more conservative choice
> > that might truncate a few PS display messages, or maybe not given the
> > typical postmaster arguments, maye that'd work out OK), and we'd still
> > copy the environment to somewhere new, but anything like "LD_XXX" that
> > the runtime linker might have stashed a pointer to would remain valid.
> > /me runs away and hides
>
> It doesn't lack for bravery!  (And I have to just comment that the linker storing pointers into that space as a way of finding libraries... well, that doesn't get them the moral high ground for nasty hacks.)

FWIW here is a blind patch if someone wants to try it out... no musl here.

(Hmm, I think it's not that unreasonable on their part to assume the
initial environment is immutable if their implementation doesn't
mutate it, and our doing so is undeniably UB; surprising, maybe, given
that the technique works on that other popular brand of C library on
that kind of kernel, not to mention dozens of old Unixen of yore...
The real solution may turn out to be the prctl() described in that
thread, where you can tell the kernel where you're planning to move
your argv and it can find it to show ps/top, but I checked and you
still can't call that without special privileges, so maybe someone
should get onto complaining to kernel hackers about that?  That thread
is wrong about us clobbering auxv BTW, we're not animals!)