Use the new dump_syms tool in mingw builds
Categories
(Firefox Build System :: General: Unsupported Platforms, defect)
Tracking
(firefox86 fixed)
Tracking | Status | |
---|---|---|
firefox86 | --- | fixed |
People
(Reporter: gsvelto, Assigned: gsvelto)
References
Details
Attachments
(1 file)
When we switched Windows builds to the oxidized dump_syms
tool in bug 1594344 we failed to add the necessary bits to the mingw jobs too. As such the mingw builds lack symbols as seen in bug 1618819 for example.
Assignee | ||
Comment 1•5 years ago
|
||
I tried naively adding it to the tasks but it doesn't work: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b94b02011556c2149bff39da26d4a986379c5424
I'll have a better look tomorrow.
Assignee | ||
Comment 2•5 years ago
|
||
I think I figured out how to fix this.
Assignee | ||
Comment 3•5 years ago
|
||
I managed to fix the downloading & finding dump_syms part of the problem but it's still not producing symbols, this needs more digging:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=076a9ec2d3ed7c285c223bff243e8bea60baf83d
Comment 4•5 years ago
|
||
mingw builds don't produce the same kind of symbols. I'm not even sure they enable the crashreporter.
Assignee | ||
Comment 5•5 years ago
|
||
It's not producing .pdb files? That would explain why it's not working then.
Comment 6•5 years ago
|
||
(In reply to Gabriele Svelto [:gsvelto] from comment #5)
It's not producing .pdb files? That would explain why it's not working then.
They produce .pdbs; but they are in a different place. Like the ASAN builds, they build next to the .exe/.dll
Comment 7•5 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is --
(Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to --
(default, untriaged.)
Comment 8•5 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is --
(Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to --
(default, untriaged.)
Comment 9•5 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is --
(Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to --
(default, untriaged.)
Comment 10•5 years ago
|
||
The severity of these bugs was changed, mistakenly, from normal
to S3
.
Because these bugs have a priority of --
, indicating that they have not been previously triaged, these bugs should be changed to Severity of --
.
Assignee | ||
Comment 11•5 years ago
|
||
Tom, I noticed that when MOZ_COPY_PDBS
is set - like in MinGW builds - we just skip the symbol-generation step:
Reading the comments in bug 1475562 this was a conscious choice because the old dump_syms wouldn't work. Now that we have a working dump_syms how do you suggest we proceed? Shall I try removing MOZ_COPY_PDBS
and let MinGW builds use the normal flow as other builds?
Comment 12•5 years ago
|
||
(In reply to Gabriele Svelto [:gsvelto] from comment #11)
Reading the comments in bug 1475562 this was a conscious choice because the old dump_syms wouldn't work. Now that we have a working dump_syms how do you suggest we proceed? Shall I try removing
MOZ_COPY_PDBS
and let MinGW builds use the normal flow as other builds?
Absolutely. You may find that the pdbs are not in the expected place once generated and we need to special case MinGW somehow to either put them in the right place or look for them in a different place.
Assignee | ||
Comment 13•5 years ago
|
||
This uses the new cross-platform dump_syms tool to generate symbols for MinGW
builds, just like on all other platforms.
Comment 14•5 years ago
|
||
Comment 15•5 years ago
|
||
bugherder |
Description
•