Author: psmith
Date: Thu May 17 06:17:33 2018
New Revision: 332606
URL: http://llvm.org/viewvc/llvm-project?rev=332606&view=rev
Log:
[AArch64] Correct inline assembly test case for S modifier [NFC]
The existing test for the AArch64 inline assembly constraint S uses the
A and L modifiers. These mo
Author: psmith
Date: Tue Oct 24 02:51:55 2017
New Revision: 316424
URL: http://llvm.org/viewvc/llvm-project?rev=316424&view=rev
Log:
[AArch64] Fix PR34625 -mtune without -mcpu should not set -target-cpu
When -mtune is used on AArch64 the -target-cpu is passed the value of the
cpu given to -mtune.
Author: psmith
Date: Mon Sep 3 05:36:32 2018
New Revision: 341312
URL: http://llvm.org/viewvc/llvm-project?rev=341312&view=rev
Log:
[Aarch64] Fix linker emulation for Aarch64 big endian
This patch fixes target linker emulation for aarch64 big endian.
aarch64_be_linux is not recognized by gnu ld.
Author: psmith
Date: Tue Oct 16 02:21:17 2018
New Revision: 344597
URL: http://llvm.org/viewvc/llvm-project?rev=344597&view=rev
Log:
[ARM][AArch64] Pass through endian flags to assembler and linker.
The big-endian arm32 Linux builds are currently failing when the
-mbig-endian flag is used but the
Author: psmith
Date: Mon Oct 22 03:40:52 2018
New Revision: 344890
URL: http://llvm.org/viewvc/llvm-project?rev=344890&view=rev
Log:
[ARM][AArch64] Add LLVM_FALLTHROUGH to silence warning [NFC]
A follow up to D52784 to add in LLVM_FALLTHROUGH where there is an
intentional fall through in a switch
This commit, specifically the changes made to
CodeGenCXX/cxx2a-three-way-comparison.cpp, are failing on all the Arm
and AArch64 builders that run check-clang and some of the other
non-X86 builders as well like S390 and PPC.
It seems to be the // RUN: not %clang_cc1 -std=c++2a -emit-llvm %s -o
- -t
Hello Erich,
The test added in this commit is failing on the Arm and Hexagon
builders. I think that this is because the expected type "long" in the
warning text is "int" on these platforms (possibly other 32-bit host
platforms).
The raw output from an Arm machine is:
llvm-project/clang/test/SemaC
Author: psmith
Date: Fri Sep 28 02:04:31 2018
New Revision: 343304
URL: http://llvm.org/viewvc/llvm-project?rev=343304&view=rev
Log:
[ARM] Alter test to account for change to armv6k default CPU
Review D52594 will change the default in llvm for armv6k from the
non-existent cpu arm1176jf-s to mpcor
Author: Peter Smith
Date: 2020-08-06T13:47:21+01:00
New Revision: 839d974ee0e45f09b9665b4eed734ca1ba174d25
URL:
https://github.com/llvm/llvm-project/commit/839d974ee0e45f09b9665b4eed734ca1ba174d25
DIFF:
https://github.com/llvm/llvm-project/commit/839d974ee0e45f09b9665b4eed734ca1ba174d25.diff
L
https://github.com/smithp35 commented:
I think it makes sense to reuse the field if we can save a flag. The potential
for someone to use the versionId as an index, or otherwise misuse it in the
future makes me a bit nervous.
A possible alternative is to use a different name for the versionId,
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/71272
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -316,9 +308,25 @@ class Symbol {
// This field is a index to the symbol's version definition.
uint16_t verdefIndex;
- // Version definition index.
- uint16_t versionId;
+ // Used by a Defined symbol with protected or default visibility, to record
+ // the verdef ind
@@ -321,9 +321,11 @@ void aarch64::getAArch64TargetFeatures(const Driver &D,
}
}
- if (Arg *A = Args.getLastArg(options::OPT_mno_unaligned_access,
- options::OPT_munaligned_access)) {
-if (A->getOption().matches(options::OPT_mno_unalign
https://github.com/smithp35 commented:
If possible I would prefer to keep -m[no-]unaligned-access for AArch64.
The history of this option name derives from Arm's proprietary compiler
https://developer.arm.com/documentation/dui0472/m/Compiler-Command-line-Options/--unaligned-accessno-unalign
smithp35 wrote:
> > If possible I would prefer to keep -m[no-]unaligned-access for AArch64.
> > The history of this option name derives from Arm's proprietary compiler
> > [developer.arm.com/documentation/dui0472/m/Compiler-Command-line-Options/--unaligned-accessno-unaligned-access](https://
smithp35 wrote:
Just to make sure I've understood:
* x86_64's support for constraint "s" was hoisted into the target independent
TargetLowering in https://reviews.llvm.org/D61560
* Clang's implementation of constraint "s" isn't restricted to non-PIC/non-PIE
like GCC's
* We can implement constr
smithp35 wrote:
Apologies managed to mess up my branch when trying to fix the typo. I'll try
and fix.
https://github.com/llvm/llvm-project/pull/80272
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listin
https://github.com/smithp35 closed
https://github.com/llvm/llvm-project/pull/80272
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
smithp35 wrote:
Apologies I'll send a new pull request with the typo fixed. Probably the
fastest thing to do than trying to get my local branch back into the same state
to recreate the additional commit.
https://github.com/llvm/llvm-project/pull/80272
__
https://github.com/smithp35 approved this pull request.
Thanks for the response. LGTM.
I think the RISCV inline-asm-S-constraint.ll is no longer necessary thanks to
#80201
https://github.com/llvm/llvm-project/pull/80255
___
cfe-commits mailing list
c
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/80255
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3,6 +3,7 @@
; RUN: llc -mtriple=riscv64 < %s | FileCheck %s --check-prefix=RV64
@var = external dso_local global i32, align 4
+@a = external global [2 x [2 x i32]], align 4
smithp35 wrote:
Did you mean to change this file in this PR? I think this change h
https://github.com/smithp35 approved this pull request.
Code changes LGTM too. I can't think of a case when a C/C++ compiler would
directly generate a reference to an SHN_ABS symbol as I don't think there is a
way of expressing such a symbol in C/C++ and debug generation concentrates on
descri
Stefan =?utf-8?q?Gränitz?= ,
Stefan =?utf-8?q?Gränitz?= ,
Stefan =?utf-8?q?Gränitz?=
Message-ID:
In-Reply-To:
smithp35 wrote:
> Thanks for your notes @smithp35. This worked out nicely! A test for Thumb B
> to Arm interworking is todo, because we need support for `R_ARM_THM_JUMP11`
> first. I
https://github.com/smithp35 commented:
I'm happy with this on the AArch64 side.
If clang for a target defaults to position independent code this may lead to
some -mcmodel=large projects failing to build, at least until they add -fno-pic
Could we add this to the release notes? Perhaps in the f
Author: KAWASHIMA Takahiro
Date: 2020-01-13T10:16:53Z
New Revision: 10c11e4e2d05cf0e8f8251f50d84ce77eb1e9b8d
URL:
https://github.com/llvm/llvm-project/commit/10c11e4e2d05cf0e8f8251f50d84ce77eb1e9b8d
DIFF:
https://github.com/llvm/llvm-project/commit/10c11e4e2d05cf0e8f8251f50d84ce77eb1e9b8d.diff
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/65966
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/smithp35 commented:
This will only fix the problem for AArch64, but it also affects other targets.
Assuming relocateAlloc is the best place to fix this, then it would need
applying in all instances of relocateAlloc.
https://github.com/llvm/llvm-project/pull/65966
___
@@ -770,6 +770,9 @@ void AArch64::relocateAlloc(InputSectionBase &sec, uint8_t
*buf) const {
uint64_t secAddr = sec.getOutputSection()->addr;
if (auto *s = dyn_cast(&sec))
secAddr += s->outSecOff;
+ else if (auto *eh = dyn_cast(&sec))
smithp35 wrote:
Author: psmith
Date: Thu Oct 26 05:02:03 2017
New Revision: 316657
URL: http://llvm.org/viewvc/llvm-project?rev=316657&view=rev
Log:
[libunwind] Always use unwind tables in tests
For many targets setting -fno-exceptions will prevent unwinding tables from
being generated for the test programs.
Author: psmith
Date: Mon Nov 20 05:43:55 2017
New Revision: 318647
URL: http://llvm.org/viewvc/llvm-project?rev=318647&view=rev
Log:
[ARM] For assembler files recognize -Xassembler or -Wa, -mthumb
The Unified Arm Assembler Language is designed so that the majority of
assembler files can be assemb
Author: psmith
Date: Mon Nov 20 05:53:55 2017
New Revision: 318648
URL: http://llvm.org/viewvc/llvm-project?rev=318648&view=rev
Log:
[ARM] For assembler files recognize -Xassembler or -Wa, -mthumb
Attempt to fix warning picked up by buildbot.
Modified:
cfe/trunk/lib/Driver/ToolChains/Clang.
Author: psmith
Date: Tue Jun 27 03:04:04 2017
New Revision: 306385
URL: http://llvm.org/viewvc/llvm-project?rev=306385&view=rev
Log:
[NFC] Update to account for DiagnosticRenderer use of FullSourceLoc
D31709 [NFC] Refactor DiagnosticRenderer to use FullSourceLoc was committed
in r305684 and rever
Author: psmith
Date: Thu Jul 27 02:21:41 2017
New Revision: 309257
URL: http://llvm.org/viewvc/llvm-project?rev=309257&view=rev
Log:
[CodeGen][ARM] ARM runtime helper functions are not always soft-fp
The ARM Runtime ABI document (IHI0043) defines the AEABI floating point
helper functions in 4.1.2
Author: psmith
Date: Thu Jul 27 02:57:13 2017
New Revision: 309259
URL: http://llvm.org/viewvc/llvm-project?rev=309259&view=rev
Log:
[CodeGen][ARM] Revert r309257
The test arm-float-helpers.c appears to be failing on some builders and
needs some work to make it more robust.
Removed:
cfe/tru
Author: psmith
Date: Thu Jul 27 03:43:53 2017
New Revision: 309263
URL: http://llvm.org/viewvc/llvm-project?rev=309263&view=rev
Log:
[CodeGen][ARM] ARM runtime helper functions are not always soft-fp
Re-commit r309257 with less precise register checks in arm-float-helpers.c
test.
Added:
cfe
peter.smith added a comment.
That looks correct to me. Certainly armebelf_linux_eabi is not recognised on a
recent ld.
Comment at: lib/Driver/Tools.cpp:9098
@@ -9097,3 +9097,3 @@
case llvm::Triple::thumbeb:
-return "armebelf_linux_eabi"; /* TODO: check which NAME. */
+
peter.smith accepted this revision.
peter.smith added a comment.
This revision is now accepted and ready to land.
I think the change looks fine and it looks small enough for me to approve.
http://reviews.llvm.org/D21022
___
cfe-commits mailing list
Hello Lei,
I agree with Rafael that this is currently missing a few critical
things right now, especially in the llvm patch.
My (limited) understanding of musl is that it intends to support the
same interface as GNUEABI and GNUEABIHF, but it is obviously a
different implementation.
This is what
From what I can see, the EABI type is used to decide if certain
__aeabi_ prefixed functions such as __aeabi_idiv are available. If
Musl differs in function availability from the GNU library here I
think you'll need a Musl EABI type. However if there is no difference
you should be able to use the EA
Hello Lei,
The changes to llvm and clang look ok to me. I've got some suggestions
for testing.
For the clang patch, it looks like there isn't a test to check that
musleabihf implies hard floating point. It looks like
Driver/arm-mfpu.c CHECK-HF might be a good candidate to add a test.
For the llv
Hello Lei,
Thanks for all the updates. That looks good to me from an ARM perspective.
Peter
On 22 June 2016 at 09:03, Lei Zhang wrote:
> 2016-06-21 23:07 GMT+08:00 Peter Smith :
>> Hello Lei,
>>
>> The changes to llvm and clang look ok to me. I've got some suggestions
>> for testing.
>>
>> For
Hello Lei,
They look good enough for me. Unless anyone else has any objections I
think you are good to go.
Peter
On 24 June 2016 at 04:25, Lei Zhang wrote:
> 2016-06-22 16:55 GMT+08:00 Peter Smith :
>> Hello Lei,
>>
>> Thanks for all the updates. That looks good to me from an ARM perspective.
>
@@ -895,20 +895,18 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver
&D,
// defaults this bit to 0 and handles it as a system-wide (not
// per-process) setting. It is therefore safe to assume that ARMv7+
// Linux targets support unaligned accesses. The s
smithp35 wrote:
Off the top of my head we default to `-ffunction-sections` and
`-fdata-sections` as this helps Garbage Collection, and we have a linker
feature that can merge constant pool entries between functions that needs the
gaps between the functions.
https://github.com/llvm/llvm-proj
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
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 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
@@ -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/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:
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
@@ -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
@@ -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
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
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 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/97827
___
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 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
@@ -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
@@ -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
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
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
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
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
@@ -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 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
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 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
smithp35 wrote:
No objections from me. I would prefer there not to be a difference for assembly
at different optimisation levels.
I can't find any evidence that this affects Arm (Thumb to be precise) assembly
at all. For example:
```
.text
b dest// b.n 2-byte branch
@@ -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.
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
_
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 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:
I can chime in with an opinion but unfortunately I think it may be different to
everyone elses!
This is a bit of an awkward situation as I think we have to balance several
things:
* Consistency between v8-R and AArch32 (ARM) and AArch64 (more consistent the
better)
* Consisten
smithp35 wrote:
Apologies I read the comments, rather than go through the code. It looks the
code has already made the v8-r imply a generic CPU.
So it looks like the code is doing what my proposal states so no objections
from me and apologies for the noise.
https://github.com/llvm/llvm-projec
https://github.com/smithp35 approved this pull request.
LGTM, thanks for the confirmation.
https://github.com/llvm/llvm-project/pull/88287
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commi
https://github.com/smithp35 commented:
There was a previous attempt at doing something similar with more global
registers r6-r11 in https://reviews.llvm.org/D68862 based on
http://lists.llvm.org/pipermail/llvm-dev/2018-December/128706.html
This got reverted, and unfortunately didn't get picked
https://github.com/smithp35 edited
https://github.com/llvm/llvm-project/pull/91028
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/smithp35 commented:
Thanks for working on this! Just a couple of small comment suggestions from me.
https://github.com/llvm/llvm-project/pull/91028
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-b
@@ -221,6 +221,11 @@ New Compiler Flags
- ``-fexperimental-modules-reduced-bmi`` enables the Reduced BMI for C++20
named modules.
See the document of standard C++ modules for details.
+- ``-fseparate-named-sections`` uses separate unique sections for global
+ symbols in na
@@ -277,6 +277,8 @@ namespace llvm {
/// Use unique names for basic block sections.
unsigned UniqueBasicBlockSectionNames : 1;
+unsigned SeparateNamedSections : 1;
smithp35 wrote:
Almost all of the other flags have Doxygen comments. Worth somethin
https://github.com/smithp35 commented:
The code-changes look good, what I'm less sure about is whether this is the
right thing to do unconditionally.
A few months ago I would likely to have said this wouldn't matter that much as
most people don't use `-S` in there build systems so any failure
smithp35 wrote:
Thanks for the additional context. My main concern is that we're undoing the
consensus of https://reviews.llvm.org/D45164 which if I've understood the
comments properly was "There is a reasonable expectation that compiled (not
assembled) code should be identical, or at least as
smithp35 wrote:
I will take a look, but may take me a while to go through it. Some very quick
comments:
* Would `--enable-experimental-crel` be a better name than
`--experimental-crel` that makes it clear that the option is just an unlock of
another flag, and not a flag in of itself?
* I agree
https://github.com/smithp35 commented:
Code change LGTM.
Although currently trivial, would it be worth adding a Driver test for it.
Something like
https://github.com/llvm/llvm-project/blob/main/clang/test/Driver/funique-internal-linkage-names.c
https://github.com/llvm/llvm-project/pull/915
smithp35 wrote:
I think it would be useful to nominate a source as the canonical reference for
the specification which is updated along with any implementation changes. I
think
https://discourse.llvm.org/t/rfc-crel-a-compact-relocation-format-for-elf/77600/3
is a good starting point.
Possibl
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
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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
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
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 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
@@ -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
1 - 100 of 160 matches
Mail list logo
