[LLD] Adding support for RELA for CG Profile.

[ayermolo]

Summary

This is a follow up to https://reviews.llvm.org/D104080, and https://github.com/llvm/llvm-project/commit/ca3bdb57fa1ac98b711a735de048c12b5fdd8086#diff-e64a48fabe31db213a631fdc5f2acb51bdddf3f16a8fb2928784f4c579229585. The implementation of call graph profile was changed from a black box section to relocation approach. This was done to be compatible with post processing tools like strip/objcopy, and llvm equivalent. When they are invoked on object file before the final linking step with this new approach the symbol indices correctness is preserved.

The GNU binutils tools change the REL section to RELA section, unlike llvm tools. For example when strip -S is run on the ELF object files, as an intermediate step before linking. To preserve compatibility this patch extends implementation in LLD and ELFDumper to support both REL and RELA sections for call graph profile.

[ayermolo]

removing header include that sneaked in somehow

[MaskRay]

I have changed MC to unconditionally emit REL, so this change is not needed.

[ayermolo]

In D105217#2850892, @MaskRay wrote:

I have changed MC to unconditionally emit REL, so this change is not needed.

Unfortunately when running strip -S on ELF object files it converts REL to RELA.

Before:

[85] .llvm.call-graph-profile LLVM_CALL_GRAPH_PROFILE 0000000000000000 00db01 000168 08   E 92   0  1
[86] .rel.llvm.call-graph-profile REL  0000000000000000 01ec18 0005a0 10     92  85  8

After:

[76] .llvm.call-graph-profile LLVM_CALL_GRAPH_PROFILE 0000000000000000 0056aa 000168 08   E  0   0  1
[77] .rela.llvm.call-graph-profile RELA 0000000000000000 00dd18 000870 18   I 81  76  8

Supporting usage model of running strip -S on object files before linking was original motivation for this changing CG Call graph to use relocations.

[modimo]

Thanks for the fix. Please add a test case of what a stripped binary would look like (yaml2obj probably easiest way to do this) to make sure this works. Also are there llvm-readobj changes that need to be made?

lld/ELF/Driver.cpp

63

Needed?

868

I don't think you need this vector, the getIndex lambda can be generalized as a templated lambda/function based on ArrayRef

872

Add a warning + bailout if a binary every has both for some weird reason?

lld/ELF/InputFiles.h

254

Fix up comments to reflect that there is "always" here now.

[ayermolo]

lld/ELF/Driver.cpp

868

I wanted to doing a rel/rela check on each invocation of helper function.

[MaskRay]

I feel uneasy with the additional complexity. I am not sure we want this just to make strip -S happy. Can you use llvm-strip -S?

[ayermolo]

In D105217#2850944, @MaskRay wrote:

I feel uneasy with the additional complexity. I am not sure we want this just to make strip -S happy. Can you use llvm-strip -S?

Although llvm-strip does have the "correct/expected" behavior I think it's a too strict requirement on the users. Specifically I am thinking of large build systems with multiple projects. Right now it will be an assert

if (obj->cgProfileRel.size() != obj->cgProfile.size() * 2)
   fatal("number of relocations doesn't match Weights");

Which in context is not a descriptive error message.
Owners of projects will need to dig in to LLD source code, and change their workflow.

Also strip and objcopy are standard GNU tools that I think used interchangeably with llvm tools, and it's worth for LLD to continue to support them, and not force users in to using llvm tools.

I understand that this ads complexity, but I think the benefit of enabling support for more tools and reducing work on users of lld out-weights it.

[MaskRay]

Why is strip -S is part of the step running on intermediate object files?

The usually operation is to do strip only on linked images. If you want to have smaller intermediate object files, you may use -gsplit-dwarf or -gsplit-dwarf=single.

[ayermolo]

In D105217#2851133, @MaskRay wrote:

Why is strip -S is part of the step running on intermediate object files?

The usually operation is to do strip only on linked images. If you want to have smaller intermediate object files, you may use -gsplit-dwarf or -gsplit-dwarf=single.

