Профилировщик в kernel space видит только адреса. Полезные инсайты появляются только после символизации — и в Go этот этап устроен иначе, чем в других языках.
Проблема проявляется в момент, когда профиль уже собран, но интерпретировать его невозможно. eBPF-профилировщик снимает stack traces на уровне ядра и получает набор program counter значений — сырые адреса в памяти. Без символизации это просто hex-строки без контекста. В отличие от традиционных профилировщиков, здесь нельзя обратиться к runtime процесса или внедрить агент. Всё, что доступно — это адреса и бинарники на диске. При этом система должна укладываться в жёсткое ограничение по overhead (менее ~1% CPU). Это превращает символизацию в задачу с жёсткими требованиями к latency и алгоритмической сложности.
Решение строится вокруг оффлайн-анализа бинарника и быстрого поиска соответствий «адрес → функция». Для Go ключевую роль играет секция .gopclntab — таблица, встроенная в бинарник, которая хранит соответствие диапазонов адресов функциям и строкам исходного кода. В отличие от DWARF debug-информации или ELF symbol tables, эта структура не удаляется при strip. Это компромисс: бинарник становится больше (в примере около 22% размера занимает gopclntab), но система получает стабильную символизацию без внешних symbol servers. Для eBPF это особенно важно, потому что fallback-стратегии (как в C/C++) либо дороги, либо недоступны.
Реализация выглядит как конвейер с несколькими фазами. Сначала профилировщик читает /proc/<pid>/maps, чтобы определить, какому бинарнику принадлежит адрес. Затем открывает ELF-файл и извлекает .gopclntab. Эта структура уже отсортирована по адресам, поэтому применяется бинарный поиск (O(log n)) для нахождения функции, в диапазон которой попадает адрес. Результат кэшируется (LRU), чтобы повторные lookup выполнялись за микросекунды. Это критично: при частоте 20–100 Hz и десятках процессов система легко выходит на десятки тысяч разрешений адресов в секунду. Линейный поиск здесь сразу приводит к неприемлемому CPU overhead.
На практике это даёт предсказуемое поведение. Даже если бинарник stripped, Go-программа продолжает корректно символизироваться, потому что runtime требует наличия gopclntab. В других языках удаление символов часто делает профиль бесполезным без внешних debug-файлов. Ограничения остаются: например, заинлайненные функции не появляются как отдельные фреймы, а CGO-вызовы могут требовать отдельной символизации. Метрики улучшения в исходном материале не приведены, но архитектурно система достигает микросекундных lookup и удерживает низкий overhead, что делает continuous profiling практически незаметным для продакшена.