Symbolizing addresses with DWARF is well known to be CPU and memory intensive. While other formats such as LLVM's GSYM [0] exist to make lookups cheap, there is still a need to fetch the debug information. Fortunately for us, it is 2024 and there are many pieces of infrastructure already in place, such as debuginfod [1]. This is something we might want to add later so lightswitch can programmatically download missing debug information, and maybe even optionally convert them to GSYM.
As of now, there is another use case that could benefit from not running a local symbolizing: remote symbolization. To perform symbolization in remote, i.e. some backend, we should just sent the raw memory addresses that make up the stack. We do this now with the --symbolizer flag, except for kernel symbols, which are not well supported in remote use cases, but this is something that will be tackled soon.
Test Plan
Ran lots of tests locally, both locally (with and without local symbolization) and remotely too.
Symbolizing addresses with DWARF is well known to be CPU and memory intensive. While other formats such as LLVM's GSYM [0] exist to make lookups cheap, there is still a need to fetch the debug information. Fortunately for us, it is 2024 and there are many pieces of infrastructure already in place, such as debuginfod [1]. This is something we might want to add later so lightswitch can programmatically download missing debug information, and maybe even optionally convert them to GSYM.
As of now, there is another use case that could benefit from not running a local symbolizing: remote symbolization. To perform symbolization in remote, i.e. some backend, we should just sent the raw memory addresses that make up the stack. We do this now with the
--symbolizer
flag, except for kernel symbols, which are not well supported in remote use cases, but this is something that will be tackled soon.Test Plan
Ran lots of tests locally, both locally (with and without local symbolization) and remotely too.