Opened 4 months ago

Closed 3 months ago

Last modified 4 days ago

#31448 closed defect (fixed)

gold and lld break linking 32bit Linux bundles we need to resort to bfd

Reported by: gk Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-rbm, ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201909R, BugSmashFund
Cc: boklm Actual Points: 2
Parent ID: #30321 Points: 2
Reviewer: Sponsor:

Description

For some reason both gold

40:57.34 toolkit/library/libxul.so
41:17.86 /var/tmp/dist/binutils/bin/ld.gold.real: internal error in relocate_section, at i386.cc:3684

and lld

40:55.77 toolkit/library/libxul.so
41:04.50 ld.lld: error: dwarf.c:(.debug_info+0x20DE295A): has non-ABS relocation R_386_GOTOFF against symbol '.LC25'

fail when linking Firefox 68 in our build setup while bfd works.

Child Tickets

Change History (14)

comment:1 Changed 4 months ago by pili

Sponsor: Sponsor44-can

Tagging with Sponsor 44

comment:2 Changed 3 months ago by gk

Cc: boklm added
Keywords: tbb-9.0-must-alpha TorBrowserTeam201909 added
Parent ID: #30321

comment:4 Changed 3 months ago by gk

Moving must-alpha tickets to September.

comment:5 Changed 3 months ago by pili

Points: 2

comment:6 Changed 3 months ago by cypherpunks

Does lld work without debug info? BTW, they made a good progress in lld 9.

comment:7 Changed 3 months ago by boklm

gold is working if we disable debug infos, and remove the --verbose option from ./mach build. This is also fixing #31618.

With the --verbose option, the build fails with the error:

20:23.94 [style 0.0.1] cargo:rerun-if-changed=/var/tmp/build/firefox-80f3dafdd420/obj-i686-pc-linux-gnu/dist/include/nsISelectionController.h
20:23.94 thread 'main' panicked at 'stack backtrace:
20:23.94    0:     0x556c358f0aaf - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h304be3226173ed42
20:23.94                                at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
20:23.94    1:     0x556c358d7027 - std::sys_common::backtrace::print::hd25e8e60339fbb32
20:23.94                                at src/libstd/sys_common/backtrace.rs:70
20:23.94                                at src/libstd/sys_common/backtrace.rs:58
20:23.94    2:     0x556c358f6131 - std::panicking::default_hook::{{closure}}::h03a7ac06911d91f6
20:23.94                                at src/libstd/panicking.rs:200
20:23.94    3:     0x556c358f5eb3 - std::panicking::default_hook::hf698310ff6948dc9
20:23.94                                at src/libstd/panicking.rs:215
20:23.94    4:     0x556c358f681f - std::panicking::rust_panic_with_hook::h1110d0ebea64132e
20:23.94                                at src/libstd/panicking.rs:478
20:23.94    5:     0x556c358f63b1 - std::panicking::continue_panic_fmt::h021e998d93d9aaa2
20:23.94                                at src/libstd/panicking.rs:385
20:23.94    6:     0x556c358f62fe - std::panicking::begin_panic_fmt::h77660097330c47c3
20:23.94                                at src/libstd/panicking.rs:340
20:23.94    7:     0x556c358ed576 - std::io::stdio::_print::h6e57cfdb1b772a9e
20:23.94                                at src/libstd/io/stdio.rs:735
20:23.94                                at src/libstd/io/stdio.rs:744
20:23.94    8:     0x556c3550d9aa - cargo::core::compiler::job_queue::JobQueue::drain_the_queue::hffcf682cf810a238
20:23.94    9:     0x556c35549954 - std::panicking::try::do_call::h66c050aaf8a469a2
20:23.94   10:     0x556c358f9829 - __rust_maybe_catch_panic
20:23.94                                at src/libpanic_unwind/lib.rs:87
20:23.94   11:     0x556c35602eb4 - crossbeam_utils::thread::scope::hf1785210d8a5b66b
20:23.94   12:     0x556c3550b981 - cargo::core::compiler::job_queue::JobQueue::execute::h09f1e669b485a855
20:23.94   13:     0x556c3555ecc1 - cargo::core::compiler::context::Context::compile::h8a68efdbc0494af1
20:23.94   14:     0x556c35331d10 - cargo::ops::cargo_compile::compile_ws::hd78d2523b7ad97f6
20:23.94   15:     0x556c3532dfd8 - cargo::ops::cargo_compile::compile::h509beaa3ec4c3493
20:23.94   16:     0x556c3529033b - cargo::commands::rustc::exec::h3b4e359c9f17ec05
20:23.94   17:     0x556c3527ce55 - cargo::cli::main::hc45236825e872f74
20:23.94   18:     0x556c3529b01f - cargo::main::hda5e03499791a40b
20:23.94   19:     0x556c35290ea2 - std::rt::lang_start::{{closure}}::h6ad13ea773945a56
20:23.94   20:     0x556c358f6232 - std::panicking::try::do_call::h89d6bcd43bef83f4
20:23.94                                at src/libstd/rt.rs:49
20:23.94                                at src/libstd/panicking.rs:297
20:23.94   21:     0x556c358f9829 - __rust_maybe_catch_panic
20:23.94                                at src/libpanic_unwind/lib.rs:87
20:23.94   22:     0x556c358ea51f - std::rt::lang_start_internal::h6d57f5d29fcde9f1
20:23.94                                at src/libstd/panicking.rs:276
20:23.94                                at src/libstd/panic.rs:388
20:23.94                                at src/libstd/rt.rs:48
20:23.94   23:     0x556c3529d641 - main
20:23.94   24:     0x2adc4abcfeac - __libc_start_main
20:23.94   25:     0x556c35272248 - <unknown>
22:19.92 [style 0.0.1] cargo:rerun-if-changed=/var/tmp/build/firefox-80f3dafdd420/obj-i686-pc-linux-gnu/dist/include/mozilla/dom/TouchBinding.h
22:19.92 make[4]: *** [force-cargo-library-build] Error 101
22:19.92 make[4]: Leaving directory `/var/tmp/build/firefox-80f3dafdd420/obj-i686-pc-linux-gnu/toolkit/library/rust'
22:19.92 make[3]: *** [toolkit/library/rust/target] Error 2
22:19.92 make[3]: Leaving directory `/var/tmp/build/firefox-80f3dafdd420/obj-i686-pc-linux-gnu'
22:19.92 make[2]: *** [compile] Error 2
22:19.92 make[2]: Leaving directory `/var/tmp/build/firefox-80f3dafdd420/obj-i686-pc-linux-gnu'
22:19.92 make[1]: *** [default] Error 2
22:19.92 make[1]: Leaving directory `/var/tmp/build/firefox-80f3dafdd420/obj-i686-pc-linux-gnu'
22:19.92 make: *** [build] Error 2

