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

Jan Beulich jbeulich@suse.com
Thu Apr 3 07:00:24 GMT 2025


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).

What I had been wondering already in the past is whether we shouldn't have
a mode where only plain-old-NOP would ever be emitted (unless "nop <opnd>"
is used explicitly, of course). That could then have been used as a
workaround here, until (as per the guess above) Nvidia would have fixed
their patching code.

Jan


More information about the Binutils mailing list