Once we have a new ProfilerGetSymbols API that lets us request information for a given set of addresses (bug 1563316), we can start to return a richer set of data for each address: Instead of just returning the closest symbol name and the address's offset from the symbol, if we have access to the binary's debug information, we can also return the following: - The function names of any functions that were inlined by the compiler at this address (the "inline stack") - The filename where each of these functions lives in the source code - The line number of the code line that produced this instruction, for each inline stack frame Once we have this information, we can display much richer information in the profiler frontend.
Bug 1563318 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Once we have a new ProfilerGetSymbols API that lets us request information for a given set of addresses (bug 1563316), we can start to return a richer set of data for each address. Instead of just returning the closest symbol name and the address's offset from the symbol, if we have access to the binary's debug information, we can also return the following: - The function names of any functions that were inlined by the compiler at this address (the "inline stack") - The filename where each of these functions lives in the source code - The line number of the code line that produced this instruction, for each inline stack frame Once we have this information, we can display much richer information in the profiler frontend.
Once we have a new ProfilerGetSymbols API that lets us request information for a given set of addresses (bug 1563316), we can start to return a richer set of data for each address. Instead of just returning the closest symbol name and the address's offset from the symbol, if we have access to the binary's debug information, we can also return the following: - The function names of any functions that were inlined by the compiler at this address (the "inline stack") - The filename where each of these functions lives in the source code - The line number of the code line that produced this instruction, for each inline stack frame Once we have this information, we can display much richer information in the profiler frontend, e.g. [issue 2121](https://github.com/firefox-devtools/profiler/issues/2121) is about inline stacks in the call tree.
Once we have a new ProfilerGetSymbols API that lets us request information for a given set of addresses (bug 1563316), we can start to return a richer set of data for each address. Instead of just returning the closest symbol name and the address's offset from the symbol, if we have access to the binary's debug information, we can also return the following: - The function names of any functions that were inlined by the compiler at this address (the "inline stack") - The filename where each of these functions lives in the source code - The line number of the code line that produced this instruction, for each inline stack frame Once we have this information, we can display much richer information in the profiler frontend, e.g. [issue 2121](https://github.com/firefox-devtools/profiler/issues/2121) is about inline stacks in the call tree.