Difference between revisions of "Porting/Chromium/BE"

Revision as of 12:05, 2 October 2018

Changes required to Chromium to work on big endian

Skia

- Chromium assumes that the pixel format, when viewed as a 32-bit word, is either ARGB or ABGR. However, third_party/skia/include/core/SkImageInfo.h contains a check that the pixel format, when viewed as four 8-bit bytes, is either BGRA or RGBA. Hence either this check needs to be relaxed (Maybe it is bogus in the first place? The comments talk about "native ARGB 32-bit", yet the test goes out of its way to test the ordering as bytes and not as 32-bit words), or Chromium needs to learn about a different pixel format.

Datapack
- ui/base/resource/data_pack.cc
- Need to byteswap metadata on input (resource file format is specified to use LE)
- chrome/browser/themes/browser_theme_pack.cc
- "datapack assumes little endian"
Net
- net/cert/crl_set.cc
- "assumes little endian"
- components/safe_browsing/db/v4_rice.cc
- #error The code below assumes little-endianness.
Media
- media/ffmpeg/ffmpeg_common.cc and media/formats/mp4/box_definitions.cc
- #error The code below assumes little-endianness.
- media/renderers/paint_canvas_video_renderer.cc
- Depending on choice of Skia pixel format, a new LIBYUV mapping set may be needed (see also third_party/libyuv below).
I18N
- base/i18n/icu_util.cc
- Needs to use "icudtb.dat" instead of "icudtl.dat" on BE
Sandbox
- sandbox/linux/system_headers/linux_seccomp.h
- The definition of the big endian variant is incorrect (contains a bogus "__AUDIO_ARCH_BE"). Also, it would be better to define two different macros AUDIT_ARCH_PPC64 and AUDIT_ARCH_PPC64LE (because that is how it actually looks in <linux/audit.h>), and choose the correct one in sandbox/linux/bpf_dsl/seccomp_macros.h instead.
third_party/skia
- include/private/GrTypesPriv.h
- #error "Skia gpu currently assumes little endian"
- src/opts/Sk4px_none.h
- Sk4px::alphas, Sk4px::zeroAlphas, Sk4px::zeroColors: "This method assumes little-endian."
- src/opts/SkXfermode_opts.h
- a_rgb assumes specific component order
- src/utils/SkJSON.cpp and src/utils/SkJSON.h
- Tagged value implementation needs to be adapted for BE
third_party/boringssl/src
- crypto/fipsmodul/bn/bytes.c
- Bignum I/O functions need adaption for BE
third_party/blink
- renderer/platform/graphics/gpu/webgl_image_conversion.cc
- Does contain BE support, but a variable rename refactoring is missing from the BE code
- renderer/platform/graphics/logging_canvas.cc
- Does contain BE support, but a variable rename refactoring is missing from the BE code
- renderer/platform/image-decoders/jpeg/jpeg_image_decoder.cc
- #error Blink assumes a little-endian target.
- renderer/platform/image-decoders/webp/webp_image_decoder.cc
- #error Blink assumes a little-endian target.
third_party/perfetto
- src/ipc/buffered_frame_deserializer.cc, src/ipc/buffered_frame_deserializer_unittest.cc
- Uses "AssumeLittleEndian" template
- src/protozero/message.cc
- float and double handling need adjusting for BE (accoring to comment)
- src/protozero/proto_decoder.cc
- Byteswap implementations missing
third_party/ffmpeg
- chromium/scripts/build_ffmpeg.py
- Needs to recognize 'ppc64' as well as 'ppc64le'
third_party/webrtc
- common_audio/wav_file.cc
- WavReader::ReadSamples and WavWriter::WriteSamples need to byteswap the samples
- common_audio/wav_header.cc
- Conversion functions missing
third_party/modp_b64
- BUILD.gn
- modp_b64 actually supports BE, but in converting to their own build system Google managed to lose the check to define WORDS_BIGENDIAN
- modp_b64.cc
- The prototype of modp_b64_decode needs to be updated to use size_t instead of int for the lengths, as it has been done for the LE variant
third_party/libvpx

- The build system should move VSX-specific sources into a separate source set, and set the cflags "-maltivec -mvsx" for it. In the original build system the cflags were set based on a glob of the source filename, but in Googles build system it has to be done manually.