comment:8 Changed 3 months ago by gk

boklm: are you building the browser part with commit 4458b4e8a09aaa759f1735b36aec860aa61f3ba7 applied? (i.e. after the tor-browser patch for #31621 landed) I ask, because that's exactly the error you would get if the nodejs problem was not solved.

comment:9 in reply to:  8 ; Changed 3 months ago by boklm

Replying to gk:

boklm: are you building the browser part with commit 4458b4e8a09aaa759f1735b36aec860aa61f3ba7 applied? (i.e. after the tor-browser patch for #31621 landed) I ask, because that's exactly the error you would get if the nodejs problem was not solved.

Oh, I probably did an alpha build by mistake instead of nightly. I will try again doing a nightly.

comment:10 in reply to:  9 Changed 3 months ago by boklm

Keywords: TorBrowserTeam201909R added; TorBrowserTeam201909 removed
Status: newneeds_review

Replying to boklm:

Replying to gk:

boklm: are you building the browser part with commit 4458b4e8a09aaa759f1735b36aec860aa61f3ba7 applied? (i.e. after the tor-browser patch for #31621 landed) I ask, because that's exactly the error you would get if the nodejs problem was not solved.

Oh, I probably did an alpha build by mistake instead of nightly. I will try again doing a nightly.

This was indeed the issue.

In branch bug_31448_v5 I made a patch disabling debug symbols and switching back to ld.gold:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_31448_v5&id=8cc9eaf22abf0c9d98b88bb60aaa1476e4a6555c

I did builds on two machines with this patch to see that is is also fixing #31618.

However I did not find why it is failing with debug symbols.

comment:11 Changed 3 months ago by gk

Resolution: fixed
Status: needs_reviewclosed

The patch looks good to me and it seems #31618 is fixed, too. I am still wondering, though, what breaks now. I tried a bunch of things:
-different binutils versions (2.32, 2.29, 2.28.1) - no effect
-using GCC - no effect
-disabling hardening - no effect
-compiling our stable branch with the toolchain on master - that works with debug symbols enabled (I had to disable Stylo, though, due to errors)

So, it seems something between esr60 and esr68 causes the breakage. We should find out what it is, but we can use a new bug for that.

I am merging the patch as it is for now: commit 3b899b766fd13986fc3545a4294fd391b6ea139d on master has it.

comment:12 Changed 3 months ago by boklm

Actual Points: 2

comment:13 Changed 4 days ago by pili

Keywords: BugSmashFund added

BugSmashFund can be used for the ESR work done so far

comment:14 Changed 4 days ago by pili

Sponsor: Sponsor44-can

Sponsor 44 only covered PM and Team Lead work

Note: See TracTickets for help on using tickets.