1806470 - The --build-id flag is no longer set on local builds

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Markus Stange [:mstange]]

This came up in bug 1805915 comment 9: Local builds on Linux no longer contain ELF build IDs.

The profiler uses build IDs to identify the correct debug information during symbolication. There is a fallback for when no build ID is present, but a bug in that fallback caused profiler symbolication to break when mold was used.

It would be nice to have build IDs by default.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug is a defect, but please change it back in case of error.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1796518

:glandium, since you are the author of the regressor, bug 1796518, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Comment 3

[Mike Hommey [:glandium]]

Generating the build id is actually taking a significant portion of the time used to link, which is why it was removed for local builds.

The profiler uses build IDs to identify the correct debug information during symbolication. There is a fallback for when no build ID is present, but a bug in that fallback caused profiler symbolication to break when mold was used.

I'm confused by this. I don't see what the build id brings for local builds. It's not like you can get symbols from the symbols server, because there will be no match there, and you won't have local breakpad symbols either because they're not generated by default. So what is the build id used for in local builds?

Comment 4

[Markus Stange [:mstange]]

Fair point.

It mostly comes down to code reuse. Symbolication is asynchronous: The profiler UI requests symbols from the browser after the profiler tab is opened. When we designed the API of the symbol request, we just reused the same API format that was already used for the request to the symbol server. And in that API, libraries are identified by "debug name + breakpad ID". In other words, the Firefox Profiler UI basically pretends that Firefox is a local symbol server, and Firefox translates the library identification pair back to the absolute file path.

I can imagine one niche case where having a build ID or some kind of hash is actually useful in practice: If libxul.so was overwritten by a new compilation while Firefox was already open, then the hash check makes sure that we don't return the incorrect symbols from the new build for a profile from the old build.

In any case, I've now landed a fix for the fallback hash computation in bug 1808982, so my immediate need for a build ID has been resolved.

Comment 5

[Mike Hommey [:glandium]]

I'll need to check, but a reasonable alternative could be to set --build-id=uuid, which should be cheap (it's supposed to be random and unrelated to the contents of the binary being linked)

Comment 6

[Mike Hommey [:glandium]]

Attachment: Bug 1806470 - Still set some build-id on local builds.

Bug 1796518 removed the build-id on local builds because it's faster to
do so, but it may be desirable to still have /some/ build-id, even if
it's random, so use a uuid on local builds instead of none at all.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/81385fe1076a
Still set some build-id on local builds. r=firefox-build-system-reviewers,andi

Comment 8

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/81385fe1076a