Bugzilla

I've thought about this some and have come to the counter-intuitive conclusion that the current stack merging behavior may actually be "correct", and that this is something we may want to fix in the front-end instead.

The key thing to remember is that stack walking doesn't give us functions - it gives us frame addresses. Frame addresses describe a place in the middle of a function. So let's say you have a function like this:

```c++
void myFunction() {
  some->code();
  {
    pushProfilerLabelFrame();
    more->code();
    this->line = gets + sampled; // <---
    more->code();
    popProfilerLabelFrame();
  }
  more->code();
```

The address for the sampled instruction could be considered "inside" the profiler label here.
It's only during symbolication that this address now resolves to the function name. So really, this is the step where we move from "something that describes a place inside the function" to "something that describes the entire function".

I've thought about this some and have come to the counter-intuitive conclusion that the current stack merging behavior may actually be "correct", and that this is something we may want to fix in the front-end instead.

The key thing to remember is that stack walking doesn't give us functions - it gives us frame addresses. Frame addresses describe a place in the middle of a function. So let's say you have a function like this:

```c++
void myFunction() {
  some->code();
  {
    pushProfilerLabelFrame();
    more->code();
    this->line = gets + sampled; // <---
    more->code();
    popProfilerLabelFrame();
  }
  more->code();
}
```

The address for the sampled instruction could be considered "inside" the profiler label here.
It's only during symbolication that this address now resolves to the function name. So really, this is the step where we move from "something that describes a place inside the function" to "something that describes the entire function".