Bugzilla

The Gecko profiler records raw stack frame addresses in the profile JSON. These addresses can come from two different sources:

 - The instruction pointer, and
 - Stack walking, which records return addresses.

The instruction pointer is how we get the topmost stack frame, and the rest of the frames are return addresses.
However, once these addresses are stored in the profile JSON, we have forgotten where we got them from.

The profiler front-end needs to treat return addresses different from "instruction pointer" values when looking up symbols and when calculating per-instruction costs. See bug 1642516 for background.

How can it know which addresses are return addresses?

It now [makes the following assumption](https://github.com/firefox-devtools/profiler/blob/b4f76e7596d324f701f3ed16e5a886cd9ba6f55f/src/profile-logic/profile-data.js#L2924-L2930):

 - Only the top stack frame of "sample" stacks came from the instruction pointer.
 - All other addresses are return addresses. This includes the top stack frame from synchronous backtrace stacks (marker cause stacks, allocation stacks).

Julien [suggested](https://github.com/firefox-devtools/profiler/pull/3548#discussion_r708374853) that this assumption may be fragile and that we may want to encode it into the profile JSON:

> I mean: this is probably right in the current code, but how do we ensure this stays right in the future? Should we add comment in some strategic places in the cpp profiler code?  Should we have something in the meta properties that says that the stacks in that table have that property?
>
> ```js
> meta: {
>   ...
>   stacksNudging: {
>     // properties with the same name than the tables
>     samples: "all-but-last", // or "all-but-top"
>     markers: "all",
>     jsAllocations: "all",
>     nativeAllocations: "all",
>   },
> }
> ```

The Gecko profiler records raw stack frame addresses in the profile JSON. These addresses can come from two different sources:

 - The instruction pointer, and
 - Stack walking, which records return addresses.

The instruction pointer is how we get the topmost stack frame, and the rest of the frames are return addresses.
However, once these addresses are stored in the profile JSON, we have forgotten where we got them from.

The profiler front-end needs to treat return addresses different from "instruction pointer" values when looking up symbols and when calculating per-instruction costs. See bug 1642516 comment 0 for background.

How can it know which addresses are return addresses?

It now [makes the following assumption](https://github.com/firefox-devtools/profiler/blob/b4f76e7596d324f701f3ed16e5a886cd9ba6f55f/src/profile-logic/profile-data.js#L2924-L2930):

 - Only the top stack frame of "sample" stacks came from the instruction pointer.
 - All other addresses are return addresses. This includes the top stack frame from synchronous backtrace stacks (marker cause stacks, allocation stacks).

Julien [suggested](https://github.com/firefox-devtools/profiler/pull/3548#discussion_r708374853) that this assumption may be fragile and that we may want to encode it into the profile JSON:

> I mean: this is probably right in the current code, but how do we ensure this stays right in the future? Should we add comment in some strategic places in the cpp profiler code?  Should we have something in the meta properties that says that the stacks in that table have that property?
>
> ```js
> meta: {
>   ...
>   stacksNudging: {
>     // properties with the same name than the tables
>     samples: "all-but-last", // or "all-but-top"
>     markers: "all",
>     jsAllocations: "all",
>     nativeAllocations: "all",
>   },
> }
> ```