@@ -110,20 +110,81 @@ static std::string computeBaseSysRoot(const Driver &D,
bool IncludeTriple) {
return std::string(SysRootDir);
}
+static bool hasGCCToolChainAlongSideClang(const Driver &D) {
+ SmallString<128> GCCDir;
+ llvm::sys::path::append(GCCDir, D.Dir, "..", D.g
https://github.com/smithp35 commented:
Apologies I've got a few more questions as I'm not sure I've understood.
https://github.com/llvm/llvm-project/pull/121829
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
@@ -110,20 +110,81 @@ static std::string computeBaseSysRoot(const Driver &D,
bool IncludeTriple) {
return std::string(SysRootDir);
}
+static bool hasGCCToolChainAlongSideClang(const Driver &D) {
smithp35 wrote:
> I am not aware if there is any common file
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/121829
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -110,20 +110,81 @@ static std::string computeBaseSysRoot(const Driver &D,
bool IncludeTriple) {
return std::string(SysRootDir);
}
+static bool hasGCCToolChainAlongSideClang(const Driver &D) {
+ SmallString<128> GCCDir;
+ llvm::sys::path::append(GCCDir, D.Dir, "..", D.g
smithp35 wrote:
> > I'm looking at this patch in isolation, so its possible that the comments
> > here are addressed elasewhere.
> > It looks like useful functionality to add to the bare metal driver.
> > It also looks like there is some scope for some documentation, for users
> > and for toolc
@@ -0,0 +1,12 @@
+// check that gnu assembler is invoked with arm baremetal as well
+
+// RUN: %clang --target=armv6m-none-eabi
--gcc-toolchain=%S/Inputs/basic_riscv32_tree -fno-integrated-as %s -### -c \
smithp35 wrote:
I'm a bit confused about this test. It i
@@ -110,20 +110,81 @@ static std::string computeBaseSysRoot(const Driver &D,
bool IncludeTriple) {
return std::string(SysRootDir);
}
+static bool hasGCCToolChainAlongSideClang(const Driver &D) {
smithp35 wrote:
IIUC this is when we have something like clan
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/121829
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/smithp35 commented:
I'm looking at this patch in isolation, so its possible that the comments here
are addressed elasewhere.
It looks like useful functionality to add to the bare metal driver.
It also looks like there is some scope for some documentation, for users and
for
@@ -110,20 +110,81 @@ static std::string computeBaseSysRoot(const Driver &D,
bool IncludeTriple) {
return std::string(SysRootDir);
}
+static bool hasGCCToolChainAlongSideClang(const Driver &D) {
+ SmallString<128> GCCDir;
+ llvm::sys::path::append(GCCDir, D.Dir, "..", D.g
@@ -239,12 +239,10 @@ static void getAArch64MultilibFlags(const Driver &D,
Result.push_back(BranchProtectionArg->getAsString(Args));
}
- if (Arg *AlignArg = Args.getLastArg(
- options::OPT_mstrict_align, options::OPT_mno_strict_align,
- options::OPT_mn
https://github.com/smithp35 approved this pull request.
LGTM, thanks for the update
https://github.com/llvm/llvm-project/pull/134099
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/134099
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/smithp35 commented:
I think it would be useful to mention in the Description that
-mno-unaligned-access and -mstrict-align are synonyms, and that we pass both
through so that the multilib.yaml file can select on either.
https://github.com/llvm/llvm-project/pull/134099
__
smithp35 wrote:
The AArch64 ABI doesn't currently document an equivalent of `__aeabi_read_tp`
largely because in the 32-bit world not all targets have a dedicated
thread-pointer register.
I've very recently made a pull request to document the AArch64 TLS ABI
https://github.com/ARM-software/ab
@@ -14,18 +14,18 @@
// RUN: FileCheck -check-prefix=ARMv7_THREAD_POINTER-TPIDRPRW %s
// ARMv7_THREAD_POINTER-TPIDRPRW: "-target-feature" "+read-tp-tpidrprw"
-// RUN: %clang --target=armv6t2-linux -mtp=cp15 -### -S %s 2>&1 | \
-// RUN: FileCheck -check-prefix=ARM_THREAD_POINTER
@@ -240,7 +247,7 @@ arm::ReadTPMode arm::getReadTPMode(const Driver &D, const
ArgList &Args,
D.Diag(diag::err_drv_invalid_mtp) << A->getAsString(Args);
return ReadTPMode::Invalid;
}
- return (isHardTPSupported(Triple) ? ReadTPMode::TPIDRURO : ReadTPMode::Soft);
+
https://github.com/smithp35 commented:
I assume this is a rewrite of https://github.com/llvm/llvm-project/pull/128728
It looks like we've lost an explicit ``-mtp=auto``. I think that part is
important, my apologies if my earlier comment implied that we should remove it.
I've made a suggestion
@@ -239,7 +239,7 @@ arm::ReadTPMode arm::getReadTPMode(const Driver &D, const
ArgList &Args,
D.Diag(diag::err_drv_invalid_mtp) << A->getAsString(Args);
return ReadTPMode::Invalid;
}
- return ReadTPMode::Soft;
+ return (isHardTPSupported(Triple) ? ReadTPMode::TPID
@@ -42,4 +42,4 @@
// RUN: %clang --target=armv7-linux -### -S %s 2>&1 | \
// RUN: FileCheck -check-prefix=ARMv7_THREAD_POINTER_NON %s
-// ARMv7_THREAD_POINTER_NON-NOT: "-target-feature" "+read-tp-tpidruro"
+// ARMv7_THREAD_POINTER_NON: "-target-feature" "+read-tp-tpidruro"
---
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/128901
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
smithp35 wrote:
A couple of things I forgot to mention:
* Please can you update the in progress ReleaseNotes in
https://github.com/llvm/llvm-project/blob/main/clang/docs/ReleaseNotes.rst as
this is a potentially breaking change.
* It is fine to add `fixes https://github.com/llvm/llvm-project/is
@@ -580,6 +581,9 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver
&D,
Features.push_back("+read-tp-tpidruro");
smithp35 wrote:
We're calling getReadTPMode 4 times now, with the same parameters. and I don't
think it can return a different value
@@ -239,7 +240,7 @@ arm::ReadTPMode arm::getReadTPMode(const Driver &D, const
ArgList &Args,
D.Diag(diag::err_drv_invalid_mtp) << A->getAsString(Args);
return ReadTPMode::Invalid;
}
- return ReadTPMode::Soft;
+ return ReadTPMode::Auto;
smithp35 w
@@ -580,6 +581,9 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver
&D,
Features.push_back("+read-tp-tpidruro");
if (getReadTPMode(D, Args, Triple, ForAS) == ReadTPMode::TPIDRPRW)
Features.push_back("+read-tp-tpidrprw");
+ if (getReadTPMode(D, Args, Triple
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/128728
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/smithp35 commented:
As statham-arm points out, please do replace the [FIXME]s in the description.
The first one is tpidruro, you can probably find the GCC version from the
changelog.
https://github.com/llvm/llvm-project/pull/128728
=?utf-8?q?Csanád_Hajdú?=
Message-ID:
In-Reply-To:
https://github.com/smithp35 approved this pull request.
LGTM. Thanks for updating the code and test to account for Multilib. Apologies
for missing this last week.
Please leave some time for other reviewers to comment before merging.
https://
@@ -0,0 +1,6 @@
+// RUN: %clang --sysroot=%S/Inputs -c -fdriver-only -Werror
--target=aarch64-unknown-linux-gnu \
smithp35 wrote:
Can you check that this test still passes with a aarch64-none-elf bare-metal
target?
There's a !ForMultilib in the ARM code
https
@@ -16,7 +16,7 @@
// RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s
-flto=thin -c -o %t.call_thin.bc -DCALL_LIB
// RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s
-flto=thin -c -o %t.define_thin.bc -DDEFINE_LIB
-// RUN
@@ -16,7 +16,7 @@
// RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s
-flto=thin -c -o %t.call_thin.bc -DCALL_LIB
// RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s
-flto=thin -c -o %t.define_thin.bc -DDEFINE_LIB
-// RUN
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/111334
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -16,7 +16,7 @@
// RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s
-flto=thin -c -o %t.call_thin.bc -DCALL_LIB
// RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s
-flto=thin -c -o %t.define_thin.bc -DDEFINE_LIB
-// RUN
https://github.com/smithp35 commented:
Apologies for the delay in responding.
I don't have much to add over davemgreen and ostannard.
Leaving aside whether this should be an error in the front or back-end. As
mentioned before I haven't worked in this area for a long time, and there are
enough
smithp35 wrote:
> > front-end error/warning as this is a front-end/source-level mistake, with
> > better diagnostic control options available.
>
> There's a _lot_ of complicated logic required to determine, for each
> architecture, which target features affect the ABI in which ways. Are you
>
@@ -311,11 +311,15 @@ ARMBaseTargetMachine::getSubtargetImpl(const Function &F)
const {
// function that reside in TargetOptions.
resetTargetOptions(F);
I = std::make_unique(TargetTriple, CPU, FS, *this, isLittle,
-F.hasMinSi
https://github.com/smithp35 commented:
I'm not yet convinced that llvm is the right place for this error message.
There's quite a lot of test changes that I presume needed to make and at least
the LTO use case looks like we don't want to require extra information. I'd
also prefer this to be a
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/111334
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -459,9 +459,6 @@ def warn_drv_assuming_mfloat_abi_is : Warning<
def warn_drv_unsupported_float_abi_by_lib : Warning<
"float ABI '%0' is not supported by current library">,
InGroup;
-def warn_drv_no_floating_point_registers: Warning<
smithp35 wrote:
This
smithp35 wrote:
> This patch adds support for custom flags in the multilib YAML file.
>
> Details about this change can be found in this thread:
> https://discourse.llvm.org/t/rfc-multilib-custom-flags/81058
Apologies in advance for being a pain. Prior to commit, assuming that the RFC
has sta
smithp35 wrote:
Whatever we choose to do I think clang and llvm should be consistent. There's
no point in clang giving a warning if llvm is going to give an error.
I can see two positions most clearly:
* clang gives an error message for an eabihf target (or -mfloat-abi=hard). This
is what GCC
https://github.com/smithp35 approved this pull request.
Thanks for the updates. I don't have any more comments. I've approved the patch
on my side. Will be worth waiting for a bit to see if any other reviewers have
any feedback.
https://github.com/llvm/llvm-project/pull/110804
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/110804
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -217,15 +215,15 @@ struct MultilibSetSerialization {
template <> struct llvm::yaml::MappingTraits {
static void mapping(llvm::yaml::IO &io, MultilibSerialization &V) {
io.mapOptional("Dir", V.Dir);
-io.mapOptional("FatalError", V.FatalError);
+io.mapOptional("E
@@ -124,12 +124,11 @@ bool MultilibSet::select(const Driver &D, const
Multilib::flags_list &Flags,
}
// If this multilib is actually a placeholder containing a fatal
-// error message written by the multilib.yaml author, display that
-// error message, and ret
https://github.com/smithp35 commented:
Change looks good to me. A few small comment nits.
https://github.com/llvm/llvm-project/pull/110804
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commi
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/110804
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/smithp35 approved this pull request.
LGTM too, I've checked that the
`-DLIBCXX_STATICALLY_LINK_ABI_IN_STATIC_LIBRARY=ON` works. We, and other
bare-metal driver using toolchains can adopt that.
https://github.com/llvm/llvm-project/pull/101259
_
@@ -382,38 +382,6 @@ void BareMetal::AddClangCXXStdlibIncludeArgs(const ArgList
&DriverArgs,
}
}
-void BareMetal::AddCXXStdlibLibArgs(const ArgList &Args,
-ArgStringList &CmdArgs) const {
- switch (GetCXXStdlibType(Args)) {
- case ToolC
@@ -382,38 +382,6 @@ void BareMetal::AddClangCXXStdlibIncludeArgs(const ArgList
&DriverArgs,
}
}
-void BareMetal::AddCXXStdlibLibArgs(const ArgList &Args,
-ArgStringList &CmdArgs) const {
- switch (GetCXXStdlibType(Args)) {
- case ToolC
@@ -382,38 +382,6 @@ void BareMetal::AddClangCXXStdlibIncludeArgs(const ArgList
&DriverArgs,
}
}
-void BareMetal::AddCXXStdlibLibArgs(const ArgList &Args,
-ArgStringList &CmdArgs) const {
- switch (GetCXXStdlibType(Args)) {
- case ToolC
https://github.com/smithp35 approved this pull request.
After discussion in the PAuthABI call. We agreed that it would be best to have
an exemplar of how a signing schema for a platform should be encoded rather
than always using the individual options.
Anton mentioned that we can document that
https://github.com/smithp35 commented:
Does this need a clang command line option at this point? Would it be possible
to live with a {{-mllvm}} option to turn on signed GOT? I would expect signed
GOT (or not) would be part of a higher-level signing schema and not toggled at
a low-level via cla
https://github.com/smithp35 commented:
Apologies for the delay in responding, been a bit backed up. I like the idea of
pauthtest as it does give some leeway to change the signing schema.
I expect that with some work this could be made to work with bare-metal targets
too, but I think it is best
@@ -1546,16 +1581,28 @@ static void CollectARMPACBTIOptions(const ToolChain
&TC, const ArgList &Args,
CmdArgs.push_back(
Args.MakeArgString(Twine("-msign-return-address=") + Scope));
- if (Scope != "none")
+ if (Scope != "none") {
+if (Triple.getEnvironment() ==
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/97237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
smithp35 wrote:
I can't find a `-Wno-something-c++20-aggregate-init` in clang.
The closest I can find is
https://clang.llvm.org/docs/DiagnosticsReference.html#wc-20-compat which has a
text string
```
warning: aggregate initialization of type A with user-declared constructors is
incompatible
smithp35 wrote:
Apologies for the length of the post, it could probably do with more revisions
and research but I thought it better to send what I have and refine later after
comments. Most of this is a summation of a discussion had in the PAuthABI call,
followed by my attempts at analysing th
smithp35 wrote:
Apologies, it looks like I'm not going to get this out this morning, still
working on it.
https://github.com/llvm/llvm-project/pull/97237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/li
smithp35 wrote:
Apologies for the delay, I was out of office Thursday/Friday and wanted to
discuss some possible options on the Monday call. I'll write something up based
on the discussion tomorrow (Tuesday 9th) morning. I am at a conference for a
lot of the week, so I maybe a bit slower to re
https://github.com/smithp35 approved this pull request.
Thanks for the update LGTM. I've set approved, but please wait for a few days
to let other reviewers comment.
https://github.com/llvm/llvm-project/pull/97827
___
cfe-commits mailing list
cfe-comm
@@ -0,0 +1,4 @@
+// RUN: %clang --target=aarch64-none-elf -march=armv8.9-a+rcpc3
-print-multi-flags-experimental -c %s 2>&1 | FileCheck %s
+
smithp35 wrote:
I think it could be worth a comment here explaining what the test is checking
for as it would likely nee
@@ -0,0 +1,4 @@
+// RUN: %clang --target=aarch64-none-elf -march=armv8.9-a+rcpc3
-print-multi-flags-experimental -c %s 2>&1 | FileCheck %s
+
+// CHECK: -march=armv8.9-a
+// CHECK-SAME: +rcpc+rcpc3+
smithp35 wrote:
I'm wondering if a `CHECK-NOT ++` could be used
https://github.com/smithp35 commented:
A couple of comments on the test, but otherwise from the Arm and AArch64
feature modelling this looks good to me. I agree that we are not losing any
useful functionality by omitting implicit flags that have no command line value.
https://github.com/llvm/l
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/97827
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/smithp35 approved this pull request.
My apologies, I missed this one in my github mail folder.
LGTM, thanks for the update.
https://github.com/llvm/llvm-project/pull/97378
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/97237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/smithp35 commented:
I'm wondering if it is worth resurrecting
https://discourse.llvm.org/t/aarch64-pauthabi-options-for-command-line-options-to-use-the-pauthabi-and-set-signing-schema/73479
to see if we can get some more visibility on this. It has also been almost a
year sin
@@ -1537,11 +1570,16 @@ static void CollectARMPACBTIOptions(const ToolChain
&TC, const ArgList &Args,
if (!isAArch64 && PBP.Key == "b_key")
D.Diag(diag::warn_unsupported_branch_protection)
<< "b-key" << A->getAsString(Args);
+if (!isAArch64 && PBP.HasPa
@@ -1484,6 +1484,39 @@ void AddUnalignedAccessWarning(ArgStringList &CmdArgs) {
}
}
+static void handlePAuthABIOption(const ArgList &DriverArgs,
smithp35 wrote:
I think it will be worth a comment above and possibly inline explaining the ABI
implications of t
https://github.com/smithp35 commented:
As I understand it we are implicitly defining the default signing schema for
ELF platforms with `-mbranch-protection=pauthabi` .
Is there any thought on how we want to manage signing schemas going forward?
For example I can imagine looking an environment
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/97237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,25 @@
+// RUN: not %clang -### -c --target=x86_64 -Wa,--crel %s 2>&1 | FileCheck %s
--check-prefix=NOEXP
+
+// NOEXP: error: -Wa,--allow-experimental-crel must be specified to use
-Wa,--crel. CREL is experimental and takes a non-standard section type code
+
+// RUN: %
@@ -801,6 +801,9 @@ def warn_drv_missing_multilib : Warning<
def note_drv_available_multilibs : Note<
"available multilibs are:%0">;
+def err_drv_experimental_crel : Error<
+ "-Wa,--allow-experimental-crel must be specified to use -Wa,--crel. CREL is
experimental and takes
@@ -0,0 +1,25 @@
+// RUN: not %clang -### -c --target=x86_64 -Wa,--crel %s 2>&1 | FileCheck %s
--check-prefix=NOEXP
+
+// NOEXP: error: -Wa,--allow-experimental-crel must be specified to use
-Wa,--crel. CREL is experimental and takes a non-standard section type code
+
+// RUN: %
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/97378
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/smithp35 commented:
A few small comments, but otherwise looks good to me.
https://github.com/llvm/llvm-project/pull/97378
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com
https://github.com/smithp35 approved this pull request.
LGTM from me too.
https://github.com/llvm/llvm-project/pull/91280
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -123,6 +123,12 @@ class ContiguousBlobAccumulator {
return encodeULEB128(Val, OS);
}
+ unsigned writeSLEB128(int64_t Val) {
+if (!checkLimit(10))
smithp35 wrote:
I'm guessing 10 is from 64-bits extended to 10 groups of 7-bits extended to 8.
Unl
@@ -0,0 +1,180 @@
+# RUN: yaml2obj --docnum=1 %s -o %t
+# RUN: llvm-readobj -r %t | FileCheck %s --check-prefix=LLVM --match-full-lines
+# RUN: llvm-readelf -r %t | FileCheck %s --check-prefix=GNU --match-full-lines
+
+# LLVM: Relocations [
+# LLVM-NEXT: Section ([[#]]) .cr
@@ -3840,14 +3849,15 @@ void GNUELFDumper::printRelRelaReloc(const
Relocation &R,
template
static void printRelocHeaderFields(formatted_raw_ostream &OS, unsigned SType,
- const typename ELFT::Ehdr &EHeader) {
+
@@ -0,0 +1,18 @@
+# REQUIRES: powerpc-registered-target
+## Test CREL for a 32-bit big-endian target.
smithp35 wrote:
AIUI from
https://example61560.wordpress.com/wp-content/uploads/2016/11/powerpc_abi.pdf
Power PC uses RELA relocations. Would it be worth testi
@@ -1278,29 +1285,69 @@ void ELFState::writeSectionContent(
if (!Section.Relocations)
return;
+ const bool IsCrel = Section.Type == llvm::ELF::SHT_CREL;
const bool IsRela = Section.Type == llvm::ELF::SHT_RELA;
+ typename ELFT::uint OffsetMask = 8, Offset = 0, Addend
@@ -86,6 +86,8 @@ DYNAMIC_TAG(RELRSZ, 35) // Size of Relr relocation table.
DYNAMIC_TAG(RELR, 36)// Address of relocation table (Relr entries).
DYNAMIC_TAG(RELRENT, 37) // Size of a Relr relocation entry.
+DYNAMIC_TAG(CREL, 38) // CREL relocation table
+
--
@@ -32,12 +32,17 @@ FileHeader:
# RUN: --match-full-lines --check-prefixes=GNU-RELOCS,GNU-PLTRELA
# LLVM-RELOCS: Dynamic Relocations {
+# LLVM-RELOCS-NEXT: 0x8 R_X86_64_64 foo 0x0
# LLVM-RELOCS-NEXT: 0x1 R_X86_64_NONE foo 0x0
# LLVM-RELOCS-NEXT: 0x2 R_X86_64_N
@@ -1278,29 +1285,69 @@ void ELFState::writeSectionContent(
if (!Section.Relocations)
return;
+ const bool IsCrel = Section.Type == llvm::ELF::SHT_CREL;
const bool IsRela = Section.Type == llvm::ELF::SHT_RELA;
+ typename ELFT::uint OffsetMask = 8, Offset = 0, Addend
@@ -0,0 +1,100 @@
+# RUN: llvm-mc -filetype=obj -crel -triple=x86_64 %s -o %t.o
+# RUN: llvm-readelf -Sr -x .crelrodata2 -x .crelrodata16 %t.o | FileCheck %s
+
+# RUN: %if aarch64-registered-target %{ llvm-mc -filetype=obj -crel
-triple=aarch64_be %s -o %t.be.o %}
+# RUN: %if aar
@@ -934,10 +943,51 @@ void ELFWriter::WriteSecHdrEntry(uint32_t Name, uint32_t
Type, uint64_t Flags,
WriteWord(EntrySize); // sh_entsize
}
+template
+static void encodeCrel(ArrayRef Relocs, raw_ostream &os) {
+ uint OffsetMask = 8, Offset = 0, Addend = 0;
+ uint32_t Symi
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/91280
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/smithp35 commented:
I've finished going through the patches now. Apologies for the delay.
I don't think I have too many substantive comments. Overall this looks like it
implements the specification as described in the confluence page.
https://github.com/llvm/llvm-project/pul
https://github.com/smithp35 approved this pull request.
I think it is reasonable to proceed given the RFC and the response.
https://github.com/llvm/llvm-project/pull/91082
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c
@@ -1022,6 +1027,40 @@ ELFObjectFile::section_rel_begin(DataRefImpl Sec)
const {
uintptr_t SHT = reinterpret_cast((*SectionsOrErr).begin());
RelData.d.a = (Sec.p - SHT) / EF.getHeader().e_shentsize;
RelData.d.b = 0;
+ if (reinterpret_cast(Sec.p)->sh_type == ELF::SHT_CRE
@@ -1142,6 +1193,13 @@ ELFObjectFile::getRela(DataRefImpl Rela) const {
return *Ret;
}
+template
smithp35 wrote:
Is there any way this can be called before Crels has been populated? If not
then please ignore the rest of the comment.
It looks like getRelo
@@ -446,6 +450,7 @@ template class ELFObjectFile : public
ELFObjectFileBase {
const Elf_Rel *getRel(DataRefImpl Rel) const;
const Elf_Rela *getRela(DataRefImpl Rela) const;
+ Elf_Crel getCrel(DataRefImpl Rel) const;
smithp35 wrote:
Perhaps use CRel as
@@ -292,6 +293,9 @@ template class ELFObjectFile : public
ELFObjectFileBase {
const Elf_Shdr *DotSymtabSec = nullptr; // Symbol table section.
const Elf_Shdr *DotSymtabShndxSec = nullptr; // SHT_SYMTAB_SHNDX section.
+ // Hold CREL relocations for SectionRef::relocation
@@ -1117,9 +1166,11 @@ void ELFObjectFile::getRelocationTypeName(
template
Expected
ELFObjectFile::getRelocationAddend(DataRefImpl Rel) const {
- if (getRelSection(Rel)->sh_type != ELF::SHT_RELA)
-return createError("Section is not SHT_RELA");
- return (int64_t)getRela(R
@@ -321,6 +321,11 @@ class ELFFile {
std::vector decode_relrs(Elf_Relr_Range relrs) const;
+ uint64_t crelHeader(ArrayRef Content) const;
+ using RelsOrRelas = std::pair, std::vector>;
smithp35 wrote:
There is an identically named type in LLD which has a
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/91280
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/smithp35 commented:
Some initial comments based on a read of the ELFObjectFile. I haven't got as
far as the test and tools.
One general thought is whether it is worth adding in some more constants. For
example:
```
if (B & 1)
```
Could be something like:
```
if (B & DeltaSym
1 - 100 of 160 matches
Mail list logo
