std.debug.scanAllFunctions is too slow; stack traces are too slow for large binaries

[andrewrk]

In large binaries, such a the zig compiler itself, scanning the entire list of functions in all of the debug info is doing too much work, and it makes stack traces take so long that it's worth it to ctrl+C the process and use a debugger. Instead the functions should be found lazily, and I believe there is additional DWARF information available to help binary search or otherwise quickly narrow in on the function that a given address is in.

[tiehuis]

Related to #907. I don't believe the dwarf parsing used a buffered in stream either last I checked. An strace may be interesting.

[tiehuis]

Here is a partial strace of a compiler assertion error for reference. Cancelled before it finished since it was taking forever. I would definitely start with adding buffered reads and then see how the repeated seeks can be reduced. Maybe as suggested there is extra dwarf information for navigating functions.

$ strace -c zig test replay.zig                                                      
Assertion failed. This is a bug in the Zig compiler.
^Cstrace: Process 22295 detached
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 79.13  131.484354           8  16689070           read
 20.87   34.673769           7   4953949           lseek
  0.00    0.001055           6       191           futex
  0.00    0.000298           5        66           mmap
  0.00    0.000258           5        50         8 openat
  0.00    0.000177           4        40           close
  0.00    0.000145           4        39           fstat
  0.00    0.000044          22         2           readlink
  0.00    0.000031           2        17        15 access
  0.00    0.000030          10         3         3 mkdir
  0.00    0.000021          11         2           fcntl
  0.00    0.000020           2        12           getcwd
  0.00    0.000013           0        39           brk
  0.00    0.000000           0         2           write
  0.00    0.000000           0         8         8 stat
  0.00    0.000000           0        26           mprotect
  0.00    0.000000           0         1           munmap
  0.00    0.000000           0         2           rt_sigaction
  0.00    0.000000           0         1           rt_sigprocmask
  0.00    0.000000           0         3           mremap
  0.00    0.000000           0         1           execve
  0.00    0.000000           0         1           arch_prctl
  0.00    0.000000           0         1           set_tid_address
  0.00    0.000000           0         1           set_robust_list
  0.00    0.000000           0         1           prlimit64
------ ----------- ----------- --------- --------- ----------------
100.00  166.160215              21643528        34 total

[andrewrk]

I have no doubt buffered reads would be a significant speed up and it's definitely worth doing. However I believe there is also a Big-O complexity issue here as well