[llvm-branch-commits] [llvm-objdump] -r: support CREL (PR #97382)

[James Henderson via llvm-branch-commits]

@@ -1022,6 +1033,47 @@ 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_CREL) {
+if (RelData.d.a + 1 > Crels.size()) {
+  Crels.resize(RelData.d.a + 1);
+  CrelErrs.resize(RelData.d.a + 1);
+}
+if (Crels[RelData.d.a].empty()) {
+  // Decode SHT_CREL. See ELFFile::decodeCrel.
+  ArrayRef Content = cantFail(getSectionContents(Sec));
+  DataExtractor Data(Content, ELFT::Endianness == endianness::little,
+ sizeof(typename ELFT::Addr));
+  DataExtractor::Cursor Cur(0);
+  const uint64_t Hdr = Data.getULEB128(Cur);
+  const size_t Count = Hdr / 8;
+  const size_t FlagBits = Hdr & ELF::CREL_HDR_ADDEND ? 3 : 2;
+  const size_t Shift = Hdr % ELF::CREL_HDR_ADDEND;
+  uintX_t Offset = 0, Addend = 0;
+  uint32_t Symidx = 0, Type = 0;
+  for (size_t i = 0; i != Count; ++i) {

jh7370 wrote:

It really doesn't feel right that this whole algorithm is duplicated from the 
version in ELF.cpp. Surely they can be folded together into shared code 
somewhere?

https://github.com/llvm/llvm-project/pull/97382
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm-objcopy] Support CREL (PR #97521)

[James Henderson via llvm-branch-commits]

https://github.com/jh7370 commented:

I've skimmed briefly and the changes look reasonable - will look more in depth 
on a separate occasion when I have more time.

Not for this PR, but I wonder if there would be some benefit in a 
`--decode-crel` and/or `--encode-crel` option that would convert an object file 
to/from using CREL. I feel like this might be useful for experimentation, or 
for handling the case where an object was generated with CREL but needs to be 
usable by an older tool that doesn't understand CREL. Equally, it could be 
useful for retroactively encoding CREL when the feature wasn't used during 
original creation of the object. Thoughts?

https://github.com/llvm/llvm-project/pull/97521
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm-objdump] -r: support CREL (PR #97382)

[James Henderson via llvm-branch-commits]

@@ -1117,9 +1155,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(Rel)->r_addend;
+  if (getRelSection(Rel)->sh_type == ELF::SHT_RELA)
+return (int64_t)getRela(Rel)->r_addend;
+  if (getRelSection(Rel)->sh_type == ELF::SHT_CREL)
+return (int64_t)getCrel(Rel).r_addend;
+  return createError("Section is not SHT_RELA");

jh7370 wrote:

I'm not sure this error quite makes sense anymore. Probably needs to say 
something about addends.

https://github.com/llvm/llvm-project/pull/97382
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [llvm-objcopy] Support CREL (PR #97521)

[James Henderson via llvm-branch-commits]

https://github.com/jh7370 commented:

Is it worth a test to show a user attempting to strip a symbol referenced by a 
crel section? Similarly, a crel section that is associated with a section that 
gets stripped? Perhaps not needed, but just a thought.

https://github.com/llvm/llvm-project/pull/97521
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [llvm-objcopy] Support CREL (PR #97521)

[James Henderson via llvm-branch-commits]

https://github.com/jh7370 edited https://github.com/llvm/llvm-project/pull/97521
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [llvm-objcopy] Support CREL (PR #97521)

[James Henderson via llvm-branch-commits]

@@ -0,0 +1,63 @@
+//===- MCELFExtras.h - Extra functions for ELF --*- C++ 
-*-===//
+//
+// 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
+//
+//===--===//
+
+#ifndef LLVM_MC_MCELFEXTRAS_H
+#define LLVM_MC_MCELFEXTRAS_H
+
+#include "llvm/ADT/STLExtras.h"
+#include "llvm/ADT/bit.h"
+#include "llvm/BinaryFormat/ELF.h"
+#include "llvm/Support/LEB128.h"
+#include "llvm/Support/raw_ostream.h"
+
+#include 
+#include 
+
+namespace llvm::ELF {
+// Encode relocations as CREL to OS. ToCrel is responsible for converting a
+// const &RelocsTy to a Elf_Crel

jh7370 wrote:

```suggestion
// const &RelocsTy to a Elf_Crel.
```
Nit

https://github.com/llvm/llvm-project/pull/97521
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [llvm-objcopy] Support CREL (PR #97521)

[James Henderson via llvm-branch-commits]

@@ -0,0 +1,140 @@
+# RUN: yaml2obj %s -o %t
+# RUN: llvm-objcopy --remove-section=.foo --strip-symbol=unused %t %t.out
+# RUN: llvm-readelf -Sr %t.out | FileCheck %s
+
+# CHECK:  [Nr] Name  TypeAddress  Off
Size   ES Flg Lk Inf Al
+# CHECK-NEXT: [ 0]   NULL 00 
00 00  0   0  0
+# CHECK-NEXT: [ 1] .text PROGBITS {{.*}} 
08 00   A  0   0  0
+# CHECK-NEXT: [ 2] .crel.textCREL {{.*}} 
22 00  5   1  0
+# CHECK-NEXT: [ 3] nonalloc  PROGBITS {{.*}} 
30 00  0   0  0
+# CHECK-NEXT: [ 4] .crelnonalloc CREL {{.*}} 
0b 00  5   3  0
+
+# CHECK:  Relocation section '.crel.text' at offset {{.*}} contains 4 
entries:
+# CHECK-NEXT: Offset Info Type   
Symbol's Value  Symbol's Name + Addend
+# CHECK-NEXT: 0001  {{.*}}   R_X86_64_32
 g1 + 1
+# CHECK-NEXT: 0002  {{.*}}   R_X86_64_64
 l1 + 2
+# CHECK-NEXT:   {{.*}}   R_X86_64_32S   
 g1 - 1
+# CHECK-NEXT: 0004  {{.*}}   R_X86_64_32S   
 .text - 8000
+# CHECK-EMPTY:
+# CHECK-NEXT: Relocation section '.crelnonalloc' at offset {{.*}} contains 3 
entries:
+# CHECK-NEXT: Offset Info Type   
Symbol's Value  Symbol's Name + Addend
+# CHECK-NEXT: 0010  {{.*}}   R_X86_64_64
 g1 + 1
+# CHECK-NEXT: 0020  {{.*}}   R_X86_64_64
 g2 + 2
+# CHECK-NEXT: 0030  {{.*}}   R_X86_64_64   
0
+
+--- !ELF
+FileHeader: !FileHeader

jh7370 wrote:

This line doesn't look right?

https://github.com/llvm/llvm-project/pull/97521
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [llvm-objcopy] Support CREL (PR #97521)

[James Henderson via llvm-branch-commits]

https://github.com/jh7370 approved this pull request.

LGTM!

https://github.com/llvm/llvm-project/pull/97521
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm-objdump] -r: support CREL (PR #97382)

[James Henderson via llvm-branch-commits]

https://github.com/jh7370 approved this pull request.

LGTM!

https://github.com/llvm/llvm-project/pull/97382
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [ARM, MC] Support FDPIC relocations (PR #82187)

[James Henderson via llvm-branch-commits]

https://github.com/jh7370 commented:

BinaryFormat/llvm-readobj aspects looks fine to me, but the assembler side of 
things goes a bit over my head, so you'll need someone else to review that area.

https://github.com/llvm/llvm-project/pull/82187
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [ARM, MC] Support FDPIC relocations (PR #82187)

[James Henderson via llvm-branch-commits]

https://github.com/jh7370 edited https://github.com/llvm/llvm-project/pull/82187
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [ARM, MC] Support FDPIC relocations (PR #82187)

[James Henderson via llvm-branch-commits]

@@ -143,3 +143,10 @@ ELF_RELOC(R_ARM_THM_BF16,   0x88)
 ELF_RELOC(R_ARM_THM_BF12,   0x89)
 ELF_RELOC(R_ARM_THM_BF18,   0x8a)
 ELF_RELOC(R_ARM_IRELATIVE,  0xa0)
+ELF_RELOC(R_ARM_GOTFUNCDESC,0xa1)
+ELF_RELOC(R_ARM_GOTOFFFUNCDESC, 0xa2)
+ELF_RELOC(R_ARM_FUNCDESC,   0xa3)
+ELF_RELOC(R_ARM_FUNCDESC_VALUE, 0xa4)
+ELF_RELOC(R_ARM_TLS_GD32_FDPIC, 0xa5)
+ELF_RELOC(R_ARM_TLS_LDM32_FDPIC,0xa6)
+ELF_RELOC(R_ARM_TLS_IE32_FDPIC, 0xa7)

jh7370 wrote:

I might be looking in the wrong place, but I couldn't see the values for these 
three relocations defined in the doc you link in the description?

https://github.com/llvm/llvm-project/pull/82187
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] release/18.x: [llvm-objcopy] Add SystemZ support (#81841) (PR #82324)

[James Henderson via llvm-branch-commits]

jh7370 wrote:

Functionally, I'm confident this is safe, but I don't know whether it's too 
late in the cycle to be picking additional non-bug fix commits. @tstellar?

Also, as noted in the original PR, the corresponding doc change needs picking 
too.

https://github.com/llvm/llvm-project/pull/82324
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] release/18.x: [docs][llvm-objcopy] Add missing formats (#81981) (PR #82470)

[James Henderson via llvm-branch-commits]

https://github.com/jh7370 approved this pull request.

LGTM!

https://github.com/llvm/llvm-project/pull/82470
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] ReleaseNotes for LLVM binary utilities (PR #83751)

[James Henderson via llvm-branch-commits]

https://github.com/jh7370 approved this pull request.

LGTM (I haven't attempted to review the list of changes to make sure you 
haven't missed any).

https://github.com/llvm/llvm-project/pull/83751
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] ReleaseNotes for LLVM binary utilities (PR #83751)

[James Henderson via llvm-branch-commits]

@@ -344,21 +344,26 @@ Changes to the LLVM tools
 * Fixed big-endian support in llvm-symbolizer's DWARF location parser.
 * llvm-readelf now supports ``--extra-sym-info`` (``-X``) to display extra
   information (section name) when showing symbols.
-
-* ``llvm-nm`` now supports the ``--line-numbers`` (``-l``) option to use
-  debugging information to print symbols' filenames and line numbers.
+* ``llvm-readobj``/``llvm-readelf`` now supports ``--decompress``/``-z`` with

jh7370 wrote:

There are a number of references to tool names in other notes within this file 
without the backticks. They should probably be normalised at some point.

https://github.com/llvm/llvm-project/pull/83751
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] ReleaseNotes for LLVM binary utilities (PR #83751)

[James Henderson via llvm-branch-commits]

https://github.com/jh7370 edited https://github.com/llvm/llvm-project/pull/83751
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm-objcopy] Simplify --[de]compress-debug-sections and don't compress SHF_ALLOC sections (PR #84885)

[James Henderson via llvm-branch-commits]

@@ -214,33 +214,34 @@ static Error dumpSectionToFile(StringRef SecName, 
StringRef Filename,
SecName.str().c_str());
 }
 
-static bool isCompressable(const SectionBase &Sec) {
-  return !(Sec.Flags & ELF::SHF_COMPRESSED) &&
- StringRef(Sec.Name).starts_with(".debug");
-}
-
-static Error replaceDebugSections(
-Object &Obj, function_ref ShouldReplace,
-function_ref(const SectionBase *)> AddSection) {
+Error Object::compressOrDecompressSections(const CommonConfig &Config) {
   // Build a list of the debug sections we are going to replace.
   // We can't call `AddSection` while iterating over sections,
   // because it would mutate the sections array.
-  SmallVector ToReplace;
-  for (auto &Sec : Obj.sections())
-if (ShouldReplace(Sec))
-  ToReplace.push_back(&Sec);
-
-  // Build a mapping from original section to a new one.
-  DenseMap FromTo;
-  for (SectionBase *S : ToReplace) {
-Expected NewSection = AddSection(S);
-if (!NewSection)
-  return NewSection.takeError();
-
-FromTo[S] = *NewSection;
+  SmallVector>, 0>

jh7370 wrote:

I had this idea in my head that `0` was the default for `SmallVector`?

https://github.com/llvm/llvm-project/pull/84885
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm-objcopy] Simplify --[de]compress-debug-sections and don't compress SHF_ALLOC sections (PR #84885)

[James Henderson via llvm-branch-commits]

https://github.com/jh7370 commented:

Looks basically fine to me.

https://github.com/llvm/llvm-project/pull/84885
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm-objcopy] Simplify --[de]compress-debug-sections and don't compress SHF_ALLOC sections (PR #84885)

[James Henderson via llvm-branch-commits]

https://github.com/jh7370 edited https://github.com/llvm/llvm-project/pull/84885
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm-objcopy] Simplify --[de]compress-debug-sections and don't compress SHF_ALLOC sections (PR #84885)

[James Henderson via llvm-branch-commits]

@@ -12,8 +12,10 @@
 # CHECK: Name  TypeAddress  Off
Size   ES Flg Lk Inf Al
 # COMPRESSED:.debug_fooPROGBITS 40 
{{.*}} 00   C  0   0  8
 # COMPRESSED-NEXT:   .notdebug_foo PROGBITS {{.*}} 
08 00  0   0  0
+# COMPRESSED:.debug_alloc  PROGBITS {{.*}} 
40 00   A  0   0  0

jh7370 wrote:

You presumably need changes to the zstd version of this test too?

https://github.com/llvm/llvm-project/pull/84885
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [libc] [compiler-rt] [clang] [clang-tools-extra] [llvm] [flang] [OptTable] Make new lines in help text respect indentation (PR #74880)

[James Henderson via llvm-branch-commits]

https://github.com/jh7370 commented:

Is the main functionality of this test actually tested in the current patch? It 
doesn't seem to be to me.

https://github.com/llvm/llvm-project/pull/74880
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [libc] [flang] [clang-tools-extra] [compiler-rt] [clang] [OptTable] Make new lines in help text respect indentation (PR #74880)

[James Henderson via llvm-branch-commits]

https://github.com/jh7370 edited https://github.com/llvm/llvm-project/pull/74880
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [compiler-rt] [clang-tools-extra] [libc] [llvm] [flang] [clang] [OptTable] Make new lines in help text respect indentation (PR #74880)

[James Henderson via llvm-branch-commits]

@@ -1,16 +1,16 @@
 ; RUN: llvm-cvtres /h > %t
-; RUN: FileCheck -input-file=%t %s -check-prefix=HELP_TEST
+; RUN: FileCheck -input-file=%t %s --strict-whitespace -check-prefix=HELP_TEST
 
-; HELP_TEST: OVERVIEW: Resource Converter
-; HELP_TEST-DAG:  USAGE: llvm-cvtres [options] file...
-; HELP_TEST-DAG:  OPTIONS:
-; HELP_TEST-NEXT:   /{{DEFINE}}:symbol - Not implemented
-; HELP_TEST-NEXT:   /FOLDDUPS: - Not implemented
-; HELP_TEST-NEXT:   /HELP - Display available options
+;  HELP_TEST: OVERVIEW: Resource Converter
+;  HELP_TEST-DAG: USAGE: llvm-cvtres [options] file...
+;  HELP_TEST-DAG: OPTIONS:
+; HELP_TEST-NEXT:   /{{DEFINE}}:symbol - Not implemented

jh7370 wrote:

The formatting in this line looks wrong? It looks to me like there might be a 
bug here (possibly predating your PR).

https://github.com/llvm/llvm-project/pull/74880
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [flang] [llvm] [clang-tools-extra] [clang] [compiler-rt] [libc] [OptTable] Make new lines in help text respect indentation (PR #74880)

[James Henderson via llvm-branch-commits]

https://github.com/jh7370 commented:

> > Is the main functionality of this test actually tested in the current 
> > patch? It doesn't seem to be to me.
> I don't fully understand your comment, I am working on getting some of the 
> test to be whitespace strict to specifically test the functionality.

I just didn't see any testing like you've now added in OptionParsingTest.cpp 
that showed that the indentation was working correctly as desired.

Taking a step back, I'm not sure the addition of the dash has anything to do 
with the main purpose of this PR, and I'm a little worried people will not spot 
that this PR is adding it. I personally have no issue with that part of the 
change, but I wonder if others wouldn't want it?

https://github.com/llvm/llvm-project/pull/74880
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [lld] b37a349 - [lld][ELF][test] Add testing for IE/LD TLS weak undef references

[James Henderson via llvm-branch-commits]

Author: James Henderson
Date: 2021-01-25T09:58:56Z
New Revision: b37a349ff2442e73ceafeee982afb430359e08b1

URL: 
https://github.com/llvm/llvm-project/commit/b37a349ff2442e73ceafeee982afb430359e08b1
DIFF: 
https://github.com/llvm/llvm-project/commit/b37a349ff2442e73ceafeee982afb430359e08b1.diff

LOG: [lld][ELF][test] Add testing for IE/LD TLS weak undef references

Whilst migrating/retiring some downstream testing, I came across a test
for weak undef IE and LD TLS references, but was unable to find any
equivalent in LLD's upstream testing. There does seem to be some slight
subtle differences that could be worth testing compared to LE TLS
references, in particular that IE can be relaxed to LE in this case,
hence this change.

Differential Revision: https://reviews.llvm.org/D95124

Reviewed by: grimar, MaskRay

Added: 
lld/test/ELF/tls-weak-undef.s

Modified: 


Removed: 
lld/test/ELF/tls-le-weak-undef.s



diff  --git a/lld/test/ELF/tls-le-weak-undef.s 
b/lld/test/ELF/tls-le-weak-undef.s
deleted file mode 100644
index fefda9da9816..
--- a/lld/test/ELF/tls-le-weak-undef.s
+++ /dev/null
@@ -1,18 +0,0 @@
-# REQUIRES: x86
-# RUN: llvm-mc -filetype=obj -triple=x86_64 %s -o %t.o
-# RUN: echo '.tbss; .globl tls; tls:' | llvm-mc -filetype=obj -triple=x86_64 - 
-o %tdef.o
-# RUN: ld.lld %t.o -o - | llvm-objdump -d - | FileCheck %s
-
-## A weak symbol does not fetch a lazy definition.
-# RUN: ld.lld %t.o --start-lib %tdef.o --end-lib -o - | llvm-objdump -d - | 
FileCheck %s
-
-## Undefined TLS symbols arbitrarily resolve to 0.
-# CHECK:  leaq 16(%rax), %rdx
-
-# RUN: ld.lld -shared %tdef.o -o %tdef.so
-# RUN: not ld.lld %t.o %tdef.so -o /dev/null 2>&1 | FileCheck 
--check-prefix=COPYRELOC %s
-
-# COPYRELOC: symbol 'tls' has no type
-
-.weak tls
-leaq tls@tpoff+16(%rax), %rdx

diff  --git a/lld/test/ELF/tls-weak-undef.s b/lld/test/ELF/tls-weak-undef.s
new file mode 100644
index ..19d1337c9fc8
--- /dev/null
+++ b/lld/test/ELF/tls-weak-undef.s
@@ -0,0 +1,42 @@
+# REQUIRES: x86
+
+# RUN: split-file %s %t
+# RUN: llvm-mc -filetype=obj -triple=x86_64 %t/exec.s -o %texec.o
+# RUN: llvm-mc -filetype=obj -triple=x86_64 %t/shared.s -o %tshared.o
+# RUN: llvm-mc -filetype=obj -triple=x86_64 %t/ledef.s -o %tdef.o
+# RUN: ld.lld %texec.o -o %t.exec
+# RUN: ld.lld %tshared.o -o %t.shared --shared
+# RUN: llvm-objdump -d %t.exec | FileCheck %s --check-prefix=EXEC
+# RUN: llvm-objdump -d %t.shared | FileCheck %s --check-prefix=SHARED
+
+## An undefined weak TLS symbol does not fetch a lazy definition.
+# RUN: ld.lld %texec.o --start-lib %tdef.o --end-lib -o %tlazy
+# RUN: llvm-objdump -d %tlazy | FileCheck %s --check-prefix=EXEC
+
+## Undefined TLS symbols arbitrarily resolve to 0.
+# EXEC:   leaq 16(%rax), %rdx
+## Initial-exec references to undefined weak symbols can be relaxed to LE
+## references.
+# EXEC:   leaq 32(%rax), %rax
+# SHARED: leaq 48(%rax), %rcx
+
+# RUN: ld.lld -shared %tdef.o -o %tdef.so
+# RUN: not ld.lld %texec.o %tdef.so -o /dev/null 2>&1 | FileCheck 
--check-prefix=ERROR %s
+
+# ERROR: symbol 'le' has no type
+
+#--- ledef.s
+.tbss
+.globl le
+le:
+
+#--- exec.s
+.weak le
+leaq le@tpoff+16(%rax), %rdx
+
+.weak ie
+addq ie@gottpoff+32(%rip), %rax
+
+#--- shared.s
+.weak ld
+leaq ld@dtpoff+48(%rax), %rcx



___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] 5b95eb0 - [debuginfo-test][cross-project-tests] Release note for new project name

[James Henderson via llvm-branch-commits]

Author: James Henderson
Date: 2021-09-21T09:48:35+01:00
New Revision: 5b95eb0b442e8eaa6b90ff765a3ad4c271c2d9eb

URL: 
https://github.com/llvm/llvm-project/commit/5b95eb0b442e8eaa6b90ff765a3ad4c271c2d9eb
DIFF: 
https://github.com/llvm/llvm-project/commit/5b95eb0b442e8eaa6b90ff765a3ad4c271c2d9eb.diff

LOG: [debuginfo-test][cross-project-tests] Release note for new project name

Add a release note for the renaming of the debuginfo-test to
cross-project-tests, performed in commit
1364750dadbb56032ef73b4d0d8cbc88a51392da and follow-ons.

Reviewed by: sylvestre.ledru

Differential Revision: https://reviews.llvm.org/D110134

Added: 


Modified: 
llvm/docs/ReleaseNotes.rst

Removed: 




diff  --git a/llvm/docs/ReleaseNotes.rst b/llvm/docs/ReleaseNotes.rst
index a192485d46836..ba83775aa8cd5 100644
--- a/llvm/docs/ReleaseNotes.rst
+++ b/llvm/docs/ReleaseNotes.rst
@@ -57,6 +57,15 @@ Non-comprehensive list of changes in this release
 
 * Flang is now included in the binary packages released by LLVM.
 
+* The debuginfo-test project has been renamed cross-project-tests and is now
+  intended for testing components from multiple projects, not just debug
+  information. The new "cross-project-tests" name replaces "debuginfo-test" in
+  LLVM_ENABLE_PROJECTS, and a new check-cross-project-tests target has been
+  added for running all tests in the project. The pre-existing check-debuginfo-
+  test target remains for running just the debug information tests.
+  (`D95339 `_ and
+  `D96513 `_)
+
 Changes to the LLVM IR
 --
 



___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] f07403e - [llvm-symbolizer][doc] Reorder --relativenames in options list

[James Henderson via llvm-branch-commits]

Author: James Henderson
Date: 2021-01-20T11:50:00Z
New Revision: f07403eb1a5f781b1bcc2b0c18ef7f632e1a0fdc

URL: 
https://github.com/llvm/llvm-project/commit/f07403eb1a5f781b1bcc2b0c18ef7f632e1a0fdc
DIFF: 
https://github.com/llvm/llvm-project/commit/f07403eb1a5f781b1bcc2b0c18ef7f632e1a0fdc.diff

LOG: [llvm-symbolizer][doc] Reorder --relativenames in options list

This puts it in alphabetical order, matching the rest of the list.

Reviewed by: MaskRay, saugustine

Differential Revision: https://reviews.llvm.org/D94481

Added: 


Modified: 
llvm/docs/CommandGuide/llvm-symbolizer.rst

Removed: 




diff  --git a/llvm/docs/CommandGuide/llvm-symbolizer.rst 
b/llvm/docs/CommandGuide/llvm-symbolizer.rst
index f2a8d8ef6801..40986eac8722 100644
--- a/llvm/docs/CommandGuide/llvm-symbolizer.rst
+++ b/llvm/docs/CommandGuide/llvm-symbolizer.rst
@@ -182,12 +182,6 @@ OPTIONS
 
   Print just the file's name without any directories, instead of the
   absolute path.
-
-.. option:: --relativenames
-
-  Print the file's path relative to the compilation directory, instead
-  of the absolute path. If the command-line to the compiler included
-  the full path, this will be the same as the default.
   
 .. _llvm-symbolizer-opt-C:
 
@@ -321,6 +315,12 @@ OPTIONS
 11 >:   return foz() + k;
 12  : }
 
+.. option:: --relativenames
+
+  Print the file's path relative to the compilation directory, instead
+  of the absolute path. If the command-line to the compiler included
+  the full path, this will be the same as the default.
+
 .. _llvm-symbolizer-opt-use-symbol-table:
 
 .. option:: --use-symbol-table



___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] release/20.x: [llvm-objcopy] Fix prints wrong path when dump-section output path doesn't exist (#125345) (PR #126367)

[James Henderson via llvm-branch-commits]

https://github.com/jh7370 approved this pull request.

LGTM.

Regarding the release note, you'll need one on the release branch. IIUC, you 
won't then need one on `main`, because the release branch is still in RC mode, 
so not a final release yet.

https://github.com/llvm/llvm-project/pull/126367
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] release/20.x: [llvm-objcopy][ReleaseNotes] Fix prints wrong path when dump-section output path doesn't exist #125345 (PR #126607)

[James Henderson via llvm-branch-commits]

https://github.com/jh7370 approved this pull request.

LGTM, with @MaskRay's suggestion.

https://github.com/llvm/llvm-project/pull/126607
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [YAML] Don't validate `Fill::Size` after error (PR #123280)

[James Henderson via llvm-branch-commits]

@@ -1750,7 +1750,9 @@ void 
MappingTraits>::mapping(
 std::string MappingTraits>::validate(
 IO &io, std::unique_ptr &C) {
   if (const auto *F = dyn_cast(C.get())) {
-if (F->Pattern && F->Pattern->binary_size() != 0 && !F->Size)
+// Can't check the `Size`, as it's required and may be left uninitialized 
by

jh7370 wrote:

At a guess, based on the comment, it's when the `Size` field in the YAML is 
missing for a `Fill`?

I'm beginning to think that `mapRequired` should zero-initialise the value that 
is being mapped, even on failure. I suspect there are many more cases along 
these lines too.

https://github.com/llvm/llvm-project/pull/123280
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [SHT_LLVM_FUNC_MAP][llvm-readobj]Introduce function address map section and emit dynamic instruction count(readobj part) (PR #124333)

[James Henderson via llvm-branch-commits]

@@ -7922,6 +7928,59 @@ void LLVMELFDumper::printBBAddrMaps(bool 
PrettyPGOAnalysis) {
   }
 }
 
+template  void LLVMELFDumper::printFuncMaps() {
+  bool IsRelocatable = this->Obj.getHeader().e_type == ELF::ET_REL;
+  using Elf_Shdr = typename ELFT::Shdr;
+  auto IsMatch = [](const Elf_Shdr &Sec) -> bool {
+return Sec.sh_type == ELF::SHT_LLVM_FUNC_MAP;
+  };

jh7370 wrote:

Please define this inline, since it's only used once, and delete the trailing 
return type (since that is automatically derived from the result of the return 
expression, of which there is only one).

https://github.com/llvm/llvm-project/pull/124333
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [SHT_LLVM_FUNC_MAP][llvm-readobj]Introduce function address map section and emit dynamic instruction count(readobj part) (PR #124333)

[James Henderson via llvm-branch-commits]

@@ -940,6 +940,92 @@ ELFFile::decodeBBAddrMap(const Elf_Shdr &Sec, const 
Elf_Shdr *RelaSec,
   return std::move(AddrMapsOrErr);
 }
 
+template 
+Expected>
+ELFFile::decodeFuncMap(const Elf_Shdr &Sec,
+ const Elf_Shdr *RelaSec) const {
+  bool IsRelocatable = this->getHeader().e_type == ELF::ET_REL;
+
+  // This DenseMap maps the offset of each function (the location of the
+  // reference to the function in the SHT_LLVM_FUNC_MAP section) to the
+  // addend (the location of the function in the text section).
+  llvm::DenseMap FunctionOffsetTranslations;
+  if (IsRelocatable && RelaSec) {
+assert(RelaSec &&
+   "Can't read a SHT_LLVM_FUNC_ADDR_MAP section in a relocatable "
+   "object file without providing a relocation section.");
+Expected::Elf_Rela_Range> Relas =
+this->relas(*RelaSec);
+if (!Relas)
+  return createError("unable to read relocations for section " +
+ describe(*this, Sec) + ": " +
+ toString(Relas.takeError()));
+for (typename ELFFile::Elf_Rela Rela : *Relas)
+  FunctionOffsetTranslations[Rela.r_offset] = Rela.r_addend;
+  }
+  auto GetAddressForRelocation =
+  [&](unsigned RelocationOffsetInSection) -> Expected {
+auto FOTIterator =
+FunctionOffsetTranslations.find(RelocationOffsetInSection);
+if (FOTIterator == FunctionOffsetTranslations.end()) {
+  return createError("failed to get relocation data for offset: " +
+ Twine::utohexstr(RelocationOffsetInSection) +
+ " in section " + describe(*this, Sec));
+}
+return FOTIterator->second;
+  };
+  Expected> ContentsOrErr = this->getSectionContents(Sec);
+  if (!ContentsOrErr)
+return ContentsOrErr.takeError();
+  ArrayRef Content = *ContentsOrErr;
+  DataExtractor Data(Content, this->isLE(), ELFT::Is64Bits ? 8 : 4);
+  std::vector FunctionEntries;
+
+  DataExtractor::Cursor Cur(0);
+
+  // Helper lampda to extract the (possiblly relocatable) address stored at 
Cur.
+  auto ExtractAddress = [&]() -> Expected::uintX_t> {
+uint64_t RelocationOffsetInSection = Cur.tell();
+auto Address =
+static_cast::uintX_t>(Data.getAddress(Cur));
+if (!Cur)
+  return Cur.takeError();
+if (!IsRelocatable)
+  return Address;
+assert(Address == 0);
+Expected AddressOrErr =
+GetAddressForRelocation(RelocationOffsetInSection);
+if (!AddressOrErr)
+  return AddressOrErr.takeError();
+return *AddressOrErr;
+  };
+
+  uint8_t Version = 0;
+  while (Cur && Cur.tell() < Content.size()) {
+if (Sec.sh_type == ELF::SHT_LLVM_FUNC_MAP) {

jh7370 wrote:

Why is this check needed?

https://github.com/llvm/llvm-project/pull/124333
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [SHT_LLVM_FUNC_MAP][llvm-readobj]Introduce function address map section and emit dynamic instruction count(readobj part) (PR #124333)

[James Henderson via llvm-branch-commits]

@@ -7922,6 +7928,59 @@ void LLVMELFDumper::printBBAddrMaps(bool 
PrettyPGOAnalysis) {
   }
 }
 
+template  void LLVMELFDumper::printFuncMaps() {
+  bool IsRelocatable = this->Obj.getHeader().e_type == ELF::ET_REL;
+  using Elf_Shdr = typename ELFT::Shdr;
+  auto IsMatch = [](const Elf_Shdr &Sec) -> bool {
+return Sec.sh_type == ELF::SHT_LLVM_FUNC_MAP;
+  };
+  Expected> SecRelocMapOrErr =
+  this->Obj.getSectionAndRelocations(IsMatch);
+  if (!SecRelocMapOrErr) {
+this->reportUniqueWarning("failed to get SHT_LLVM_FUNC_MAP section(s): " +
+  toString(SecRelocMapOrErr.takeError()));
+return;
+  }
+
+  for (auto const &[Sec, RelocSec] : *SecRelocMapOrErr) {
+std::optional FunctionSec;
+if (IsRelocatable)
+  FunctionSec =
+  unwrapOrError(this->FileName, this->Obj.getSection(Sec->sh_link));

jh7370 wrote:

Do not use `unwrapOrError` in new code. The dumper should be tolerant of 
slightly dodgy looking object files, as the dumper is often the only way of 
finding out what's gone wrong (short of decoding the bytes be hand).

A warning is fine here and you can then either continue as if the relocation 
section didn't exist or bail out. See my comments elsewhere about the 
requirement for a relocation section.

https://github.com/llvm/llvm-project/pull/124333
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [SHT_LLVM_FUNC_MAP][llvm-readobj]Introduce function address map section and emit dynamic instruction count(readobj part) (PR #124333)

[James Henderson via llvm-branch-commits]

@@ -940,6 +940,92 @@ ELFFile::decodeBBAddrMap(const Elf_Shdr &Sec, const 
Elf_Shdr *RelaSec,
   return std::move(AddrMapsOrErr);
 }
 
+template 
+Expected>
+ELFFile::decodeFuncMap(const Elf_Shdr &Sec,
+ const Elf_Shdr *RelaSec) const {
+  bool IsRelocatable = this->getHeader().e_type == ELF::ET_REL;

jh7370 wrote:

Do we really need this check? Would not the value of `RelaSec` (`nullptr` or 
otherwise) be sufficient?

https://github.com/llvm/llvm-project/pull/124333
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [SHT_LLVM_FUNC_MAP][llvm-readobj]Introduce function address map section and emit dynamic instruction count(readobj part) (PR #124333)

[James Henderson via llvm-branch-commits]

@@ -940,6 +940,92 @@ ELFFile::decodeBBAddrMap(const Elf_Shdr &Sec, const 
Elf_Shdr *RelaSec,
   return std::move(AddrMapsOrErr);
 }
 
+template 
+Expected>
+ELFFile::decodeFuncMap(const Elf_Shdr &Sec,
+ const Elf_Shdr *RelaSec) const {
+  bool IsRelocatable = this->getHeader().e_type == ELF::ET_REL;
+
+  // This DenseMap maps the offset of each function (the location of the
+  // reference to the function in the SHT_LLVM_FUNC_MAP section) to the
+  // addend (the location of the function in the text section).
+  llvm::DenseMap FunctionOffsetTranslations;
+  if (IsRelocatable && RelaSec) {
+assert(RelaSec &&
+   "Can't read a SHT_LLVM_FUNC_ADDR_MAP section in a relocatable "
+   "object file without providing a relocation section.");
+Expected::Elf_Rela_Range> Relas =
+this->relas(*RelaSec);
+if (!Relas)
+  return createError("unable to read relocations for section " +
+ describe(*this, Sec) + ": " +
+ toString(Relas.takeError()));
+for (typename ELFFile::Elf_Rela Rela : *Relas)
+  FunctionOffsetTranslations[Rela.r_offset] = Rela.r_addend;

jh7370 wrote:

Not all relocations function in the same way. Naively assuming that the 
`r_addend` and `r_offset` work like this is not going to be correct in some 
cases. The ELF gABI only describes `r_addend` as a "constant addend used to 
compute the value".

Have you looked into the Object/RelocationResolver.h? It's used elsewhere by 
llvm-readobj to calculate the values of relocations and may be of some use (see 
`printRelocatableStackSizes` for an example usage).

https://github.com/llvm/llvm-project/pull/124333
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [llvm] release/20.x: [Hexagon] Set the default compilation target to V68 (#125239) (PR #128597)

[James Henderson via llvm-branch-commits]

jh7370 wrote:

I don't know why I've been included on this PR - I have no knowledge of this 
area, nor was I involved with the original PR.

https://github.com/llvm/llvm-project/pull/128597
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [llvm-objdump] Support --symbolize-operand on AArch64 (PR #145009)

[James Henderson via llvm-branch-commits]

https://github.com/jh7370 approved this pull request.

LGTM, thanks. Probably want to wait for @MaskRay for final sign-off, but if 
he's too busy, land it in a couple of days anyway.

https://github.com/llvm/llvm-project/pull/145009
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm-objdump] Support --symbolize-operand on AArch64 (PR #145009)

[James Henderson via llvm-branch-commits]

@@ -0,0 +1,42 @@
+# RUN: yaml2obj %s -o %t
+# RUN: llvm-objdump %t -d --symbolize-operands --no-show-raw-insn 
--no-leading-addr | \
+# RUN:   FileCheck %s --match-full-lines
+# RUN: llvm-objdump %t -d --symbolize-operands --no-show-raw-insn 
--no-leading-addr --adjust-vma=0x2000 | \
+# RUN:   FileCheck %s --match-full-lines
+
+## Expect to find the branch labels and global variable name.
+# CHECK:  <_start>:
+# CHECK-NEXT:   ldr x0, 
+# CHECK-NEXT: :
+# CHECK-NEXT:   adrp x1, 0x{{[68]}}000 
+# CHECK-NEXT:   adr x2, 
+# CHECK-NEXT:   cmp x1, x2
+# CHECK-NEXT:   b.eq 
+# CHECK-NEXT:   b 
+# CHECK-NEXT: :
+# CHECK-NEXT:   cbz x2, 
+# CHECK-NEXT:   ret
+
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:ELFDATA2LSB
+  Type:ET_EXEC
+  Machine: EM_AARCH64
+Sections:
+  - Name:.text
+Type:SHT_PROGBITS
+Address: 0x4000
+Flags:   [SHF_ALLOC, SHF_EXECINSTR]
+Content: '6080005801d0228000103f0002eb4054fc1762b4c0035fd6'

jh7370 wrote:

Assuming that using llvm-mc and relying on relocations is not sufficient to 
test the desired behaviour, I think this is mostly okay, as it's not an 
especially long block, but I do think you need to describe somewhere what these 
instructions map to or in other words, how to regenerate this hex.

https://github.com/llvm/llvm-project/pull/145009
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm-objdump] Support --symbolize-operand on AArch64 (PR #145009)

[James Henderson via llvm-branch-commits]

@@ -0,0 +1,42 @@
+# RUN: yaml2obj %s -o %t
+# RUN: llvm-objdump %t -d --symbolize-operands --no-show-raw-insn 
--no-leading-addr | \
+# RUN:   FileCheck %s --match-full-lines
+# RUN: llvm-objdump %t -d --symbolize-operands --no-show-raw-insn 
--no-leading-addr --adjust-vma=0x2000 | \
+# RUN:   FileCheck %s --match-full-lines
+
+## Expect to find the branch labels and global variable name.
+# CHECK:  <_start>:
+# CHECK-NEXT:   ldr x0, 
+# CHECK-NEXT: :
+# CHECK-NEXT:   adrp x1, 0x{{[68]}}000 

jh7370 wrote:

Personally, I'd prefer this to use either a) a FileCheck -D option to specify 
the expected value in each specific case, or b) a different check prefix for 
each case, to ensure the maximum tightness for the test, as this could pass 
even though the wrong value is being used.

https://github.com/llvm/llvm-project/pull/145009
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm-objdump] Support --symbolize-operand on AArch64 (PR #145009)

[James Henderson via llvm-branch-commits]

@@ -0,0 +1,42 @@
+# RUN: yaml2obj %s -o %t

jh7370 wrote:

Nit: there's a typo in the filename.

https://github.com/llvm/llvm-project/pull/145009
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [llvm-objdump] Support --symbolize-operand on AArch64 (PR #145009)

[James Henderson via llvm-branch-commits]

@@ -0,0 +1,77 @@
+# RUN: llvm-mc --triple=aarch64-elf --filetype=obj < %s | llvm-objdump -d -r 
--symbolize-operands --no-show-raw-insn --no-leading-addr - | FileCheck %s 
--match-full-lines
+
+# CHECK:  :
+# CHECK-NEXT:   b 
+# CHECK-NEXT:   tbz x0, #0x2c, 
+# CHECK-NEXT: :
+# CHECK-NEXT:   b.eq 
+# CHECK-NEXT: :
+# CHECK-NEXT:   cbz x1, 
+# CHECK-NEXT: :
+# CHECK-NEXT:   nop
+# CHECK-NEXT: :
+# CHECK-NEXT:   bl 
+# CHECK-NEXT: R_AARCH64_CALL26 fn2
+# CHECK-NEXT:   bl 
+# CHECK-NEXT:   adr x0, 
+# CHECK-NEXT: :
+# CHECK-NEXT:   adr x1, 
+# CHECK-NEXT: R_AARCH64_ADR_PREL_LO21 fn2
+# CHECK-NEXT:   adr x2, 
+# CHECK-NEXT:   ldr w0, 
+# CHECK-NEXT: :
+# CHECK-NEXT:   ldr w0, 
+# CHECK-NEXT: R_AARCH64_LD_PREL_LO19 fn2
+# CHECK-NEXT:   ret
+# CHECK-NEXT:   nop
+# CHECK-NEXT:   nop
+# CHECK-NEXT:   nop
+# CHECK-EMPTY:
+# CHECK-NEXT: :
+# CHECK-NEXT:   bl 
+# CHECK-NEXT:   adrp x3, 0x0 
+# CHECK-NEXT: R_AARCH64_ADR_PREL_PG_HI21 fn2
+# CHECK-NEXT:   add x3, x3, #0x0
+# CHECK-NEXT: R_AARCH64_ADD_ABS_LO12_NC fn2
+# CHECK-NEXT:   adrp x3, 0x0 
+# CHECK-NEXT: R_AARCH64_ADR_PREL_PG_HI21 fn2
+# CHECK-NEXT:   ldr x0, [x3]
+# CHECK-NEXT: R_AARCH64_LDST64_ABS_LO12_NC fn2
+# CHECK-NEXT:   ret
+# CHECK-NEXT:   nop
+# CHECK-NEXT:   nop
+# CHECK-NEXT: :
+# CHECK-NEXT:   ret
+
+.p2align 4
+.global fn1
+fn1:
+b 0f
+tbz x0, 44, 2f
+0:  b.eq 1f
+1:  cbz x1, 0b
+2:  nop
+bl fn2
+bl .Lfn2
+adr x0, 2b
+adr x1, fn2
+adr x2, .Lfn2
+ldr w0, 2b
+ldr w0, fn2
+ret
+
+.p2align 4
+.global fn2
+fn2:
+.Lfn2: # local label for non-interposable call
+bl .Lfn3
+# In future, we might identify the pairs and symbolize the operands 
properly

jh7370 wrote:

```suggestion
## In future, we might identify the pairs and symbolize the operands 
properly.
```

https://github.com/llvm/llvm-project/pull/145009
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [llvm-objdump] Support --symbolize-operand on AArch64 (PR #145009)

[James Henderson via llvm-branch-commits]

@@ -1813,6 +1817,12 @@ void AArch64InstPrinter::printAdrAdrpLabel(const MCInst 
*MI, uint64_t Address,
unsigned OpNum,
const MCSubtargetInfo &STI,
raw_ostream &O) {
+  // Do not print the numberic target address when symbolizing.

jh7370 wrote:

```suggestion
  // Do not print the numeric target address when symbolizing.
```

https://github.com/llvm/llvm-project/pull/145009
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [llvm-objdump] Support --symbolize-operand on AArch64 (PR #145009)

[James Henderson via llvm-branch-commits]

https://github.com/jh7370 edited 
https://github.com/llvm/llvm-project/pull/145009
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [llvm-objdump] Support --symbolize-operand on AArch64 (PR #145009)

[James Henderson via llvm-branch-commits]

@@ -0,0 +1,77 @@
+# RUN: llvm-mc --triple=aarch64-elf --filetype=obj < %s | llvm-objdump -d -r 
--symbolize-operands --no-show-raw-insn --no-leading-addr - | FileCheck %s 
--match-full-lines
+
+# CHECK:  :
+# CHECK-NEXT:   b 
+# CHECK-NEXT:   tbz x0, #0x2c, 
+# CHECK-NEXT: :
+# CHECK-NEXT:   b.eq 
+# CHECK-NEXT: :
+# CHECK-NEXT:   cbz x1, 
+# CHECK-NEXT: :
+# CHECK-NEXT:   nop
+# CHECK-NEXT: :
+# CHECK-NEXT:   bl 
+# CHECK-NEXT: R_AARCH64_CALL26 fn2
+# CHECK-NEXT:   bl 
+# CHECK-NEXT:   adr x0, 
+# CHECK-NEXT: :
+# CHECK-NEXT:   adr x1, 
+# CHECK-NEXT: R_AARCH64_ADR_PREL_LO21 fn2
+# CHECK-NEXT:   adr x2, 
+# CHECK-NEXT:   ldr w0, 
+# CHECK-NEXT: :
+# CHECK-NEXT:   ldr w0, 
+# CHECK-NEXT: R_AARCH64_LD_PREL_LO19 fn2
+# CHECK-NEXT:   ret
+# CHECK-NEXT:   nop
+# CHECK-NEXT:   nop
+# CHECK-NEXT:   nop
+# CHECK-EMPTY:
+# CHECK-NEXT: :
+# CHECK-NEXT:   bl 
+# CHECK-NEXT:   adrp x3, 0x0 
+# CHECK-NEXT: R_AARCH64_ADR_PREL_PG_HI21 fn2
+# CHECK-NEXT:   add x3, x3, #0x0
+# CHECK-NEXT: R_AARCH64_ADD_ABS_LO12_NC fn2
+# CHECK-NEXT:   adrp x3, 0x0 
+# CHECK-NEXT: R_AARCH64_ADR_PREL_PG_HI21 fn2
+# CHECK-NEXT:   ldr x0, [x3]
+# CHECK-NEXT: R_AARCH64_LDST64_ABS_LO12_NC fn2
+# CHECK-NEXT:   ret
+# CHECK-NEXT:   nop
+# CHECK-NEXT:   nop
+# CHECK-NEXT: :
+# CHECK-NEXT:   ret
+
+.p2align 4
+.global fn1
+fn1:
+b 0f
+tbz x0, 44, 2f
+0:  b.eq 1f
+1:  cbz x1, 0b
+2:  nop
+bl fn2
+bl .Lfn2
+adr x0, 2b
+adr x1, fn2
+adr x2, .Lfn2
+ldr w0, 2b
+ldr w0, fn2
+ret
+
+.p2align 4
+.global fn2
+fn2:
+.Lfn2: # local label for non-interposable call
+bl .Lfn3
+# In future, we might identify the pairs and symbolize the operands 
properly
+adrp x3, fn2
+add x3, x3, :lo12:fn2
+adrp x3, fn2
+ldr x0, [x3, :lo12:fn2]
+ret
+
+.p2align 4
+.Lfn3: # private function

jh7370 wrote:

```suggestion
.Lfn3: ## Private function
```

https://github.com/llvm/llvm-project/pull/145009
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [llvm-objdump] Support --symbolize-operand on AArch64 (PR #145009)

[James Henderson via llvm-branch-commits]

@@ -1784,6 +1784,10 @@ void AArch64InstPrinter::printAlignedLabel(const MCInst 
*MI, uint64_t Address,
unsigned OpNum,
const MCSubtargetInfo &STI,
raw_ostream &O) {
+  // Do not print the numberic target address when symbolizing.

jh7370 wrote:

```suggestion
  // Do not print the numeric target address when symbolizing.
```

https://github.com/llvm/llvm-project/pull/145009
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [llvm-objdump] Support --symbolize-operand on AArch64 (PR #145009)

[James Henderson via llvm-branch-commits]

@@ -0,0 +1,77 @@
+# RUN: llvm-mc --triple=aarch64-elf --filetype=obj < %s | llvm-objdump -d -r 
--symbolize-operands --no-show-raw-insn --no-leading-addr - | FileCheck %s 
--match-full-lines

jh7370 wrote:

Nit: let's split this line over multiple lines for readability.
```suggestion
# RUN: llvm-mc --triple=aarch64-elf --filetype=obj < %s | \
# RUN:   llvm-objdump -d -r --symbolize-operands --no-show-raw-insn 
--no-leading-addr - | \
# RUN:   FileCheck %s --match-full-lines
```

https://github.com/llvm/llvm-project/pull/145009
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [llvm-objdump] Support --symbolize-operand on AArch64 (PR #145009)

[James Henderson via llvm-branch-commits]

@@ -0,0 +1,77 @@
+# RUN: llvm-mc --triple=aarch64-elf --filetype=obj < %s | llvm-objdump -d -r 
--symbolize-operands --no-show-raw-insn --no-leading-addr - | FileCheck %s 
--match-full-lines
+
+# CHECK:  :
+# CHECK-NEXT:   b 
+# CHECK-NEXT:   tbz x0, #0x2c, 
+# CHECK-NEXT: :
+# CHECK-NEXT:   b.eq 
+# CHECK-NEXT: :
+# CHECK-NEXT:   cbz x1, 
+# CHECK-NEXT: :
+# CHECK-NEXT:   nop
+# CHECK-NEXT: :
+# CHECK-NEXT:   bl 
+# CHECK-NEXT: R_AARCH64_CALL26 fn2
+# CHECK-NEXT:   bl 
+# CHECK-NEXT:   adr x0, 
+# CHECK-NEXT: :
+# CHECK-NEXT:   adr x1, 
+# CHECK-NEXT: R_AARCH64_ADR_PREL_LO21 fn2
+# CHECK-NEXT:   adr x2, 
+# CHECK-NEXT:   ldr w0, 
+# CHECK-NEXT: :
+# CHECK-NEXT:   ldr w0, 
+# CHECK-NEXT: R_AARCH64_LD_PREL_LO19 fn2
+# CHECK-NEXT:   ret
+# CHECK-NEXT:   nop
+# CHECK-NEXT:   nop
+# CHECK-NEXT:   nop
+# CHECK-EMPTY:
+# CHECK-NEXT: :
+# CHECK-NEXT:   bl 
+# CHECK-NEXT:   adrp x3, 0x0 
+# CHECK-NEXT: R_AARCH64_ADR_PREL_PG_HI21 fn2
+# CHECK-NEXT:   add x3, x3, #0x0
+# CHECK-NEXT: R_AARCH64_ADD_ABS_LO12_NC fn2
+# CHECK-NEXT:   adrp x3, 0x0 
+# CHECK-NEXT: R_AARCH64_ADR_PREL_PG_HI21 fn2
+# CHECK-NEXT:   ldr x0, [x3]
+# CHECK-NEXT: R_AARCH64_LDST64_ABS_LO12_NC fn2
+# CHECK-NEXT:   ret
+# CHECK-NEXT:   nop
+# CHECK-NEXT:   nop
+# CHECK-NEXT: :
+# CHECK-NEXT:   ret
+
+.p2align 4
+.global fn1
+fn1:
+b 0f
+tbz x0, 44, 2f
+0:  b.eq 1f
+1:  cbz x1, 0b
+2:  nop
+bl fn2
+bl .Lfn2
+adr x0, 2b
+adr x1, fn2
+adr x2, .Lfn2
+ldr w0, 2b
+ldr w0, fn2
+ret
+
+.p2align 4
+.global fn2
+fn2:
+.Lfn2: # local label for non-interposable call

jh7370 wrote:

```suggestion
.Lfn2: ## Local label for non-interposable call.
```

https://github.com/llvm/llvm-project/pull/145009
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [llvm-objdump] Support --symbolize-operand on AArch64 (PR #145009)

[James Henderson via llvm-branch-commits]

https://github.com/jh7370 commented:

Basically looks good. Just some typos and other nits. Also, the documentation 
for the option says it works only for PPC and X86. Please could you update this 
and double-check whether the command-line help has the same note.

https://github.com/llvm/llvm-project/pull/145009
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits