aboutsummaryrefslogtreecommitdiff
path: root/util/check_stack.go
AgeCommit message (Collapse)AuthorFilesLines
2023-04-25Re-add go:build ignore linesDavid Benjamin1-0/+2
This reverts commit bab2f96e2637acb107fe9b099c58befbca918748. This clears the sea of red in my editor. Change-Id: I600ef6c36556fb526da729f0f0d8bc69db5c5a08 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59186 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2023-02-16Revert go:build ignore linesDavid Benjamin1-2/+0
This convention seems to break with some other tooling we have. Until we figure out how to resolve that, remove the lines. This partially reverts 54b04fdc21d540a6e24f9ddb7ddc3e583518e24f but keeps the fixes to the license header comments. Change-Id: I4f08a9f3daf65d17b4c78ac6f4ac3de234ec3436 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57366 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com> Auto-Submit: David Benjamin <davidben@google.com>
2023-01-31Mark standalone Go scripts with go:build ignoreDavid Benjamin1-0/+2
gopls currently litters our project with a sea of red, because it assumes Go files are part of a package, but we have a lot of standalone Go scripts. (If there are C files in the same directory as the script, it gets upset about cgo. If there are multiple standalone scripts in the same directory, it gets uspet about duplicate files.) Per https://github.com/golang/go/issues/49657 and https://github.com/golang/tools/blob/master/gopls/doc/settings.md#standalonetags-string, the convention seems to be a go:build ignore tag. Newer versions of gopls run in a "standalone" mode, so we still get all the nice LSP features. As part of this, I had to align the license header comments from /* block comments */ to // line comments. Go build constraints can only be preceded by blank lines and line comments. Block comments apparently aren't allowed. (See https://pkg.go.dev/cmd/go#hdr-Build_constraints.) If I leave the file unconverted, go fmt will immediately move the comment to above the license block. Change-Id: I47c69255522e9aae2bdb97a6e83fcc6ce0cf29d5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56525 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com> Auto-Submit: David Benjamin <davidben@google.com>
2022-12-09Add a tool to check whether a binary has an executable stackDavid Benjamin1-0/+45
Plan is: 1. This CL 2. Update the CI/CQ recipe to be able to run this 3. Update the CI/CQ config to enable this on ELF platforms 4. Do not land, but patch out the .note.GNU-stack annotations and -Wa,--noexecstack and confirm CI/CQ fails. Based on manual testing and https://crbug.com/boringssl/292#c4, I anticipate we'll only have coverage on x86 and x86_64 Linux. Currently, our only Arm Linux builders are Android, which use the LLVM linker. The LLVM linker doesn't have this design flaw, so it doesn't need .note.GNU-stack in the first place. It also sounds like GNU ld will make this moot in a future release. 5. Remove -Wa,--noexecstack from crypto/CMakeLists.txt and confirm CI/CQ still passes. Other than generally wanting to test things, the immediate motivation is https://boringssl-review.googlesource.com/c/boringssl/+/55626/1/crypto/perlasm/arm-xlate.pl#b246 Bug: 292 Change-Id: Id1c049bfc2b4e8b7e2c8c32ea6456733a588dfe1 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55645 Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: Bob Beck <bbe@google.com>