)]}'
{
  "commit": "cdccbe121fa5dc8c6df7102eaedb62c99eec8273",
  "tree": "e2777fa96263e04540cd8a5a7336e7fe832fa0df",
  "parents": [
    "7cb90e092f2eee7dde7fd73ea39fb491123554f6"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Sat Nov 19 10:15:55 2022 -0500"
  },
  "committer": {
    "name": "Boringssl LUCI CQ",
    "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "time": "Thu Dec 08 21:30:05 2022 +0000"
  },
  "message": "Fully condition all assembly files.\n\nFor the C files, rather than force the caller to juggle\ncrypto_linux_sources, etc., we just wrap the whole file in ifdefs and\nask the callers to link everything together.\n\nAssembly is typically built by a different tool, so we have less room\nhere. However, there are really only two families of tools we care\nabout: gas (which runs the C preprocessor) and nasm (which has its own\npreprocessor). Callers should be able to limit themselves to\nspecial-casing Windows x86(_64) for NASM and then pass all the remaining\nassembly files to their gas-like tool. File-wide ifdefs can take care of\nthe rest.\n\nWe\u0027re almost set up to allow this, except the files condition on\narchitecture, but not OS. Add __ELF__, __APPLE__, and _WIN32 conditions\nas appropriate.\n\nOne subtlety: the semantics of .note.GNU-stack are that *any* unmarked\nobject file makes the stack executable. (In current GNU ld. lld doesn\u0027t\nhave this issue, and GNU ld claims they\u0027ll remove it in a later\nrelease.) Empirically, this doesn\u0027t seem to apply to empty object files\nbut, to be safe, we should ensure all object files have the marking.\n\nThat leads to a second subtlety: on targets where @ is a comment,\n@progbits is spelled %progbits, per [0]. If we want all .S files to work\nin all targets, that includes these markers. Fortunately, %progbits\nappears to work universally (see [1], [2], [3], [4]), so I\u0027ve just\nswitched us to that spelling.\n\nI\u0027ve also tightened up the __arm__ and __aarch64__ checks to __ARMEL__\nand __AARCH64EL__. We don\u0027t support big-endian Arm (or any other\nplatform) and, even if we did, the conditions in the assembly files\nshould match the conditions in the C files that pull them in.\n\nThis CL doesn\u0027t change our build to take advantage of this (though I\u0027ll\ngive it a go later), just makes it possible for builds to do it.\n\n[0] https://sourceware.org/binutils/docs/as/Section.html\n[1] https://patchwork.kernel.org/project/linux-crypto/patch/20170119212805.18049-1-dvlasenk@redhat.com/#20050285\n[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id\u003d92820#c11\n[3] https://sourceware.org/legacy-ml/gdb-patches/2016-01/msg00319.html\n[4] https://github.com/llvm/llvm-project/commit/de990b270d73632a834cb37e6ea50db093321aad\n\nBug: 542\nChange-Id: I0a8ded24423087c0da13bd0335cbd757d4eee65a\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55626\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "41bc0c6e86285dd4012bfaf87ceb0a95c378c066",
      "old_mode": 33188,
      "old_path": "crypto/curve25519/asm/x25519-asm-arm.S",
      "new_id": "ab84c104be6fc98918803f8400ce939247668263",
      "new_mode": 33188,
      "new_path": "crypto/curve25519/asm/x25519-asm-arm.S"
    },
    {
      "type": "modify",
      "old_id": "c37d7d0b4d361d711cd0ba5d63c8f8f0e215cee0",
      "old_mode": 33188,
      "old_path": "crypto/hrss/asm/poly_rq_mul.S",
      "new_id": "2b410fe5ff4f4b1293776e84c5c2a22ce61fc4ab",
      "new_mode": 33188,
      "new_path": "crypto/hrss/asm/poly_rq_mul.S"
    },
    {
      "type": "modify",
      "old_id": "c000e020a5d3bbc49bf5f60230f345e3e7d957d6",
      "old_mode": 33261,
      "old_path": "crypto/perlasm/arm-xlate.pl",
      "new_id": "e876c8b27367346552da24439e108b0d8881b195",
      "new_mode": 33261,
      "new_path": "crypto/perlasm/arm-xlate.pl"
    },
    {
      "type": "modify",
      "old_id": "fff9c004fab6e1549a7d1ed0e18da8ba08db3269",
      "old_mode": 33188,
      "old_path": "crypto/perlasm/ppc-xlate.pl",
      "new_id": "1c51577ed80462a1c1b571cac23813dbb583e979",
      "new_mode": 33188,
      "new_path": "crypto/perlasm/ppc-xlate.pl"
    },
    {
      "type": "modify",
      "old_id": "e3745f898a285826c2ab0905bbb0ddfaeb6b5660",
      "old_mode": 33261,
      "old_path": "crypto/perlasm/x86_64-xlate.pl",
      "new_id": "1b1e793f3d3354321f1ea8f48762d9fff4ebb881",
      "new_mode": 33261,
      "new_path": "crypto/perlasm/x86_64-xlate.pl"
    },
    {
      "type": "modify",
      "old_id": "c22421f9ac75f5d1364b708852bfd03ec0692893",
      "old_mode": 33188,
      "old_path": "crypto/perlasm/x86asm.pl",
      "new_id": "743c79288dabb69f43546d3d1a58665b5da614b8",
      "new_mode": 33188,
      "new_path": "crypto/perlasm/x86asm.pl"
    },
    {
      "type": "modify",
      "old_id": "80a4b31faa882330af78aa5bf1b74f5649b66db8",
      "old_mode": 33188,
      "old_path": "crypto/poly1305/poly1305_arm_asm.S",
      "new_id": "7895ab49dabaffda26cfa95d29cf97d1bdda512c",
      "new_mode": 33188,
      "new_path": "crypto/poly1305/poly1305_arm_asm.S"
    }
  ]
}