Closed Bug 1268617 Opened 4 years ago Closed 4 years ago
Pass -g to rustc
58 bytes, text/x-review-board-request
We don't seem to be passing -g to rustc, which doesn't help with the crash report situation.
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+
I had to back this out in https://hg.mozilla.org/integration/mozilla-inbound/rev/3aa433b16d75 because Windows debug devtools tests started failing when this landed: https://treeherder.mozilla.org/logviewer.html#?job_id=27162094&repo=mozilla-inbound
Well, that's surprising. Did a try push on top of central for comparison. https://treeherder.mozilla.org/#/jobs?repo=try&revision=9f6622a64da5
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
(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.
You need to log in before you can comment on or make changes to this bug.