You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
The compiler may optimise away globals with debug offsets #129223
When compiling with LTO and other aggressive optimization levels, is possible that the compiler will optimise away globals containing debug offsets. This is currently happening in https://buildbot.python.org/#/builders/125/builds/6895 for the new AsyncioDebug section, making the test fail because the information is not burned in the binary.
IIUC, it's just that the compiler is not adding some additional information so, because of this additional information, the final binary changes a bit (perhaps the profile itself is changed). Hence the "tiny tiny" (ok, the wording was probably a poor wording). Sorry if I misunderstood what happened though!
IIUC, it's just that the compiler is not adding some additional information so, because of this additional information, the final binary changes a bit (perhaps the profile itself is changed). Hence the "tiny tiny" (ok, the wording was probably a poor wording). Sorry if I misunderstood what happened though!
Hummm, seems that I didn't explain myself correctly. Apologies!
So what's happening here is that we rely on a global variable compiled in a very specific way to be present in the asyncio module shared object. Unfortunately as nothing else is using the symbol that means that the compiler when using LTO is deciding that as nobody uses the symbol then is safe to remove. This means that the section is never burned into the final shared object and we cannot do the external inspection.
The fix doesn't have performance implications: is basically convincing the compiler to leave the global alone even if is not used anywhere apparently :)
Activity
picnixz commentedon Jan 23, 2025
(Tagging it as
performanceeven though it's probably a tiny tiny regression)pablogsal commentedon Jan 23, 2025
This is the fix of #124640 (comment)
What regression are you referring to?
picnixz commentedon Jan 23, 2025
IIUC, it's just that the compiler is not adding some additional information so, because of this additional information, the final binary changes a bit (perhaps the profile itself is changed). Hence the "tiny tiny" (ok, the wording was probably a poor wording). Sorry if I misunderstood what happened though!
pablogsal commentedon Jan 23, 2025
Hummm, seems that I didn't explain myself correctly. Apologies!
So what's happening here is that we rely on a global variable compiled in a very specific way to be present in the asyncio module shared object. Unfortunately as nothing else is using the symbol that means that the compiler when using LTO is deciding that as nobody uses the symbol then is safe to remove. This means that the section is never burned into the final shared object and we cannot do the external inspection.
The fix doesn't have performance implications: is basically convincing the compiler to leave the global alone even if is not used anywhere apparently :)
pythongh-129223: Do not allow the compiler to optimise away symbols f…
picnixz commentedon Jan 23, 2025
Oh that's not even an asyncio issue!
pythongh-129223: Do not allow the compiler to optimise away symbols f…
pythongh-129223: Do not allow the compiler to optimise away symbols f…
pythongh-129223: Do not allow the compiler to optimise away symbols f…
pythongh-129223: Do not allow the compiler to optimise away symbols f…
pythongh-129223: Do not allow the compiler to optimise away symbols f…
pythongh-129223: Do not allow the compiler to optimise away symbols f…
pythongh-129223: Do not allow the compiler to optimise away symbols f…
pythongh-129223: Raise KeyError in search_map_for_section() if not found
pythongh-129223: Raise KeyError in search_map_for_section() if not found
gh-129223: Do not allow the compiler to optimise away symbols for deb…
gh-129223: Raise KeyError in search_map_for_section() if not found (#…
vstinner commentedon Feb 13, 2025
Thanks for the fix!