#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
_______________________________________________
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