third_party/libyuv

- Depending on choice of Skia pixel format, additional conversion function variants may be needed

@@ Line 1: / Line 1: @@
 == Changes required to Chromium to work on big endian ==
+* Skia
+:- Chromium assumes that the pixel format, when viewed as a 32-bit word, is either ARGB or ABGR.  However, third_party/skia/include/core/SkImageInfo.h contains a check that the pixel format, when viewed as four 8-bit bytes, is either BGRA or RGBA.  Hence either this check needs to be relaxed (Maybe it is bogus in the first place? The comments talk about "native ARGB 32-bit", yet the test goes out of its way to test the ordering as bytes and not as 32-bit words), or Chromium needs to learn about a different pixel format.
+* Datapack
+** ui/base/resource/data_pack.cc
+*:- Need to byteswap metadata on input (resource file format is specified to use LE)
+** chrome/browser/themes/browser_theme_pack.cc
+*:- "datapack assumes little endian"
+* Net
+** net/cert/crl_set.cc
+*:- "assumes little endian"
+** components/safe_browsing/db/v4_rice.cc
+*:- #error The code below assumes little-endianness.
+* Media
+** media/ffmpeg/ffmpeg_common.cc and media/formats/mp4/box_definitions.cc
+*:- #error The code below assumes little-endianness.
+** media/renderers/paint_canvas_video_renderer.cc
+*:- Depending on choice of Skia pixel format, a new LIBYUV mapping set may be needed (see also third_party/libyuv below).
+* I18N
+** base/i18n/icu_util.cc
+*:- Needs to use "icudtb.dat" instead of "icudtl.dat" on BE
 * Sandbox
 ** sandbox/linux/system_headers/linux_seccomp.h
 *:- The definition of the big endian variant is incorrect (contains a bogus "__AUDIO_ARCH_BE").  Also, it would be better to define two different macros AUDIT_ARCH_PPC64 and AUDIT_ARCH_PPC64LE (because that is how it actually looks in <linux/audit.h>), and choose the correct one in sandbox/linux/bpf_dsl/seccomp_macros.h instead.
-* Safe browsing
-** components/safe_browsing/db/v4_rice.cc
-*:- #error The code below assumes little-endianness.
 * third_party/skia
 ** include/private/GrTypesPriv.h
@@ Line 19: / Line 36: @@
 ** crypto/fipsmodul/bn/bytes.c
 *:- Bignum I/O functions need adaption for BE
+* third_party/blink
+** renderer/platform/graphics/gpu/webgl_image_conversion.cc
+*:- Does contain BE support, but a variable rename refactoring is missing from the BE code
+** renderer/platform/graphics/logging_canvas.cc
+*:- Does contain BE support, but a variable rename refactoring is missing from the BE code
+** renderer/platform/image-decoders/jpeg/jpeg_image_decoder.cc
+*:- #error Blink assumes a little-endian target.
+** renderer/platform/image-decoders/webp/webp_image_decoder.cc
+*:- #error Blink assumes a little-endian target.
 * third_party/perfetto
 ** src/ipc/buffered_frame_deserializer.cc, src/ipc/buffered_frame_deserializer_unittest.cc
@@ Line 34: / Line 60: @@
 ** common_audio/wav_header.cc
 *:- Conversion functions missing
+* third_party/modp_b64
+** BUILD.gn
+*:- modp_b64 actually supports BE, but in converting to their own build system Google managed to lose the check to define WORDS_BIGENDIAN
+** modp_b64.cc
+*:- The prototype of modp_b64_decode needs to be updated to use size_t instead of int for the lengths, as it has been done for the LE variant
+* third_party/libvpx
+:- The build system should move VSX-specific sources into a separate source set, and set the cflags "-maltivec -mvsx" for it.  In the original build system the cflags were set based on a glob of the source filename, but in Googles build system it has to be done manually.
 * third_party/libyuv
 :- Depending on choice of Skia pixel format, additional conversion function variants may be needed

Difference between revisions of "Porting/Chromium/BE"

Revision as of 12:05, 2 October 2018

Changes required to Chromium to work on big endian

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Navigation

Tools

Print/export