This is an archive of the discontinued LLVM Phabricator instance.

[compiler-rt] [builtins] Remove unused/misnamed x86 chkstk functions
ClosedPublic

Authored by mstorsjo on Aug 29 2023, 2:12 PM.

Details

Summary

For both MSVC and MinGW targets, the compiler generates calls to
functions for probing the stack, in functions that allocate a larger
amount of stack space.

The exact behaviour of these functions differ per architecture (some
decrement the stack, some actually decrement the stack pointer,
some only probe the stack). In MSVC mode, the compiler always
generates calls to a symbol named "chkstk". In MinGW mode, the
symbol is named "
alloca" on i386 and "___chkstk_ms" on x86_64,
but the functions behave exactly the same as their MSVC counterparts
despite the differing names.

(On i386, these names are the raw symbol names - if considering
a C level function name with the extra implicit leading underscore,
they would be called "_chkstk" and "_alloca".)

Remove the misleading duplicate and unused functions. These were
added in fbfed869106cc9c9cad7538db5e65bcd24f4d92e /
c27de5b2790b65394c50ba13fab319995dbf5956 (adding "___chkstk_ms"
for both architectures, even if that symbol name only was used
on x86_64) and 40eb83ba56ba9c1d2e6de44deacf889ac0143cf7
(adding "alloca" and "_chkstk", even if the former only was
used on i386, and the latter seeming like a misspelled form of
the MSVC function, with three underscores instead of two).

The x86_64 "___chkstk" was doubly surprising as that function had
the same behaviour as the function used on i386, while the
"chkstk" that MSVC emitted calls to should behave exactly like
the preexisting "_
chkstk_ms".

Remove the unused functions, and rename the misspelled MSVC-like
symbols to the correct name that MSVC mode actually uses.

Note that these files aren't assembled at all when building
compiler-rt builtins in MSVC mode, as they are expected to be
provided by MSVC libraries when building code in MSVC mode.

The i386 chkstk2.S could be renamed to plain chkstk.S in a separate
commit (not including the change here, for clarity).

Diff Detail

Event Timeline

mstorsjo created this revision.Aug 29 2023, 2:12 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 29 2023, 2:12 PM
mstorsjo requested review of this revision.Aug 29 2023, 2:12 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 29 2023, 2:12 PM
Herald added a subscriber: Restricted Project. · View Herald Transcript
rnk accepted this revision.Aug 30 2023, 11:08 AM

lgtm

At various points I have tried to untangle the meaning, purpose, and function of these various stack adjustment routines, and I never felt like I had a satisfactory understanding. I trust that you got to the bottom of this.

This revision is now accepted and ready to land.Aug 30 2023, 11:08 AM

At various points I have tried to untangle the meaning, purpose, and function of these various stack adjustment routines, and I never felt like I had a satisfactory understanding. I trust that you got to the bottom of this.

I thought I did at least; it looked to me like over-genericity from when these functions were added in the linked commits. However I just happened to look at libgcc sources, and they also have these duplicate functions (i386/x86_64 versions of both functions, complete with the unused ___chkstk function name). So I guess the duplication and extra code stems from how they've come into place there, historically, even if not all of them actually are used. Anyway, for our purposes, I'd prefer to get rid of the unused/misleading ones, and concentrate on providing the exact ones that mingw and MSVC mode stack probes use, and nothing else.

rnk added a comment.Aug 31 2023, 9:11 AM

I think that's reasonable. libgcc probably retains them out of some desire for longer term backward compatibility, and I think we're a little less constrained there.

compiler-rt/lib/builtins/x86_64/chkstk.S