https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107779
Bug ID: 107779 Summary: Support implicit references from inline assembler to compiler symbols Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: andi-gcc at firstfloor dot org CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org, mliska at suse dot cz Target Milestone: --- Created attachment 53933 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53933&action=edit prototype patch So I looked into the problem the kernel people complained about: a lot of assembler statements reference C symbols, which need externally_visible and global for gcc LTO, otherwise they can end up in the wrong asm file and cause missing symbols. I came up with the attached (hackish) patch that tries to solve the problem very partially: it parses the assembler strings and looks for anything that could be an identifier, and then tries to mark it externally_visible. It has the following open issues: - The parsing is very approximate and doesn't handle some obscure cases. With the approximation it's also impossible to give error messages, but hopefully the linker takes care of that. It also gives false positives with some assembler syntax, but in the worst case would just lose some optimization from unnecessary references. - It doesn't handle the case (which happens in the kernel) that the C declaration is after the asm statement. This could be fixed with some more effort. - It doesn't work for static which can get mangled (that's a lot of the kernel cases) static is a difficult problem because there could be conflicting names, so we cannot jut put it all in partition zero. This would need some special handling in the LTO partitioning code to create new partitions just for having unique name spaces, and then avoid mangling. Related problem is also PR50676 It's likely possible to create situations where it's impossible to solve, there could be circular dependencies etc. But I assume in this case the non LTO case would fail too. Or maybe do something with redefining symbols at the assembler level. This one is somewhat difficult and I don't have a simple solution currently. Unfortunately to solve the kernel issue would need a solution for static.