Good question. My understanding of the usage model after talking to someone knowledgable in build system is that there are two issues. First we have a large set of pre-build libraries that various projects link against and they are build with monolithic debug information. Second is how caching of object files works within the build system. It allows flexibility for projects to re-use objects with and without debug information. Second part can be mitigated if build system supported dwo files, but right now it doesn't.
There is another potential issue. For example if there is some post processing tool for object files/binaries that doesn't support split dwarf. As an example until recently BOLT project only supported monolithic debug information.

[MaskRay]

First, .llvm.call-graph-profile is only emitted by -fprofile-use= and -fprofile-sample-use=, instrumentation PGO and sample PGO.
The use case is very specific. For sample PGO/BOLT there are other requirements from an external tool converting linux-perf data to a profile format recognized by llvm-project.
I can imagine that BOLT may have more requirements on LLVM tooling.
So I don't see why requiring llvm-strip will be another hindrance.
Also keep in mind that GNU binutils doesn't recognize the section type SHT_LLVM_*. (Folks have added dumping support to llvm-readobj.)

Second is how caching of object files works within the build system. It allows flexibility for projects to re-use objects with and without debug information.

If linker input size is not a concern, you may use ld -S instead of strip -S on .o files.

[jhenderson]

I don't think the additional complexity is all that much, especially given there's an actual use-case for it. It'd be different if the case was some hypothetical situation, but it isn't. Not all systems have all of LLVM installed as their toolchain, so forcing people away from using GNU tools seems like the wrong approach to me.

[ayermolo]

In D105217#2851379, @MaskRay wrote:

First, .llvm.call-graph-profile is only emitted by -fprofile-use= and -fprofile-sample-use=, instrumentation PGO and sample PGO.
The use case is very specific. For sample PGO/BOLT there are other requirements from an external tool converting linux-perf data to a profile format recognized by llvm-project.
I can imagine that BOLT may have more requirements on LLVM tooling.
So I don't see why requiring llvm-strip will be another hindrance.
Also keep in mind that GNU binutils doesn't recognize the section type SHT_LLVM_*. (Folks have added dumping support to llvm-readobj.)

Second is how caching of object files works within the build system. It allows flexibility for projects to re-use objects with and without debug information.

If linker input size is not a concern, you may use ld -S instead of strip -S on .o files.

Linker input size is a concern. But also moving all the object files (gigs worth) around from machines where they are cached to ones where final linking step is happening.
I brought up BOLT just in context of debug fission, and that it's not always possible to enable it. Depending on the work flow. Not as an argument for this patch. Sorry for confusion.
Speaking of distributed build environment. As James pointed out, they might not have full llvm toolchain installed. I understand that this ads complexity, but it's very small and it enables maximum compatibility of LLD with standard tools that is used in production.

[MaskRay]

I filed a binutils bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=28035 Perhaps you can chime in?
The support needs a comment that this is specifically for GNU strip.

That said, my main objection is that we now waste additional 16 bytes for InputFile. Can it be avoided?

lld/ELF/Driver.cpp

864

drop braces

[wenlei]

In D105217#2851379, @MaskRay wrote:

First, .llvm.call-graph-profile is only emitted by -fprofile-use= and -fprofile-sample-use=, instrumentation PGO and sample PGO.
The use case is very specific.

Not sure if I follow this. If what you meant is we don't need to have good support for it since this call graph profile is not used by everyone... I'm afraid I don't agree: 1. We used this broadly for hundreds of workloads. 2. Toolchains have many features most of which aren't used by many, but as long as those who use them are willing to maintain and improve it, why would we want to block such work just because it's not a mainstream feature?

For sample PGO/BOLT there are other requirements from an external tool converting linux-perf data to a profile format recognized by llvm-project.
I can imagine that BOLT may have more requirements on LLVM tooling.
So I don't see why requiring llvm-strip will be another hindrance.

This is more of a build system issue - requiring all gnu tools to be replaced by llvm tools in any large organization is going to be very difficult. I think it's reasonable to support some level of compatibility if the complexity isn't high.

In fact, there're many precedences for that. In LLD, we have a list of silently ignored switches for compatibility. We could insist build system changes for all instead of accommodate them in toolchain, but we favored compatibility.

You mentioned extra complexity, while I agree that if possible simpler implementation and tighter contract is better, but the trade off here between very minor complexity and compatibility seem not very different from those silently ignored switches.

