1268617 - Pass -g to rustc

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Ralph Giles (:rillian)]

We don't seem to be passing -g to rustc, which doesn't help with the crash report situation.

Comment 1

[Ralph Giles (:rillian)]

Attachment: MozReview Request: Bug 1268617 - Pass -g to rustc on debug builds. r?ted

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/

Comment 2

[(not currently active) Ted Mielczarek]

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.

Comment 3

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6aa3f079d304

Comment 4

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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

Comment 5

[Ralph Giles (:rillian)]

Well, that's surprising. Did a try push on top of central for comparison. https://treeherder.mozilla.org/#/jobs?repo=try&revision=9f6622a64da5

Comment 6

[(not currently active) Ted Mielczarek]

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!

Comment 7

[(not currently active) Ted Mielczarek]

Filed bug 1270091 on fix_stack_using_bpsyms.py.

Comment 8

[Ralph Giles (:rillian)]

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

Comment 9

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/46a1211738cb

Comment 10

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/46a1211738cb

Comment 11

[(not currently active) Ted Mielczarek]

(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.