)]}'
{
  "commit": "c3f4612d83f345ef0bb0024ce6086a6a773324ca",
  "tree": "e48034a4454acf2125cd795bb7b4a2c9b13a9478",
  "parents": [
    "eb57cc1e875d3137aa3cf723f3c525e253ddea9b"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Tue Dec 01 17:47:57 2020 -0500"
  },
  "committer": {
    "name": "CQ bot account: commit-bot@chromium.org",
    "email": "commit-bot@chromium.org",
    "time": "Tue Dec 01 23:49:03 2020 +0000"
  },
  "message": "Only accept little-endian ARM and MIPS variants in base.h.\n\n\u003copenssl/base.h\u003e checks for a supported platform, but we don\u0027t check\nendianness of ARM and MIPS, which are bi-endian. See\nhttps://crbug.com/1153312#c7.\n\nSwitch this around. Documentation on which define is \"official\" is hard\nto come by, so I mostly mimicked Chromium. Chromium detects\nlittle-endian ARM and MIPS with __ARMEL__ and __MIPSEL__ respectively,\nwithout looking at __arm__ or __mips__. It uses __aarch64__\ninstead of __AARCH64EL__, but I think that\u0027s an oversight. I can get\nClang to output for aarch64_be and that defines __aarch64__ with\n__AARCH64EB__.\n\n\u003copenssl/arm_arch.h\u003e (which we should simplify and align with base.h\nonce this CL sticks) also normalizes to __ARMEL__ over __BYTE_ORDER__\nand friends. Although, interestingly, arm_arch.h defines its own\n__ARMEL__ on GNUC aarch64, even though Clang does *not* define __ARMEL__\non aarch64. (I\u0027m guessing this aligned for the benefit of the \"armx\"\nbi-arch asm files.) This value is based on __BYTE_ORDER__, not\n__ARMEL__, but it assumes GNUC arm always defines __ARMEL__, so I think\nit\u0027s reasonable to assume GNUC aarch64 always defines __AARCH64EL__.\n\nGiven all this, probably the simplest thing that\u0027s most likely to work\nis to use __ARMEL__, __MIPSEL__, and __AARCH64EL__. Note this does not\nchange the _M_* checks. _M_* are Windows\u0027s definitions, which I think we\ncan reasonably assume come with an endianness opinion. (Windows\u0027 ARM and\nARM64 ABIs mandate little-endian.) This aligns with Chromium.\n\nUpdate-Note: CPU processor defines are a mess. If a little-endian ARM or\nMIPS build breaks, some of the assumptions above may be wrong. In that\ncase, the output $CC -dM -E - \u003c /dev/null on the offending toolchain\nwill be useful to fix it. If a big-endian ARM or MIPS build breaks, this\nis working as intended. Any resulting binaries weren\u0027t producing the\nright outputs.\n\nChange-Id: I2a9e662d09df119a71226e91716d84e7ac3792aa\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44324\nCommit-Queue: Adam Langley \u003cagl@google.com\u003e\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "474bb8bc72b1b60f02250cdcc993666fde2f9009",
      "old_mode": 33188,
      "old_path": "include/openssl/base.h",
      "new_id": "8e8cc15a93ef566386a098906cbaeb680147242f",
      "new_mode": 33188,
      "new_path": "include/openssl/base.h"
    }
  ]
}