The elephant Firefox in the room: too BIG to FIX? for non mainstream CPU architectures & REGRESSIONS
Fixing #OpenSource #Firefox distribution #bugs live! #Ad: PCs & more @Amazon: https://services.exactcode.de/amzn.cgi?index=books&keywords=rust You can support my work at: https://patreon.com/renerebe https://github.com/sponsors/rxrbln/ http://onlyfans.com/renerebe
https://exactcode.com https://t2sde.org https://rene.rebe.de
0:00 Introduction
5:00 Demo
7:00 Q & A
by Bits inside by René Rebe
linux foundation
It seems the "modern" way is to just implement functions with intrinsics, or inline assembly. I've been working on ROCm, to make it work again on RX Vega GPUs. rpp with the HIP backend requires AVX2 intrinsics! No fallbacks for the newer HIP code they've added, even though earlier code could be built with intrinsics disabled.
Abstract
This video transcript reveals a developer's ongoing efforts to
troubleshoot and preserve cross-platform compatibility within the
Firefox web browser. The browser's intricate architecture, compounded
by dependencies on external codebases, poses ongoing challenges.
These difficulties manifest as crashes (e.g., segmentation faults)
across multiple architectures, including x86 (32-bit), MIPS (32-bit),
and potentially RISC-V (32-bit).
Technical Focus
* Software Architecture: Firefox's complex and inadequately maintained source code is a focal point. Assembly code sections within the project hinder portability, and the code's vast scale (exemplified by 3 GB debug information) complicates debugging efforts.
* Cross-Platform Compatibility: Supporting numerous architectures is exceptionally difficult due to platform-specific assembly, an absence of generic C/C++ implementations, and inconsistencies introduced by varying compilers and toolchains.
* Dependency Management: Rust components, particularly relating to WebGPU, introduce compilation problems on 32-bit architectures. Hardcoded assumptions about data sizes within these dependencies add another layer of complexity.
* Evolving Web Technologies: The increasing size and complexity of modern web applications are discussed. These trends put strain on browsers, leading to compromised performance and user experience, even on capable hardware.
Debugging and Workarounds
* Error Analysis: While crash reports and warnings are reviewed, their utility is limited by the project's size and convoluted dependencies.
* Potential Patches: The developer contemplates patching third-party Rust code to enable 32-bit atomic operations, a workaround necessary due to fixed assumptions embedded within that codebase.
* Build Configurations: Experimenting with alternative build settings is pursued. This includes selectively excluding platform-specific components to pinpoint compatibility issues.
Conclusion
This transcript illuminates the persistent challenges in ensuring cross-platform performance for large, legacy software projects, particularly amidst evolving technology stacks. It highlights the crucial need for streamlined architectural design and a stronger emphasis on long-term code maintainability within complex software development initiatives.
Why would they need to care about the size of the atomics?
Atomics are built-in to C and C++.
intmax_t, intptr_t, size_t, ssize_t…
If they could even have a donitional for INTMAX_MAX to detarmin if they can use a type or not…
I've found bugs by compiling on x86 that I could not find on x86_64.