[tor-bugs] #26323 [Applications/Tor Browser]: Build 32bit Linux bundles on 64bit systems

[Tor Bug Tracker & Wiki]

#26323: Build 32bit Linux bundles on 64bit systems
--------------------------------------+--------------------------
 Reporter:  gk                        |          Owner:  tbb-team
     Type:  task                      |         Status:  new
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:  tbb-rbm                   |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+--------------------------

Comment (by traumschule):

 I learned it's a compiler bug so more RAM does not help, {{{debuginfo=1}}}
 (instead of {{{--disable-debug-symbols}}}) might however be a progress.

 =  Conditionally disable Rust debug symbols

 https://bugzilla.mozilla.org/show_bug.cgi?id=1409680#c2
 > Downstream FreeBSD keeps non-debug symbols for profiling (dtrace,
 pmcstat) and quick stacktraces. Since Rust dependency was introduced
 libxul.so grew in size for no good reason (Firefox is mostly C++). And
 Stylo will bump the size even more.

 = stylo doesnt build on 32-bits

 https://bugzilla.mozilla.org/show_bug.cgi?id=1401093#c15
 > it *might* be a rust-bindgen issue (related to the clang version we're
 using, 5.0 here ? doubt it as successfull builds of m-b are done with
 ports clang, and failing builds from the packaging infra are done with
 ports clang too..) - he linked me to https://github.com/rust-lang-nursery
 /rust-bindgen/issues/340.
 https://bugzilla.mozilla.org/show_bug.cgi?id=1401093#c18
 > TL;DR, the clang-sys library is passing structs where libclang expects
 integers. This is fine everywhere but linux32 (or similar ABIs), so we
 need to fix it... I proposed a fix for clang-sys, and will update bindgen
 in mozilla-central once it lands.
 https://bugzilla.mozilla.org/show_bug.cgi?id=1401093#c36
 > So the original problem is a rustc compiler bug: on FreeBSD, when
 compiling the Rust part, the generated asm code expects struct from stack
 (it follows SysV/i386 convention); but the C compiler has generated asm
 code to return it from registers (the other convention, similar to
 OpenBSD), resulting stack corruption.
 https://bugzilla.mozilla.org/show_bug.cgi?id=1401093#c44
 >> If it is necessary for all native builds on 32-bits (whatever the
 platform), why not detecting it directly in the rust code where your patch
 is ? i suppose rust has a way to know the architecture of the build
 host...
 > https://github.com/servo/servo/pull/18935 (and yeah,
 target_pointer_width in a build script is actually host pointer width,
 fun)
 [https://github.com/servo/servo/pull/18935/commits/1abdf2665353f63a229f70e09b0b0577024a5481
 Run bindgen sequentially if we're on a 32-bit host]

 = build symbols missing on macOS/OS X, unhelpful crash signatures like [@
 XUL + 0xddb7c]

 https://bugzilla.mozilla.org/show_bug.cgi?id=1380381#c22
 > Please mention in the commit message that debuginfo=1 still means
 there's enough info for stack traces, although it lacks line info (so
 we'll know that something crashed in $function, but not at what specific
 line it did). debuginfo=2 also adds variable information, useful for
 debugging, but is irrelevant to crash reports.
 > The workaround has my approval. It is unfortunate that we lose
 temporarily lose line-level debugging info for Rust. But it's that, a big
 unknown and PITA reverting cross-compiling, keeping the trees closed, or
 no reliable debug symbols at all on OS X. This seems like the least bad
 option.

 = Restore full Rust debug symbols / address dsymutil crashes

 https://bugzilla.mozilla.org/show_bug.cgi?id=1381043#c17
 > Backport llvm r313872 to 3.9 to avoid llvm-dsymutil crashing on bad rust
 DWARF data.
 https://hg.mozilla.org/mozilla-central/rev/a3225b6f6193
 https://hg.mozilla.org/mozilla-central/rev/95555b11aaaf

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26323#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online