|
Revision tags: llvmorg-21-init, llvmorg-19.1.7 |
|
| #
cfe26358 |
| 11-Jan-2025 |
Timm Baeder <tbaeder@redhat.com> |
Reapply "[clang] Avoid re-evaluating field bitwidth" (#122289)
|
| #
59bdea24 |
| 08-Jan-2025 |
Timm Bäder <tbaeder@redhat.com> |
Revert "[clang] Avoid re-evaluating field bitwidth (#117732)"
This reverts commit 81fc3add1e627c23b7270fe2739cdacc09063e54.
This breaks some LLDB tests, e.g.
SymbolFile/DWARF/x86/no_unique_address-
Revert "[clang] Avoid re-evaluating field bitwidth (#117732)"
This reverts commit 81fc3add1e627c23b7270fe2739cdacc09063e54.
This breaks some LLDB tests, e.g.
SymbolFile/DWARF/x86/no_unique_address-with-bitfields.cpp:
lldb: ../llvm-project/clang/lib/AST/Decl.cpp:4604: unsigned int clang::FieldDecl::getBitWidthValue() const: Assertion `isa<ConstantExpr>(getBitWidth())' failed.
show more ...
|
| #
81fc3add |
| 08-Jan-2025 |
Timm Baeder <tbaeder@redhat.com> |
[clang] Avoid re-evaluating field bitwidth (#117732)
Save the bitwidth value as a `ConstantExpr` with the value set. Remove
the `ASTContext` parameter from `getBitWidthValue()`, so the latter
simply
[clang] Avoid re-evaluating field bitwidth (#117732)
Save the bitwidth value as a `ConstantExpr` with the value set. Remove
the `ASTContext` parameter from `getBitWidthValue()`, so the latter
simply returns the value from the `ConstantExpr` instead of
constant-evaluating the bitwidth expression every time it is called.
show more ...
|
|
Revision tags: llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4 |
|
| #
dec6324c |
| 17-Nov-2024 |
Kazu Hirata <kazu@google.com> |
[AST] Remove unused includes (NFC) (#116549)
Identified with misc-include-cleaner.
|
|
Revision tags: llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3 |
|
| #
463790bf |
| 28-Apr-2022 |
Bill Wendling <isanbard@gmail.com> |
[randstruct] Randomize all elements of a record
A record may have more than just FieldDecls in it. If so, then we're
likely to drop them if we only randomize the FieldDecls.
We need to be careful a
[randstruct] Randomize all elements of a record
A record may have more than just FieldDecls in it. If so, then we're
likely to drop them if we only randomize the FieldDecls.
We need to be careful about anonymous structs/unions. Their fields are
made available in the RecordDecl as IndirectFieldDecls, which are listed
after the anonymous struct/union. The ordering doesn't appear to be
super important, however we place them unrandomized at the end of the
RecordDecl just in case. There's also the possiblity of
StaticAssertDecls. We also want those at the end.
All other non-FieldDecls we place at the top, just in case we get
something like:
struct foo {
enum e { BORK };
enum e a;
};
Link: https://github.com/KSPP/linux/issues/185
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D123958
show more ...
|
|
Revision tags: llvmorg-14.0.2 |
|
| #
8dbc6b56 |
| 22-Apr-2022 |
Nico Weber <thakis@chromium.org> |
Revert "[randstruct] Check final randomized layout ordering"
This reverts commit a7815d33bf8f955f2a1888abbccf974bd4858f79.
Test fails on Windows, see comments on https://reviews.llvm.org/D124199
|
| #
a7815d33 |
| 22-Apr-2022 |
Bill Wendling <isanbard@gmail.com> |
[randstruct] Check final randomized layout ordering
This uses "llvm::shuffle" to stop differences in shuffle ordering on
different platforms.
Reviewed By: MaskRay
Differential Revision: https://re
[randstruct] Check final randomized layout ordering
This uses "llvm::shuffle" to stop differences in shuffle ordering on
different platforms.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D124199
show more ...
|
| #
c98b601b |
| 14-Apr-2022 |
Fangrui Song <i@maskray.me> |
[randstruct] Fix -Wunused-but-set-variable with Clang>=D122271 in -DLLVM_ENABLE_ASSERTIONS=off builds
|
|
Revision tags: llvmorg-14.0.1 |
|
| #
7aa8c38a |
| 09-Apr-2022 |
Connor Kuehl <cipkuehl@gmail.com> |
[randstruct] Add randomize structure layout support
The Randstruct feature is a compile-time hardening technique that
randomizes the field layout for designated structures of a code base.
Admittedly
[randstruct] Add randomize structure layout support
The Randstruct feature is a compile-time hardening technique that
randomizes the field layout for designated structures of a code base.
Admittedly, this is mostly useful for closed-source releases of code,
since the randomization seed would need to be available for public and
open source applications.
Why implement it? This patch set enhances Clang’s feature parity with
that of GCC which already has the Randstruct feature. It's used by the
Linux kernel in certain structures to help thwart attacks that depend on
structure layouts in memory.
This patch set is a from-scratch reimplementation of the Randstruct
feature that was originally ported to GCC. The patches for the GCC
implementation can be found here:
https://www.openwall.com/lists/kernel-hardening/2017/04/06/14
Link: https://lists.llvm.org/pipermail/cfe-dev/2019-March/061607.html
Co-authored-by: Cole Nixon <nixontcole@gmail.com>
Co-authored-by: Connor Kuehl <cipkuehl@gmail.com>
Co-authored-by: James Foster <jafosterja@gmail.com>
Co-authored-by: Jeff Takahashi <jeffrey.takahashi@gmail.com>
Co-authored-by: Jordan Cantrell <jordan.cantrell@mail.com>
Co-authored-by: Nikk Forbus <nicholas.forbus@gmail.com>
Co-authored-by: Tim Pugh <nwtpugh@gmail.com>
Co-authored-by: Bill Wendling <isanbard@gmail.com>
Signed-off-by: Bill Wendling <isanbard@gmail.com>
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D121556
show more ...
|
| #
46b2a463 |
| 09-Apr-2022 |
Fangrui Song <i@maskray.me> |
[randstruct] Use llvm::shuffle to avoid STL impl difference after D121556
This reverts commit 2a2149c754f96376ddf8fed248102dd8e6092a22.
This reverts commit 8d7595be1dd41d7f7470ec90867936ca5e4e0d82.
[randstruct] Use llvm::shuffle to avoid STL impl difference after D121556
This reverts commit 2a2149c754f96376ddf8fed248102dd8e6092a22.
This reverts commit 8d7595be1dd41d7f7470ec90867936ca5e4e0d82.
This reverts commit e2e6899452998932b37f0fa9e66d104a02abe3e5.
If this doesn't work, I'll revert the whole thing.
show more ...
|
| #
3f0587d0 |
| 08-Apr-2022 |
Connor Kuehl <cipkuehl@gmail.com> |
[randstruct] Add randomize structure layout support
The Randstruct feature is a compile-time hardening technique that
randomizes the field layout for designated structures of a code base.
Admittedly
[randstruct] Add randomize structure layout support
The Randstruct feature is a compile-time hardening technique that
randomizes the field layout for designated structures of a code base.
Admittedly, this is mostly useful for closed-source releases of code,
since the randomization seed would need to be available for public and
open source applications.
Why implement it? This patch set enhances Clang’s feature parity with
that of GCC which already has the Randstruct feature. It's used by the
Linux kernel in certain structures to help thwart attacks that depend on
structure layouts in memory.
This patch set is a from-scratch reimplementation of the Randstruct
feature that was originally ported to GCC. The patches for the GCC
implementation can be found here:
https://www.openwall.com/lists/kernel-hardening/2017/04/06/14
Link: https://lists.llvm.org/pipermail/cfe-dev/2019-March/061607.html
Co-authored-by: Cole Nixon <nixontcole@gmail.com>
Co-authored-by: Connor Kuehl <cipkuehl@gmail.com>
Co-authored-by: James Foster <jafosterja@gmail.com>
Co-authored-by: Jeff Takahashi <jeffrey.takahashi@gmail.com>
Co-authored-by: Jordan Cantrell <jordan.cantrell@mail.com>
Co-authored-by: Nikk Forbus <nicholas.forbus@gmail.com>
Co-authored-by: Tim Pugh <nwtpugh@gmail.com>
Co-authored-by: Bill Wendling <isanbard@gmail.com>
Signed-off-by: Bill Wendling <isanbard@gmail.com>
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D121556
show more ...
|