Also keep in mind that GNU binutils doesn't recognize the section type SHT_LLVM_*. (Folks have added dumping support to llvm-readobj.)

Second is how caching of object files works within the build system. It allows flexibility for projects to re-use objects with and without debug information.

If linker input size is not a concern, you may use ld -S instead of strip -S on .o files.

In D105217#2852279, @jhenderson wrote:

I don't think the additional complexity is all that much, especially given there's an actual use-case for it. It'd be different if the case was some hypothetical situation, but it isn't. Not all systems have all of LLVM installed as their toolchain, so forcing people away from using GNU tools seems like the wrong approach to me.

Exactly. As mentioned above, we have precedence for supporting some level of compatibility. Insisting on simplicity and closed toolchain would do more harm than good.

[MaskRay]

In D105217#2855739, @wenlei wrote:

In D105217#2851379, @MaskRay wrote:

First, .llvm.call-graph-profile is only emitted by -fprofile-use= and -fprofile-sample-use=, instrumentation PGO and sample PGO.
The use case is very specific.

Not sure if I follow this. If what you meant is we don't need to have good support for it since this call graph profile is not used by everyone...

No.

I'm afraid I don't agree: 1. We used this broadly for hundreds of workloads. 2. Toolchains have many features most of which aren't used by many, but as long as those who use them are willing to maintain and improve it, why would we want to block such work just because it's not a mainstream feature?

I meant: some features have some particular requirement. We don't want to add support for something nobody uses.
For this point, I saw this patch so I knew you are going to use it. If it didn't add 16-bytes to each InputFile I would be ok with it.
However, it has such overhead so I need to balance the needs with the costs and want to ensure you would not add the cost if you could fix the build system internally.

In D105217#2852279, @jhenderson wrote:

I don't think the additional complexity is all that much, especially given there's an actual use-case for it. It'd be different if the case was some hypothetical situation, but it isn't. Not all systems have all of LLVM installed as their toolchain, so forcing people away from using GNU tools seems like the wrong approach to me.

Exactly. As mentioned above, we have precedence for supporting some level of compatibility. Insisting on simplicity and closed toolchain would do more harm than good.

See my previous comment. My main concern is the size overhead to InputFile. I am thinking we are paying too much for a relatively less useful feature.

The fatal issue can be addressed by, e.g. emitting a warning instead or ignoring the section completely.

[ayermolo]

In D105217#2855688, @MaskRay wrote:

I filed a binutils bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=28035 Perhaps you can chime in?
The support needs a comment that this is specifically for GNU strip.

That said, my main objection is that we now waste additional 16 bytes for InputFile. Can it be avoided?

We only waste 16 bytes if someone uses bin utilities vs llvm one. Some users might be OK with that waste vs trying to switch large fleet of servers to use llvm.
Thank you for creating a bug report, but even if it's fixed in the issue there is that servers are using older version of binutils.

[ayermolo]

To add. From pervious patch. With RELA it was 322KB. Each entry is 56 bytes ( 8 + 24 + 24), so thats 5750 entries. With REL (8 + 16 + 16), that will be 40 bytes per entry, and translates to 230KB.
The binary is ~113MB. So with RELA it's about 0.28%, with REL it's 0.2%.

[MaskRay]

My main concern has always been: I am not sure ArrayRef<Elf_Rel> cgProfileRel; ArrayRef<Elf_Rela> cgProfileRela; is the correct design.

Previously I was ok because one ArrayRef just added 16 bytes. Now you are taking extra 16 bytes from each InputFile. Given the tiny benefit of this call graph profile optimization, I am not sure this is the good traceoff.

Can't you just not cache cgProfileRela?

[ayermolo]

Re-did lld part so that relocation sections are not cached.

[ayermolo]

In D105217#2860630, @MaskRay wrote:

My main concern has always been: I am not sure ArrayRef<Elf_Rel> cgProfileRel; ArrayRef<Elf_Rela> cgProfileRela; is the correct design.

Previously I was ok because one ArrayRef just added 16 bytes. Now you are taking extra 16 bytes from each InputFile. Given the tiny benefit of this call graph profile optimization, I am not sure this is the good traceoff.

Can't you just not cache cgProfileRela?

Oh. I see. Something like this? I guess downside is that linking time will go up slightly because we have to scan through all the sections again.

