On Sun, 19 Oct 2026 09:53:02 -0400 Steven Rostedt <[email protected]> wrote: > This is not a fix. This is just passing a corrupt object file into the > build tooling and showing that it fails. > > Show me that this can be triggered by a legitimate object file and then I > would consider it. Otherwise, you are chasing made up bugs.
I cannot, so I am withdrawing it. The only way I reached that strcmp() was by writing 0x7ffffff0 into sh_name myself. I have no case where a compiler, assembler or linker produces an object whose sh_name points outside the name table, and I could not construct one from a truncated or interrupted build either -- a short .o fails earlier and differently. Without that, this is a check against a file that cannot get there, which is the "made up bug" you are describing. Please drop it. The same applies to the sorttable patch I sent alongside it (same shape, same hand-edited reproducer); I am withdrawing that one too and have said so in the cover-letter thread. For what it is worth, the one thing in this round that does not depend on a corrupt file is the undefined shift on e_type, which you were fine with, so I am sending only that as v2 and nothing else.
