mirror of
https://github.com/capstone-engine/llvm-capstone.git
synced 2024-12-03 19:32:35 +00:00
655bea4226
Per the comments, `hash_code` values "are not stable to save or persist", so are unsuitable for the module hash, which must persist across compilations for the implicit module hashes to match. Note that in practice, today, `hash_code` are stable. But this is an implementation detail, with a clear `FIXME` indicating we should switch to a per-execution seed. The stability of `MD5` also allows modules cross-compilation use-cases. The `size_t` underlying storage for `hash_code` varying across platforms could cause mismatching hashes when cross-compiling from a 64bit target to a 32bit target. Note that native endianness is still used for the hash computation. So hashes will differ between platforms of different endianness. Reviewed By: jansvoboda11 Differential Revision: https://reviews.llvm.org/D102943
21 lines
760 B
C++
21 lines
760 B
C++
//===-- ModuleFileExtension.cpp - Module File Extensions ------------------===//
|
|
//
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
|
//
|
|
//===----------------------------------------------------------------------===//
|
|
#include "clang/Serialization/ModuleFileExtension.h"
|
|
#include "llvm/ADT/Hashing.h"
|
|
using namespace clang;
|
|
|
|
char ModuleFileExtension::ID = 0;
|
|
|
|
ModuleFileExtension::~ModuleFileExtension() {}
|
|
|
|
void ModuleFileExtension::hashExtension(ExtensionHashBuilder &HBuilder) const {}
|
|
|
|
ModuleFileExtensionWriter::~ModuleFileExtensionWriter() {}
|
|
|
|
ModuleFileExtensionReader::~ModuleFileExtensionReader() {}
|