[MaskRay]

You also need a yaml2obj test case. This is adding new functionality. Any such patch needs a test case.

Oh. I see. Something like this? I guess downside is that linking time will go up slightly because we have to scan through all the sections again.

Yes, this is close. See my inline comment. The downside is likely negligible if you benchmark it... sizeof(InputSection) is ~184 bytes. I would be unhappy if the relatively minor feature takes 15% of its size.

lld/ELF/Driver.cpp

864

Not addressed, but see below: with inlining you can ignore this.

876

section index

886

< => !=

891

just inline getIndices here

lld/ELF/InputFiles.cpp

582

Replace cgProfile with cgProfileSectionIndex. Let processRelocationsCGSection (which probably should be renamed to something else, e.g. processCallGraphRelocations) bail out if cgProfileSectionIndex is 0 (SHN_UNDEF). You can also delete one loop there.

[ayermolo]

In D105217#2860864, @MaskRay wrote:

You also need a yaml2obj test case. This is adding new functionality. Any such patch needs a test case.

Oh. I see. Something like this? I guess downside is that linking time will go up slightly because we have to scan through all the sections again.

Yes, this is close. See my inline comment. The downside is likely negligible if you benchmark it... sizeof(InputSection) is ~184 bytes. I would be unhappy if the relatively minor feature takes 15% of its size.

Wanted to make sure it's on correct path, before adding tests, and elfDumper needs to be modified.

[ayermolo]

Updated ELFDumper and a test that uses yaml2obj, plus some other cleanup/feedback incorporation.

[MaskRay]

lld/ELF/InputFiles.h

256

uint32_t

[MaskRay]

lld/ELF/Driver.cpp

872

Delete the unneeded blank line

898

This consumes too much stack space. Perhaps SmallVector<uint32_t, 32>

lld already uses SmallVector<unsigned, 32> so using 32 will not increase binary size.

llvm/test/tools/llvm-readobj/ELF/call-graph-profile.test

259 ↗

