Re: [PATCH] linux-user,bsd-user: re-exec with G_SLICE=always-malloc

[Richard Henderson <richard.henderson@linaro.org>]

On 10/6/22 11:12, Daniel P. Berrangé wrote:
> On Tue, Oct 04, 2022 at 07:59:18AM -0700, Richard Henderson wrote:
>> On 10/4/22 05:00, Daniel P. Berrangé wrote:
>>> g_slice uses a one-time initializer to check the G_SLICE env variable
>>> making it hard for QEMU to set the env before any GLib API call has
>>> triggered the initializer. Even attribute((constructor)) is not
>>> sufficient as QEMU has many constructors and there is no ordering
>>> guarantee between them.
>>
>> There are orderings for constructors, see __attribute__((constructor(priority))).
> 
> Oh, thanks for pointing that out. I tried it, but glib threw
> a bag of rocks at me ;-P
> 
> The priority works for ordering within the scope of the binary
> containing the constructor.

Yes.

> 
> libglib.so itself has a constructor function registered, and that
> calls APIs that trigger GSlice initialization:

Ah.  I had been hoping that gslice would be initialized on first use, so as long as we 
could get the setenv done before any other qemu code ran, we'd be fine.

> This all takes place when libglib.so is loaded, which happens prior
> to any code in QEMU being loaded / executed. So no constructor in
> QEMU code can ever pre-empt this in dynamic builds.

Shared libraries have a defined initialization order too, but we'd have to play real 
irritating games to make this happen, installing a shared library of our own (linked later 
in the sequence to qemu, and itself *not* linked to libglib.so).  Not worth it.

> The only possible silver linining is that in static linked builds,
> it appears that a QEMU constructor with priority 101, will pre-empt
> the constructor from any library. This is kind of crazy, as it means
> if any library or app code uses priorities, it'll get totally different
> execution ordering depending on whether it is dynamic or statically
> built.

Plausible...

> I guess we could rely on this hack if we declare that everyone using
> binfmt is probably relying on static linked QEMU, and in non-binfmt
> cases people can set the env var themselves.  It still feels pretty
> dirty.

... but as you say, dirty.

Alternately, report it as a bug to glib, because we can't be the only project impacted by 
this.


r~