The actual problem is a debug ID mismatch. The profile contains the value "B95396F750B7D947AAF1DC62F1771AF90", which was computed [here](https://searchfox.org/mozilla-central/rev/9b8ebf06145feeccf34dc126cf45b07e86556392/tools/profiler/core/shared-libraries-linux.cc#81), whereas the symbolication code computes a debug ID of "36D208789F8DF932F8E647CB2BE1FAE60". One of the reasons for that mismatch is the fact that the library doesn't contain an ELF build ID: `llvm-readelf --notes mold-opt-libxul.so` doesn't show any output. I'm a bit surprised by this. The mold documentation specifically describes how to speed up build ID computation, [in the Details section](https://github.com/rui314/mold/blob/07d89116a8fd4766645cf3581ac755b56b0c2bc4/docs/design.md#details). Anyway, we have fallback code to compute a debug ID even when no ELF build ID is present, by hashing the first 4096 bytes of the `.text` section. But this fallback code is behaving differently: The one in mozilla-central [specifically looks for the `.text` section](https://searchfox.org/mozilla-central/rev/9b8ebf06145feeccf34dc126cf45b07e86556392/toolkit/crashreporter/google-breakpad/src/common/linux/file_id.cc#125-126), whereas the one in the profiler symbolication code [takes the first section of "kind" "text"](https://github.com/mstange/samply/blob/e333d2b15bfb101a09fbb13d60da6032e79ac643/samply-symbols/src/debugid_util.rs#L92), which, in `mold-opt-libxul.so`, happens to be the `.plt` section. It looks like I [introduced](https://github.com/mstange/profiler-get-symbols/commit/d6c71897581547021133b36e92f7166dde424085#diff-31c97589d031bca1dbc5cba43a1fa29c33085a23678d6cc1367b0f0e752982d7L75-L82) this bug in May 2020.
Bug 1805915 Comment 9 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The actual problem is a debug ID mismatch. The profile contains the value "B95396F750B7D947AAF1DC62F1771AF90", which was computed [here](https://searchfox.org/mozilla-central/rev/9b8ebf06145feeccf34dc126cf45b07e86556392/tools/profiler/core/shared-libraries-linux.cc#81), whereas the symbolication code computes a debug ID of "36D208789F8DF932F8E647CB2BE1FAE60". One of the reasons for that mismatch is the fact that the library doesn't contain an ELF build ID: `llvm-readelf --notes mold-opt-libxul.so` doesn't show any output. I'm a bit surprised by this. The mold documentation specifically describes how to speed up build ID computation, [in the Details section](https://github.com/rui314/mold/blob/07d89116a8fd4766645cf3581ac755b56b0c2bc4/docs/design.md#details). Anyway, we have fallback code to compute a debug ID even when no ELF build ID is present, by hashing the first 4096 bytes of the `.text` section. But this fallback code is behaving differently: The one in mozilla-central [specifically looks for the `.text` section](https://searchfox.org/mozilla-central/rev/9b8ebf06145feeccf34dc126cf45b07e86556392/toolkit/crashreporter/google-breakpad/src/common/linux/file_id.cc#125-126), whereas the one in the profiler symbolication code [takes the first section of "kind" "text"](https://github.com/mstange/samply/blob/e333d2b15bfb101a09fbb13d60da6032e79ac643/samply-symbols/src/debugid_util.rs#L92), which, in `mold-opt-libxul.so`, happens to be the `.plt` section. It looks like [I introduced this bug](https://github.com/mstange/profiler-get-symbols/commit/d6c71897581547021133b36e92f7166dde424085#diff-31c97589d031bca1dbc5cba43a1fa29c33085a23678d6cc1367b0f0e752982d7L75-L82) in May 2020.