(On Diff #357062)

Add a test comment: ## GNU strip may convert SHT_REL to SHT_RELA. Test we can handle SHT_RELA.

262 ↗

(On Diff #357062)

Delete elf-cg-profile RUN lines. The aliases are tested by dedicated tests, no need for duplicating.

292 ↗

(On Diff #357062)

Delete if unused or make it match the reality

299 ↗

(On Diff #357062)

The offsets should match the reality: they relocate the values (0x0, 0x8, 0x10, ...)

llvm/tools/llvm-readobj/ELFDumper.cpp

6727 ↗

(On Diff #357062)

Drop else since we are using the early return pattern.

6733 ↗

(On Diff #357062)

Add a comment: MC unconditionally produces SHT_REL but GNU strip may convert the format to SHT_RELA (https://sourceware.org/bugzilla/show_bug.cgi?id=28035)

I don't expect they will fix this any time soon, but good to have a reference to justify additional complexity here.

[ayermolo]

addressing comments

[MaskRay]

LG, @jhenderson may have more comments

llvm/tools/llvm-readobj/ELFDumper.cpp

6777 ↗

(On Diff #357095)

drop parens beside !=

[MaskRay]

Looks like if we run strip -S it changes rel to rela. Changed so that LLD, and ELFDumper, supports both REL and RELA for CG Profile.

Looks like => Make this certain. https://sourceware.org/bugzilla/show_bug.cgi?id=28035

[ayermolo]

In D105217#2863339, @MaskRay wrote:

Looks like if we run strip -S it changes rel to rela. Changed so that LLD, and ELFDumper, supports both REL and RELA for CG Profile.

Looks like => Make this certain. https://sourceware.org/bugzilla/show_bug.cgi?id=28035

My bad. Just my "verbal tic" :)

[ayermolo]

Addressing () comment.

[jhenderson]

Test case(s) for the LLD portion of this patch?

lld/ELF/Driver.cpp

868–869

A quick skim of the area shows // is used for comenting function-level comments.

896

lld/ELF/InputFiles.h

24

Do you need to add this include? My understanding of the style guide is that you don't need to add it, unless the code doesn't compile without (it is likely pulled in by other headers).

llvm/tools/llvm-readobj/ELFDumper.cpp

6705–6706 ↗

(On Diff #357097)

Style is overwhelmingly // for functions here. These don't need doxygen comments, since they're not part of a public interface.

6733 ↗

(On Diff #357097)

clang-format

6739–6741 ↗

(On Diff #357097)

Test case needed for this path.

[ayermolo]

addressing comments

[ayermolo]

In D105217#2863821, @jhenderson wrote:

Test case(s) for the LLD portion of this patch?

There doesn't seem to be any tests for LLD, even for old implementation. What would be best way? feed llvm bit code in to llvm-mc, run lld on it and check final binary symbol table for ordering? Add something to LLD to output from internal data structure?

lld/ELF/InputFiles.h

24

ugh, sneaked in somehow.

[ayermolo]

missed an update

[MaskRay]

In D105217#2865533, @ayermolo wrote:

In D105217#2863821, @jhenderson wrote:

Test case(s) for the LLD portion of this patch?

There doesn't seem to be any tests for LLD, even for old implementation. What would be best way? feed llvm bit code in to llvm-mc, run lld on it and check final binary symbol table for ordering? Add something to LLD to output from internal data structure?

See test/ELF/cgprofile-obj.s for .cg_profile directives. The old implementation only tested RELA, not REL. The current state is only REL. Now we need RELA for GNU objcopy/strip compatibility, we need yaml2obj tests because assemblers don't emit RELA.

Please mark resolved comments as "done" (press submit).

[ayermolo]

In D105217#2865544, @MaskRay wrote:

In D105217#2865533, @ayermolo wrote:

In D105217#2863821, @jhenderson wrote:

Test case(s) for the LLD portion of this patch?

There doesn't seem to be any tests for LLD, even for old implementation. What would be best way? feed llvm bit code in to llvm-mc, run lld on it and check final binary symbol table for ordering? Add something to LLD to output from internal data structure?

See test/ELF/cgprofile-obj.s for .cg_profile directives. The old implementation only tested RELA, not REL. The current state is only REL. Now we need RELA for GNU objcopy/strip compatibility, we need yaml2obj tests because assemblers don't emit RELA.

Please mark resolved comments as "done" (press submit).

Ah I see it. Not sure how I missed it.

[ayermolo]

Added LLD test.

[jhenderson]

lld/ELF/Driver.cpp

868–869

896

Ping? This hasn't been addressed...

lld/test/ELF/cgprofile-rela-obj.test

1 ↗

(On Diff #357396)

Add a comment (using '##' for comment markers) to this test to explain the purpose of this test.

I think you can also drop -obj from the test name.

4 ↗

(On Diff #357396)

You don't need to specify the entry point explicitly. If you really want to suppress the warning, I'd just rename one of the symbols to _start.

8 ↗

(On Diff #357396)

Nit: add a blank line between the RUN and YAML blocks.

I also have a personal preference for the flow of the test to be:

# RUN commands

# CHECK directives

YAML

llvm/test/tools/llvm-readobj/ELF/call-graph-profile.test

209 ↗

(On Diff #357396)

307 ↗

(On Diff #357396)

[ayermolo]

Addressing comments

lld/ELF/Driver.cpp

896

Sorry missed it.

lld/test/ELF/cgprofile-rela-obj.test

4 ↗

(On Diff #357396)

Hmm. Even with that still got warning: cannot find entry symbol _start; defaulting to 0x201120
Was probably doing something wrong. Just left as Aa.

[MaskRay]

lld/test/ELF/cgprofile-rela-obj.test

4 ↗

(On Diff #357396)

_start needs to be non-local. You can find the pattern in other tests.

.globl _start
_start:

[ayermolo]

Added _start

[ayermolo]

@MaskRay Gave it another shot. Got it to work this time. I guess global symbol needs to be at the end of Symbols in yaml. Previously I was getting linker error.

[MaskRay]

lld/test/ELF/cgprofile-rela.test

32 ↗

(On Diff #357614)

Delete unused AddressAlign: 0x10

72 ↗

(On Diff #357614)

Add Offset: 0x0

120 ↗

(On Diff #357614)

Delete STT_SECTION symbols not referenced by relocations.

[ayermolo]

cleaned up cgprofile-rela.text

[ayermolo]

Missed comment fix.

[jhenderson]

lld/test/ELF/cgprofile-rela.test

1 ↗

(On Diff #357667)

I'd rewrite the comment like this:

"Under some circumstances, GNU tools strip/objcopy change REL to RELA. Test that LLD can handle call graph profile data relocated with RELA relocations."

32 ↗

(On Diff #357667)

I assume your aim is for 2-byte sections? If so, you can replace these lines with Size: 2, which I think expresses the intent better.

63 ↗

(On Diff #357667)

I believe the Link: .symtab is implicit for relocation sections. You can remove it.

64 ↗

(On Diff #357667)

Similarly: I think the address align field has a default value for reloc sections. No need to explicitly specify it.

llvm/test/tools/llvm-readobj/ELF/call-graph-profile.test

209 ↗

(On Diff #357667)

Two typos.

307 ↗

(On Diff #357667)

[ayermolo]

Addressing rela test comments.

[ayermolo]

typos

[MaskRay]

lld/test/ELF/cgprofile-rela.test

1 ↗

(On Diff #357667)

You can attach https://sourceware.org/bugzilla/show_bug.cgi?id=28035 after "change REL to RELA"

[ayermolo]

Added link to bugzilla to the test.

[jhenderson]

LGTM, except for one remaining typo fix.

llvm/test/tools/llvm-readobj/ELF/call-graph-profile.test

307 ↗

(On Diff #357667)

Ping this typo fix.

[ayermolo]

Missed a typo.

[ayermolo]

Thanks for review. Will commit later today.

[MaskRay]

In D105217#2874507, @ayermolo wrote:

Thanks for review. Will commit later today.

Please update the summary (and commit message) about the use scenario.

lld/ELF/Driver.cpp

 #include "llvm/Support/GlobPattern.h"
 #include "llvm/Support/LEB128.h"
 #include "llvm/Support/Parallel.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/TarWriter.h"
 #include "llvm/Support/TargetSelect.h"
 #include "llvm/Support/TimeProfiler.h"
 #include "llvm/Support/raw_ostream.h"
 #include <cstdlib>
 #include <utility>
 
 using namespace llvm;
 using namespace llvm::ELF;
 using namespace llvm::object;
 using namespace llvm::sys;
 using namespace llvm::support;
 using namespace lld;
for (StringRef line : args::getLines(mb)) {
     }
 
     if (InputSectionBase *from = findSection(fields[0]))
       if (InputSectionBase *to = findSection(fields[1]))
         config->callGraphProfile[std::make_pair(from, to)] += count;
   }
 }
 
+/// Retrieves symbol indices either from REL or RELA section.
+template <class ELFTRel>
+static void getIndices(SmallVector<uint32_t, 128> &symbolIndices,
+                       ArrayRef<ELFTRel> cgProfileRel) {
+  for (const ELFTRel &rel : cgProfileRel) {
+    symbolIndices.push_back(rel.getSymbol(config->isMips64EL));
+  }
+}
+
 template <class ELFT> static void readCallGraphsFromObjectFiles() {
-  auto getIndex = [&](ObjFile<ELFT> *obj, uint32_t index) {
-    const Elf_Rel_Impl<ELFT, false> &rel = obj->cgProfileRel[index];
-    return rel.getSymbol(config->isMips64EL);
-  };
+  SmallVector<uint32_t, 128> symbolIndices;
 
   for (auto file : objectFiles) {
     auto *obj = cast<ObjFile<ELFT>>(file);
-    if (obj->cgProfileRel.empty())
+    if (obj->cgProfileRel.empty() && obj->cgProfileRela.empty())
       continue;
-    if (obj->cgProfileRel.size() != obj->cgProfile.size() * 2)
+    symbolIndices.clear();
+    if (!obj->cgProfileRel.empty())
+      getIndices(symbolIndices, obj->cgProfileRel);
+    else
+      getIndices(symbolIndices, obj->cgProfileRela);
+
+    if (symbolIndices.size() != obj->cgProfile.size() * 2)
       fatal("number of relocations doesn't match Weights");
     for (uint32_t i = 0, size = obj->cgProfile.size(); i < size; ++i) {
       const Elf_CGProfile_Impl<ELFT> &cgpe = obj->cgProfile[i];
-      uint32_t fromIndex = getIndex(obj, i * 2);
-      uint32_t toIndex = getIndex(obj, i * 2 + 1);
+      uint32_t fromIndex = symbolIndices[i * 2];
+      uint32_t toIndex = symbolIndices[i * 2 + 1];
       auto *fromSym = dyn_cast<Defined>(&obj->getSymbol(fromIndex));
       auto *toSym = dyn_cast<Defined>(&obj->getSymbol(toIndex));
       if (!fromSym || !toSym)
         continue;
 
       auto *from = dyn_cast_or_null<InputSectionBase>(fromSym->section);
       auto *to = dyn_cast_or_null<InputSectionBase>(toSym->section);
       if (from && to)
         config->callGraphProfile[{from, to}] += cgpe.cgp_weight;
     }
   }
 }
 
 static bool getCompressDebugSections(opt::InputArgList &args) {
   StringRef s = args.getLastArgValue(OPT_compress_debug_sections, "none");
   if (s == "none")
     return false;
   if (s != "zlib")
     error("unknown --compress-debug-sections value: " + s);
   if (!zlib::isAvailable())
     error("--compress-debug-sections: zlib is not available");

lld/ELF/InputFiles.h

 #include "llvm/ADT/CachedHashString.h"
 #include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/IR/Comdat.h"
 #include "llvm/Object/Archive.h"
 #include "llvm/Object/ELF.h"
 #include "llvm/Object/IRObjectFile.h"
 #include "llvm/Support/Threading.h"
 #include <map>
 
 namespace llvm {
 struct DILineInfo;
 class TarWriter;
 namespace lto {
 class InputFile;
 }
 } // namespace llvm
public:
   // but had one or more functions with the no_split_stack attribute.
   bool someNoSplitStack = false;
 
   // Pointer to this input file's .llvm_addrsig section, if it has one.
   const Elf_Shdr *addrsigSec = nullptr;
 
   // SHT_LLVM_CALL_GRAPH_PROFILE table.
   ArrayRef<Elf_CGProfile> cgProfile;
   // SHT_LLVM_CALL_GRAPH_PROFILE relocations, always in the REL format.
   ArrayRef<Elf_Rel> cgProfileRel;
+  // SHT_LLVM_CALL_GRAPH_PROFILE relocations, always in the RELA format.
+  ArrayRef<Elf_Rela> cgProfileRela;
 
   // Get cached DWARF information.
   DWARFCache *getDwarf();
 
 private:
   void initializeSections(bool ignoreComdats);
   void initializeSymbols();
   void initializeJustSymbols();

lld/ELF/InputFiles.cpp

void ObjFile<ELFT>::initializeSections(bool ignoreComdats) {
   // SHT_LLVM_CALL_GRAPH_PROFILE Section Index.
   size_t cgProfileSectionIndex = 0;
 
   for (size_t i = 0, e = objSections.size(); i < e; ++i) {
     if (this->sections[i] == &InputSection::discarded)
       continue;
     const Elf_Shdr &sec = objSections[i];
 
     if (sec.sh_type == ELF::SHT_LLVM_CALL_GRAPH_PROFILE) {
       cgProfile =
           check(obj.template getSectionContentsAsArray<Elf_CGProfile>(sec));
       cgProfileSectionIndex = i;
     }
 
     // SHF_EXCLUDE'ed sections are discarded by the linker. However,
     // if -r is given, we'll let the final link discard such sections.
     // This is compatible with GNU.
if (this->sections[i] == &InputSection::discarded)
       continue;
     const Elf_Shdr &sec = objSections[i];
 
     if (sec.sh_type == SHT_REL || sec.sh_type == SHT_RELA) {
       this->sections[i] = createInputSection(sec);
       if (cgProfileSectionIndex && sec.sh_info == cgProfileSectionIndex) {
         if (sec.sh_type == SHT_REL)
           cgProfileRel = CHECK(getObj().rels(sec), this);
+        else
+          cgProfileRela = CHECK(getObj().relas(sec), this);
       }
     }
 
     // A SHF_LINK_ORDER section with sh_link=0 is handled as if it did not have
     // the flag.
     if (!(sec.sh_flags & SHF_LINK_ORDER) || !sec.sh_link)
       continue;