[llvm] [BinaryFormat] Add "SFrame" structures and constants (PR #147264)
Pavel Labath via llvm-commits
llvm-commits at lists.llvm.org
Wed Jul 9 11:00:11 PDT 2025
================
@@ -0,0 +1,98 @@
+//===- SFrameTest.cpp -----------------------------------------------------===//
+//
+// 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 "llvm/BinaryFormat/SFrame.h"
+#include "gtest/gtest.h"
+
+using namespace llvm;
+using namespace llvm::sframe;
+
+namespace {
+// Test structure sizes and triviality.
+static_assert(std::is_trivial_v<sframe_preamble>);
+static_assert(sizeof(sframe_preamble) == 4);
----------------
labath wrote:
I think I'm starting to warm up to the idea of templatizing the parser on the endianness. The FDEs could be nicely exposed as something like `ArrayRef<FDE<Endian>>`. FREs have a variable length, which makes that trickier, but they're also quite small, so maybe it's better to just copy them -- I'll see how the code looks like.
Which then brings up a followup question: Would you be okay with defining a single set of endian-aware types in the BinaryFormat library? I'd like to avoid the ELF duplication which has one set of types in BinaryFormat and another in Object.
Regarding the linker, I guess we'll see how it goes. I would hope that we can reuse at least some part of the parsing code there (naively, I would hope that we can separate the part about parsing the format from the one which resolves relocations), but I also don't know much about that part of the code base.
https://github.com/llvm/llvm-project/pull/147264
More information about the llvm-commits
mailing list