canmove, Confirmed users
225
edits
| Line 53: | Line 53: | ||
That leads me back to the DWARF Call Frame Information. This is the data added to an executable with the -fasynchronous-unwind-tables flag is set in GCC. Currently we can't use this information because it is HUGE and we run out of memory on the B2G devices. | That leads me back to the DWARF Call Frame Information. This is the data added to an executable with the -fasynchronous-unwind-tables flag is set in GCC. Currently we can't use this information because it is HUGE and we run out of memory on the B2G devices. | ||
The only obvious way forward is to have GCC generate and output all of the DWARF data, including the Call Frame Information, and then we write a new tool that strips out the DWARF information from the elf, condenses it down to just the data we need (prologue/epilogue test for a given PC) and then writes it back to the elf. Then the profiler would have the necessary data to fully unwind stacks correctly, 100% of the time. | |||