[PATCH 08/11] x86: add a few more NOP patterns

[Florian Weimer]

* Jan Beulich:

> On 03.04.2025 07:34, Florian Weimer wrote:
>> * Jan Beulich via Binutils:
>> 
>>> First of all add f32_5[], allowing to eliminate the extra slot-is-NULL
>>> code from i386_output_nops(). Plus then introduce f32_8[] and f16_5[]
>>> following the same concept of adding a %cs segment override prefix.
>>>
>>> Also re-use patterns when possible and correct comments as applicable.
>>> Similarly re-use testcase expectations as much as possible, where they
>>> need touching anyway.
>>> ---
>>> The x86-64-nops-5* tests are kind of bogus: The source file has .code32
>>> almost first thing, and hence there's no real 64-bit testing there. We
>>> could likely as well delete them, rather than fiddling with them here.
>> 
>> This change has been associated with a crash in the Nvidia drivers.  It
>> seems that if glibc is built with this, the Nvidia driver is no longer
>> able to find the right place to patch in _dl_debug_update:
>> 
>> <https://bugzilla.redhat.com/show_bug.cgi?id=2357062#c5>
>> <https://forums.developer.nvidia.com/t/slackware64-current-multilib-after-update-to-glibc-2-39-32-bit-glx-programs-segfault/281769/3>
>> 
>> Not sure if there's anything we can do about this.
>
> I don't think reverting makes sense, which is about the only thing I can
> think of as on option on our side. There's hardly any technical detail in
> that report, so I can only guess that the patching logic you mention
> looks for only a subset of all possible NOP patterns. (They may not like
> the %cs: overrides on LEA?) Imo it should be entirely at the discretion of
> the assembler which particular NOP patterns to use, so long as they're
> okay execution-wise (i.e. wouldn't fault, and wouldn't alter machine state
> other than updating %eip).

It's also not something that we can easily fix during the glibc build
because we don't know what the patching code is looking for.  This isn't
even assembler code, so what we get in the binary also depends on the
compiler and the build flags used.

Alexander Monakov has suggested it's actually _dl_debug_state.  That
would be a bit disappointing because we deliberately build with
Systemtap probes and ship with debugging information, to make such
introspection easier (but we certainly didn't expect code patching like
this).

Thanks,
Florian