//go:linkname usage of runtime.gcController breaks with Go 1.23+ linkname checker

[rahulduvedi]

The library uses //go:linkname to access runtime.gcController (rtml.go#L16-L29), which is an internal runtime symbol not in Go's linkname allowlist.

Since Go 1.23, the linker enforces -checklinkname=1 by default, which blocks access to unapproved internal symbols. This causes a build failure for any downstream consumers

The only workaround is -ldflags=-checklinkname=0, which disables the safety check for all dependencies not ideal for consumers concerned about runtime stability.
Could the library be updated to use a supported API (e.g., runtime/metrics or debug.ReadGCStats) instead of directly accessing runtime internals?

Thanks for all your work for the community on this one.

[blumamir]

Hi @rahulduvedi

Thank you for sharing your findings here.

The issue with runtime/metrics or debug.ReadGCStats is that they are very expensive to call. They both use "Stop the World" and doing a lot of computation, thus they are not ideal for any "real time" memory checks. we wrote it so we can check the memory before every request we process, which will be very expensive to do with the official api.

After a lot of research, we landed on this solution, which has trade offs as you mention above. the main problem is the need to use the -ldflags=-checklinkname=0 which can be considered unsafe. in return you get the power to run very accurate and cheap check of the live memory state as the go runtime see it exactly.

You can weight the pros/cons of each option and pick the memory protection method that most fit your requirements and memory allocation patterns.

Feel free to share more info about your application, would love to help if I can.

[blumamir]

Also linking to a section in the README regarding this requirement: https://github.com/odigos-io/go-rtml#about-ldflags-checklinkname0