Fix unwind and symbol export for _start in C programs

[zachcmadsen]

Problem

Below is a stack from a simple C program workload. I collected the trace with record-trace --on-cpu --pid <pid> on an Azure VM running Azure Linux. There's a couple problems. We don't resolve workload!_start and we try to unwind past it.

+ Process32 workload (139721) Args: workload
 + Thread (139721) CPU=19974ms
  + BROKEN
   + [stack]!?
   |+ workload!?
   | + libc.so.6!__libc_start_main
   |  + libc.so.6!__libc_start_call_main
   |   + workload!main
   |    + workload!run_workload
   |     + workload!hot_loop
   |     + workload!warm_loop
   |     + workload!cold_loop

Changes

• Use an inclusive end boundary for the symbol filter in add_matching_symbols. Symbols whose only matching IP is their last byte don't get exported with the current exclusive boundary. That always seems to be the case for _start. It looks like we use an inclusive boundary in other places too: elf.rs and graph.rs
• Honor DWARF undefined rules in unwind_to_cfa to end unwinds at _start

Result

Stack after changes

+ Process32 workload (140228) Args: workload
 + Thread (140228) CPU=19984ms
  + BROKEN
  |+ workload!?
  ||+ libc.so.6!__libc_start_main
  || + libc.so.6!__libc_start_call_main
  ||  + workload!main
  ||   + workload!run_workload
  ||    + workload!hot_loop
  ||    + workload!warm_loop
  ||    + workload!cold_loop

and with corresponding TraceEvent changes:

+ Process32 workload (140228) Args: workload
 + Thread (140228) CPU=19984ms
  + workload!_start
  |+ libc.so.6!__libc_start_main
  | + libc.so.6!__libc_start_call_main
  |  + workload!main
  |   + workload!run_workload
  |    + workload!hot_loop
  |    + workload!warm_loop
  |    + workload!cold_loop

[zachcmadsen]

@brianrob There'll be a small TraceEvent PR with corresponding changes. Just a heads up

[brianrob]

This looks reasonable to me. @beaubelgrave, can you take a look at the ruwind change?

@zachcmadsen, please do share the TraceEvent change as well. I have a pending change in this area, and so we may want to merge them, but I haven't posted a PR for it yet.

[beaubelgrave]

Approved and merged, thanks @zachcmadsen!