Closed Bug 1268617 Opened 8 years ago Closed 8 years ago

Pass -g to rustc

Categories

(Firefox Build System :: General, defect)

defect
Not set
normal

Tracking

(firefox49 fixed)

RESOLVED FIXED
mozilla49
Tracking Status
firefox49 --- fixed

People

(Reporter: rillian, Assigned: rillian)

References

Details

Attachments

(1 file)

We don't seem to be passing -g to rustc, which doesn't help with the crash report situation.
Product: Toolkit → Core
Enable debug output from the rust compiler when we're doing so
for the C/C++ compilers.

Review commit: https://reviewboard.mozilla.org/r/49529/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/49529/
Attachment #8746673 - Flags: review?(ted)
Comment on attachment 8746673 [details]
MozReview Request: Bug 1268617 - Pass -g to rustc on debug builds. r?ted

https://reviewboard.mozilla.org/r/49529/#review47055

Adding more stuff to config.mk makes me sad, but this patch is so small and I don't want to make you do busywork to get this fixed. I'll fix it when I move the m4 stuff to moz.configure.
Attachment #8746673 - Flags: review?(ted) → review+
Well, that's surprising. Did a try push on top of central for comparison. https://treeherder.mozilla.org/#/jobs?repo=try&revision=9f6622a64da5
Flags: needinfo?(giles)
So that test hit an assertion, and then the harness was trying to symbolicate the assertion stack, and it failed parsing the Breakpad symbol file because a FUNC line is missing a function name.

So there are two bugs here:
1) fix_stack_using_bpsyms.py shouldn't break on FUNC records with missing symbols:
https://dxr.mozilla.org/mozilla-central/rev/0a25833062a880f369e6f9f622413a94cc671bf4/tools/rb/fix_stack_using_bpsyms.py#46

2) Either rustc is outputing bad debug info for these functions, or dump_syms is failing to interpret them properly. Looking at the symbol file from that build, I see (among others):
```
FUNC 3eee0 c0 0 
3eee0 b 90 284744
3eeeb 1e 91 284744
3ef09 12 59 284722
3ef1b 5 138 284722
3ef20 3d 91 284744
3ef5d f 234 284745
3ef6c 27 139 284722
3ef93 d 234 284745
```

That function is missing a name! The `284744` there is a file number, which is:
FILE 284744 hg:hg.mozilla.org/integration/mozilla-inbound:media/libstagefright/binding/mp4parse/capi.rs:6aa3f079d304

Mashing the info from those two together produces:
https://hg.mozilla.org/integration/mozilla-inbound/file/6aa3f079d304/media/libstagefright/binding/mp4parse/capi.rs#l90

so this is mp4parse_new, and at least the line data is right, which is nice!
Filed bug 1270091 on fix_stack_using_bpsyms.py.
Thanks for the help, Ted. I don't know much about this, but `objdump -g obj/media/libstagefright/liblib.rlib` in my build does show several occurances of `mp4parse_new`, and those are propagated to `liburl.a`. Perhaps the incompatibility is in our symbol extractor then.

Contents of the .debug_info section:

    <3396>   DW_AT_linkage_name: (indirect string, offset: 0x13fdf): _ZN3lib4capi12mp4parse_newE
    <339a>   DW_AT_name        : (indirect string, offset: 0x13ffb): mp4parse_new
 
Contents of the .debug_pubnames section:

    Offset      Name
    3395        mp4parse_new
https://hg.mozilla.org/mozilla-central/rev/46a1211738cb
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
(In reply to Ralph Giles (:rillian) needinfo me from comment #8)
> Thanks for the help, Ted. I don't know much about this, but `objdump -g
> obj/media/libstagefright/liblib.rlib` in my build does show several
> occurances of `mp4parse_new`, and those are propagated to `liburl.a`.
> Perhaps the incompatibility is in our symbol extractor then.

Yes, but unfortunately the problem you hit in CI was on Windows. :) I'm back from vacation now, I'll file a bug and take a look at it.
No longer blocks: 1272278
Depends on: 1272278
Depends on: 1272738
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.