lld: add experimental support for SHT_RELR sections.

[rahulchaudhry]

Summary

This change adds experimental support for SHT_RELR sections, proposed
here: https://groups.google.com/forum/#!topic/generic-abi/bX460iggiKg

Pass '--pack-dyn-relocs=relr' to enable generation of SHT_RELR section
and DT_RELR, DT_RELRSZ, and DT_RELRENT dynamic tags.

Definitions for the new ELF section type and dynamic array tags, as well
as the encoding used in the new section are all under discussion and are
subject to change. Use with caution!

Pass '--use-android-relr-tags' with '--pack-dyn-relocs=relr' to use
SHT_ANDROID_RELR section type instead of SHT_RELR, as well as
DT_ANDROID_RELR* dynamic tags instead of DT_RELR*. The generated
section contents are identical.

'--pack-dyn-relocs=android+relr --use-android-relr-tags' enables both
'--pack-dyn-relocs=android' and '--pack-dyn-relocs=relr': lld will
encode the relative relocations in a SHT_ANDROID_RELR section, and pack
the rest of the dynamic relocations in a SHT_ANDROID_REL(A) section.

[rahulchaudhry]

This patch depends on https://reviews.llvm.org/D47919

I'm still working on adding some unit tests, but I thought I'd send this in for now in case there is any high level feedback on the overall approach.

I've tested this by linking chrome (for amd64 and arm) with '-pie --pack-dyn-relocs=relr'.
For amd64, chrome binary size goes down from 163M to 148M.
For arm, chrome binary size goes down from 101M to 96M.
Installed the generated binaries on both amd64 and arm chromebooks.
The chromebooks boot fine. Played with the browser a little bit. Everything looks ok.
(Support for SHT_RELR is already present in glibc dynamic loader in Chrome OS).

[rahulchaudhry]

Added tests, ready for review.

[mcgrathr]

ELF/Driver.cpp

951

It doesn't seem right to start writing nonzero values into the section data on RELA machines for all relocs.
The addend should only be written in place for words actually converted to RELR slots.

[rahulchaudhry]

Write addend in section data only for the relocations in .relr.dyn.

[rahulchaudhry]

ELF/Driver.cpp

951

Moved the logic to RelocationBaseSection::addReloc() where Config->WriteAddends is actually checked.

[pcc]

ELF/Config.h

117–118

Can you add an enum class for the --pack-dyn-relocs flag instead of adding these bools?

ELF/SyntheticSections.cpp

1741

Please also include a brief description of the encoding as a comment in the code.

1747

I think you can avoid needing to error on this by only creating RELR relocations for relocations at even offsets in sections with sh_addralign >= 2. In practice I think this would be almost every section that might contain a relative relocation.

1755

Remove unnecessary parens.

1759

Remove unnecessary parens.

1763

Remove unnecessary parens.

ELF/SyntheticSections.h

477

Instead of making this virtual and teaching RelocationBaseSection about RELR I think we should add logic here:
http://llvm-cs.pcc.me.uk/tools/lld/ELF/Relocations.cpp#797
to directly add the relocation to RELR if applicable.

[ruiu]

ELF/Driver.cpp

859

nit: if you add {} to one of else if, please add it to all if and else ifs.

ELF/SyntheticSections.cpp

1446

I don't get the meaning of this comment. What does if required actually mean? I think that should be answered in the comment. Actually, I'd think instead of writing comment for each expression, you probably should write a function comment to give readers a big picture as to what this function is supposed to do.

1461

Add {}

1717

Please write a function comment so that the first-time reader can understand your code without hassle.

1718

This function seems a bit too long. Please consider splitting this into multiple small functions.

ELF/SyntheticSections.h

522

In lld, we try to keep the class hierarchy as shallow as possible. Please avoid class inheritance when possible.

[rahulchaudhry]

Relr is now defined directly as packed<uint>.
Added comment describing the SHT_RELR encoding.
Moved the logic for adding a relr relocation to Relocations.cpp.
RelocationBaseSection::addReloc is no longer a virtual function.

ELF/Config.h

117–118

I started on this, but it got clumsy very fast.
The problem is that these bools are not mutually exclusive.
e.g. for --pack-dyn-relocs=android-relr, both RelrPackDynRelocs and AndroidRelrPackDynRelocs are set to true. Most places look at RelrPackDynRelocs, and AndroidRelrPackDynRelocs is only checked to decide which tags to emit. This gets messy when you can only set an enum variable to Relr or AndroidRelr. Many places end up needing to check for both values.
Another example is that --pack-dyn-relocs=android-relr and --pack-dyn-relocs=android are not mutually exclusive. It's fine to have both on the command line, and the effect should be to move relative relocations to SHT_RELR, and pack the remaining relocations in SHT_REL/SHT_RELA using AndroidPackedRelocationSection.

ELF/SyntheticSections.cpp

1461

This logic is now moved to Relocations.cpp

1718

Ack.
The main logic in the function is computing the bitmap, which is 15 lines including comments beginning with 'if ((Base > 0) && (Base <= Current))'
The rest of the function is setting up common types and consts, sorting the offsets, and iterating over them.
I don't see an easy way to split it up without duplicating the common type and const declarations or moving them into the class.

1747

I guess the check would now be in Relocations.cpp before calling InX::RelrDyn->addReloc().
Any hint on what the check would be? I don't see any other obvious place in that file checking for section alignment.
I think this check should still be preserved, just in case something odd ends up here (maybe convert it to fatal?)

ELF/SyntheticSections.h

522

Ack. In this case, the existing hierarchy is

• RelocationBaseSection inherits from SyntheticSection
• RelocationSection and AndroidPackedRelocationSection both inherit from RelocationBaseSection

RelrPackedRelocationSection fits right here in the hierarchy with RelocationSection and AndroidPackedRelocationSection as siblings.

[pcc]

ELF/Config.h

117–118

for --pack-dyn-relocs=android-relr, both RelrPackDynRelocs and AndroidRelrPackDynRelocs are set to true. Most places look at RelrPackDynRelocs, and AndroidRelrPackDynRelocs is only checked to decide which tags to emit.

I was thinking that you would add a line to the end of this function http://llvm-cs.pcc.me.uk/tools/lld/ELF/Driver.cpp#928 like this:

Config->Relr = Config->PackDynRelocs == Relr || Config->PackDynRelocs == AndroidRelr;

then have the code check Config->Relr in most places.

Another example is that --pack-dyn-relocs=android-relr and --pack-dyn-relocs=android are not mutually exclusive. It's fine to have both on the command line, and the effect should be to move relative relocations to SHT_RELR, and pack the remaining relocations in SHT_REL/SHT_RELA using AndroidPackedRelocationSection.

That doesn't look like the current behaviour though?

That said, can we just make --pack-dyn-relocs=android-relr mean "use SHT_ANDROID_RELR and SHT_ANDROID_REL/SHT_ANDROID_RELA"? Is there any case in which it would be useful to have SHT_ANDROID_RELR combined with unpacked SHT_REL/SHT_RELA?

ELF/Relocations.cpp

786 ↗

(On Diff #152987)

Re SyntheticSections.cpp:1752 comment I think this can be something like if (InX::RelrDyn && Sec.Alignment >= 2 && Offset % 2 == 0) now.

ELF/SyntheticSections.cpp

1446–1456

I don't think you need to add logic here at all. Instead, you can add the static relocation directly to the input section in Relocations.cpp when you decide to add the relocation to RELR.

ELF/SyntheticSections.h

522

It doesn't really fit though because RelrPackedRelocationSection is unlike the other sections in that it can only store one specific type of relocation. With the change to add relocations directly to InX::RelrDyn I think you can just make this class derive from SyntheticSection and have it store a vector of (section, offset) pairs instead of DynamicRelocs.

[pcc]

ELF/SyntheticSections.cpp

1747

I think this check should still be preserved, just in case something odd ends up here (maybe convert it to fatal?)

We shouldn't expect this to happen because of the guarantees provided by the rest of the program, so you can make it an assert.

[ruiu]

ELF/SyntheticSections.cpp

1756

This is the same as Config->Wordsize.

1763

I think you can always use std::vector<uint64_t> instead of defining Word and using std::vector<Word> because the larger integral type will just work fine for 32-bit machines in this case.

1773

Could you use clang-format-diff to format your patch?

1780

I believe you can use uint64_t as well. We generally prefer uint64_t instead of the target-dependent integral type for the sake of simplicity.

[rahulchaudhry]

Added an enum class for the --pack-dyn-relocs flag.
Added another option "android+relr" that implies both "android" and "android-relr" packing.
Another place in Relocations.cpp needed change to add relative relocations in RelrDyn instead of RelaDyn.
Relocations are only added to RelrDyn if "Sec.Alignment >= 2 && Offset % 2 == 0".

[rahulchaudhry]

ELF/Config.h

117–118

I think it would be better to keep the two packing modes independent:

• For debugging, someone might want to enable SHT_ANDROID_RELR but not SHT_ANDROID_RELA, or vice-versa.
• At some later date, Android might decide to remove support for the custom (non-standard) SHT_ANDROID_RELA packing. This becomes cumbersome if SHT_ANDROID_RELR implies SHT_ANDROID_RELA.

I added another recognized form for this option: "android+relr", which is a combination of "android" and "android-relr".
The naming is a bit confusing now. The "+" means plus/addition, but the "-" means hyphen (not minus/subtraction).
Maybe "android-relr" should be renamed to "androidrelr" without the hyphen?

Also added an enum class, but that did not improve things much.
The three bools are still there, but now they're set in Driver.cpp:setConfigs() using the enum value in Config->PackDynRelocs.

ELF/Relocations.cpp

736 ↗

(On Diff #153417)

After logic to add relocations to RelrDyn was moved to Relocations.cpp, I noticed that chrome binary still had ~20,000 relative relocations left over in RelaDyn.
This is the place where those remaining relocations were coming from.
So moving this logic to the callers of addReloc() (instead of making addReloc virtual) does result in duplicating this logic.

There are a few other places that add RelativeRel to RelaDyn, but they're MipsGotSection::build(), so I assume they're mips specific.
I have not put the logic there yet, so those relocations may still end up in RelaDyn instead of RelrDyn.

ELF/SyntheticSections.cpp

1446–1456

There are at least two places where RelSec is set to either RelaDyn or RelrDyn. This logic for writing the addends would need to be in both places. There might be more places in the future, and it becomes all too easy (i.e. errorprone) to add a relocation to RelrDyn, but forget to write the addend for it in the section.
I think keeping this logic in one place is desirable.

ELF/SyntheticSections.h

522

Deriving RelrPackedRelocationSection directly from SyntheticSection has several consequence:

• It cannot use the addReloc() functions from RelocationBaseSection. It'd need its own addReloc() and a vector of (section, offset) pairs like you suggested. This affects all call sites that do RelSec->addReloc(). Currently RelSec can be InX::RelaDyn or InX::RelrDyn and the same addReloc() call works fine for both. I think there's some value to storing DynamicRelocs the same way for all types of relocation sections.

• RelrPackedRelocationSection needs to be a template on <class ELFT> (similar to RelocationSection and AndroidPackedRelocationSection). RelocationBaseSection is not templated, and as such, RelaDyn, RelaPlt, etc are all declared as RelocationBaseSection* in struct InX. Currently RelrDyn is also in struct InX as RelocationBaseSection*. If it inherits directly from SyntheticSection, it would need to be moved to struct In<ELFT>. This would mean all references to InX::RelrDyn would have to converted to In<ELFT>::RelrDyn. All this makes using or referencing RelrDyn very unlike using or referencing RelaDyn when it is conceptually very similar.

• On top of the above, there are at least some places where InX::RelrDyn is referenced, but class ELFT is not available. Converting to In<ELFT>::RelrDyn would mean turning those functions into template versions with <class ELFT> as well. This can have a cascading effect, reversing some of the detemplating effort that I see has taken place in recent past.

I am not convinced that RelrPackedRelocationSection is so unlike the other classes for relocation sections that it doesn't fit in the heirarchy here and it's worth going through all this trouble to avoid inheriting from RelocationBaseSection.

[pcc]

ELF/Config.h

117–118

Seems reasonable enough, and if we're going to go that way I think I'm convinced that you don't need the enum class.

I think you can avoid needing to have both android-relr and android+relr by having the flags look like this:

• --pack-dyn-relocs=android -- use Android packing
• --pack-dyn-relocs=relr -- use RELR packing
• --pack-dyn-relocs=android+relr -- do both of the above
• --use-android-relr-tags -- use SHT_ANDROID_RELR tag instead of SHT_RELR

ELF/Relocations.cpp

736 ↗

(On Diff #153417)

You could always add a function addRelativeReloc and call it from both places as well as the places in the MIPS code.

ELF/SyntheticSections.cpp

1446–1456

There are at least two places where RelSec is set to either RelaDyn or RelrDyn.

Those places become a single place if you introduce addRelativeReloc. If for whatever reason new code ends up calling InX::RelaDyn->addReloc (although I don't see why since the author of that code would probably follow existing code that calls addRelativeReloc), that wouldn't be an error, it would just mean that that relocation wouldn't be compressed.

ELF/SyntheticSections.h

522

This affects all call sites that do RelSec->addReloc()

Only the one in addRelativeReloc.

RelrPackedRelocationSection needs to be a template on <class ELFT> (similar to RelocationSection and AndroidPackedRelocationSection).

Yes, that's annoying. You can solve it in the same way as we avoid templating RelocationBaseSection on ELFT: introduce a RelrBaseSection which stores the (section, offset) pairs and derive RelrSection<ELFT> from it.

I am not convinced that RelrPackedRelocationSection is so unlike the other classes for relocation sections that it doesn't fit in the heirarchy

From my perspective it's not so much a matter of fitting in a hierarchy but using appropriate data structures. There's no need to use a data structure for arbitrary dynamic relocations when a simpler one would suffice.

test/ELF/pack-dyn-relocs.s

1

Please add a test showing that misaligned relative relocations end up in .rel.dyn or .rela.dyn.

[jhenderson]

I'm a little concerned that the only test for this is aarch64/arm specific, and won't run on hosts with only x86 enabled. We tend to use x86/x86_64 for generic testing, from what I understand.

I'm not actually sure what the solution is though, since it doesn't make sense to duplicate the test logic really, and some of the test is android (so arm, if I'm not mistaken) specific.

[rahulchaudhry]

Reverted the enum class for --pack-dyn-relocs.
Added class RelativeReloc that is similar to DynamicReloc but only stores relative relocations.
Added class RelrBaseSection that is similar to RelocationBaseSection but stores RelativeRelocs instead of DynamicRelocs.
RelrPackedRelocationSection now inherits from RelrBaseSection.
Updated test to add a relative relocation with odd offset.

[rahulchaudhry]

ELF/Config.h

117–118

Added new flag --use-android-relr-tags.

ELF/SyntheticSections.h

522

Ah.. I see. So a little bit of code duplication is okay in the interest of keeping the class hierarchy more flat.
I added RelrBaseSection, which stores std::vector<RelativeReloc>.
RelativeReloc is similar to DynamicReloc, but only stores Section and Offset.

[pcc]

Thanks, this is closer to what I had in mind. But I was imagining that addRelativeReloc would be a free function so that you can move the rest of the logic into it. I wrote a patch on top of yours with what I had in mind and attached it to the review. I also made a number of smaller changes as well.

0001-Changes.patch11 KBDownload

ELF/Driver.cpp

868

I was imagining that --use-android-relr-tags would be orthogonal to --pack-dyn-relocs=android+relr, so that you get the standard relr tags unless the user specifically asks otherwise.

869–872

You don't need this part because the flags are initialized to false.

ELF/SyntheticSections.cpp

1505

As the comment says there is no need for a link if all relocations are relative. In my patch I just removed this function.

[rahulchaudhry]

Applied patch from pcc and made --use-android-relr-tags independent of --pack-dyn-relocs.

[rahulchaudhry]

Thanks for the patch. Things look much cleaner now.

[pcc]

Looks great. Rui, what do you think?

[ruiu]

Overall looking good.

ELF/Driver.cpp

866–867

Move this before the code to initialize Config->UnresolvedSymbols.

ELF/Relocations.cpp

715 ↗

(On Diff #153601)

This function needs comment. (Any non-trivial code needs comment so that the code can be understood by first-time readers.)

ELF/SyntheticSections.cpp

1709

Elf_Relr -> Config->Wordsize

1759

This loop looks odd to me because it doesn't reflect the logic that this loop should implement. Currently, the loop looks like this

while () {
   do_something();
   if (...)
    add_a_leading_address_entry();
   else
    add_a_bitmap();
}

However, IIUC, the straightforward translation of the logic in the pseudo code should look like this:

while (there's remaining relocation) {
  add_a_first_address(the first remaining relocation);
  while (more relocations can be folded)
    add_a_bitmap(foldable relocations);
}

As a result, I think you had to write non-obvious code to determine whether you need to add a leading address entry or a bitmap. I believe this code can be (and perhaps should be) improved. That said, I'm fine if you submit this code as-is. I'll try to address that as a follow-up patch.

1781

Please use typename ELFT::uint instead of Elf_Relr.

ELF/SyntheticSections.h

534

Please write a comment as to what this class represents.

547

Use typename ELFT::uint instead of ELF_Relr.

[rahulchaudhry]

Added some comments, plus some minor edits.

ELF/SyntheticSections.cpp

1781

See above.

ELF/SyntheticSections.h

547

I don't think these are interchangeable here. Elf_Relr is defined as packed<uint> in ELFT. The packed<> takes care of endianness conversion when cross-compiling for a target architecture with a different endianness.
RelrRelocs is written to output using a memcpy() in writeTo(). If we convert RelrRelocs to store raw ELFT::uint values, we'll need to do byte swapping in writeTo() in case the target endianness is different.
Maybe I'm missing something or understood it all wrong.

[rahulchaudhry]

Some updates from the testing front:

I took the latest version of this patch and used it to link Chrome for Chrome OS (with '--pack-dyn-relocs=relr', for both amd64 and arm).
Flashed the newly built chrome binaries onto two chromebooks.
They boot fine. Everything seems to be working.

Also used this patch to do a full Android build for Pixel XL (with '--pack-dyn-relocs=android+relr --use-android-relr-tags').
Flashed the image to a test device.
It boots fine. Everything seems to be working.
Here's the CL for some size comparison numbers between different --pack-dyn-relocs options: https://android-review.googlesource.com/709131

[pcc]

ELF/SyntheticSections.cpp

1781

I guess uint would work here because the value is only stored temporarily in R.

That said, it looks like you could simplify the code a little by changing the code in the two branches to push values onto RelrRelocs directly instead of storing them in R.

[rahulchaudhry]

ELF/SyntheticSections.cpp

1781

The assignment to R is doing an implicit conversion from uint to packed<uint>.
If I try to do RelrRelocs.push_back(Current), build fails with "no matching function for call to ...".
We'll need explicit conversion, i.e.

RelrRelocs.push_back(Elf_Relr(Current));

and

RelrRelocs.push_back(Elf_Relr((Bits << 1) | 1));

It makes the conversion explicit (maybe that's better), and it has to be done at two places.

Alternately, I can make RelrRelocs a vector<uint> as Rui suggested, then modify writeTo to iterate over entries and convert each before writing instead of using a single memcpy to write all of them.

[pcc]

ELF/SyntheticSections.cpp

1781

I think that making the conversion explicit here is fine and probably a little clearer too, so that's what I'd go with.

[rahulchaudhry]

Made the conversion to Elf_Relr explicit.

[ruiu]

LGTM

ELF/Relocations.cpp

717–723 ↗

(On Diff #153991)

Well, this comment explains what you are doing in this function, but that's what I can find by reading this function, so I don't find this very helpful. I'd explain the intention instead. For example, this comment should answer to the question why the offset must be aligned to 2, what is RelrDyn in the first place, etc.

Now that I understood the entire patch, I'll rewrite this patch after you commit this change so that we can proceed, though.

[rahulchaudhry]

ELF/Relocations.cpp

717–723 ↗

(On Diff #153991)

I cannot commit this change as I do not have write access.
I won't ask you to commit it either, since it is clear that you are not happy with this change.
You've indicated a couple of times that you would like to rewrite this patch.
I would suggest that you re-implement the functionality to your liking, and simply commit that instead.
Unfortunately, I will not be able to spend any more time on this.
Thanks for your time,
Rahul

ELF/Config.h

struct Configuration {
   std::vector<SymbolVersion> VersionScriptGlobals;
   std::vector<SymbolVersion> VersionScriptLocals;
   std::vector<uint8_t> BuildIdVector;
   llvm::MapVector<std::pair<const InputSectionBase *, const InputSectionBase *>,
                   uint64_t>
       CallGraphProfile;
   bool AllowMultipleDefinition;
   bool AndroidPackDynRelocs = false;
+  bool RelrPackDynRelocs = false;
+  bool AndroidRelrPackDynRelocs = false;
   bool ARMHasBlx = false;
   bool ARMHasMovtMovw = false;
   bool ARMJ1J2BranchEncoding = false;
   bool AsNeeded = false;
   bool Bsymbolic;
   bool BsymbolicFunctions;
   bool CheckSections;
   bool CompressDebugSections;

ELF/Driver.cpp

if (Config->Omagic)
     Config->ZRelro = false;
 
   std::tie(Config->BuildId, Config->BuildIdVector) = getBuildId(Args);
 
   if (auto *Arg = Args.getLastArg(OPT_pack_dyn_relocs)) {
     StringRef S = Arg->getValue();
     if (S == "android")
       Config->AndroidPackDynRelocs = true;
+    else if (S == "relr")
+      Config->RelrPackDynRelocs = true;
+    else if (S == "android-relr") {
+      Config->RelrPackDynRelocs = true;
+      Config->AndroidRelrPackDynRelocs = true;
+    }
     else if (S != "none")
       error("unknown -pack-dyn-relocs format: " + S);
   }
 
   if (auto *Arg = Args.getLastArg(OPT_symbol_ordering_file))
     if (Optional<MemoryBufferRef> Buffer = readFile(Arg->getValue()))
       Config->SymbolOrderingFile = getSymbolOrderingFile(*Buffer);
 
   // If --retain-symbol-file is used, we'll keep only the symbols listed in
   // the file and discard all others.
   if (auto *Arg = Args.getLastArg(OPT_retain_symbols_file)) {
     Config->DefaultSymbolVersion = VER_NDX_LOCAL;
     if (Optional<MemoryBufferRef> Buffer = readFile(Arg->getValue()))
       for (StringRef S : args::getLines(*Buffer))
         Config->VersionScriptGlobals.push_back(
             {S, /*IsExternCpp*/ false, /*HasWildcard*/ false});
   }
 
static void setConfigs(opt::InputArgList &Args) {
   Config->IsRela =
       (Config->Is64 || IsX32 || Machine == EM_PPC) && Machine != EM_MIPS;
 
   // If the output uses REL relocations we must store the dynamic relocation
   // addends to the output sections. We also store addends for RELA relocations
   // if --apply-dynamic-relocs is used.
   // We default to not writing the addends when using RELA relocations since
   // any standard conforming tool can find it in r_addend.
   Config->WriteAddends = Args.hasFlag(OPT_apply_dynamic_relocs,
                                       OPT_no_apply_dynamic_relocs, false) ||
                          !Config->IsRela;
 }
 
 // Returns a value of "-format" option.
 static bool getBinaryOption(StringRef S) {
   if (S == "binary")
     return true;

ELF/LinkerScript.cpp

sortInputSections(MutableArrayRef<InputSection *>(Ret).slice(SizeBefore),
                       Pat);
   }
   return Ret;
 }
 
 void LinkerScript::discard(ArrayRef<InputSection *> V) {
   for (InputSection *S : V) {
     if (S == InX::ShStrTab || S == InX::Dynamic || S == InX::DynSymTab ||
-        S == InX::DynStrTab || S == InX::RelaPlt || S == InX::RelaDyn)
+        S == InX::DynStrTab || S == InX::RelaPlt || S == InX::RelaDyn ||
+        S == InX::RelrDyn)
       error("discarding " + S->Name + " section is not allowed");
 
     // You can discard .hash and .gnu.hash sections by linker scripts. Since
     // they are synthesized sections, we need to handle them differently than
     // other regular sections.
     if (S == InX::GnuHashTab)
       InX::GnuHashTab = nullptr;
     if (S == InX::HashTab)

ELF/Options.td

 def omagic: Flag<["--"], "omagic">, MetaVarName<"<magic>">,
   HelpText<"Set the text and data sections to be readable and writable">;
 
 defm orphan_handling:
   Eq<"orphan-handling", "Control how orphan sections are handled when linker script used">;
 
 defm pack_dyn_relocs:
   Eq<"pack-dyn-relocs", "Pack dynamic relocations in the given format">,
-  MetaVarName<"[none,android]">;
+  MetaVarName<"[none,android,relr,android-relr]">;
 
 defm pie: B<"pie",
     "Create a position independent executable",
     "Do not create a position independent executable (default)">;
 
 defm print_gc_sections: B<"print-gc-sections",
     "List removed unused sections",
     "Do not list removed unused sections (default)">;

ELF/SyntheticSections.h

private:
   int64_t Addend;
   const OutputSection *OutputSec;
 };
 
 template <class ELFT> class DynamicSection final : public SyntheticSection {
   typedef typename ELFT::Dyn Elf_Dyn;
   typedef typename ELFT::Rel Elf_Rel;
   typedef typename ELFT::Rela Elf_Rela;
+  typedef typename ELFT::Relr Elf_Relr;
   typedef typename ELFT::Shdr Elf_Shdr;
   typedef typename ELFT::Sym Elf_Sym;
 
   // finalizeContents() fills this vector with the section contents.
   std::vector<std::pair<int32_t, std::function<uint64_t()>>> Entries;
 
 public:
   DynamicSection();
RelocationBaseSection(StringRef Name, uint32_t Type, int32_t DynamicTag,
                         int32_t SizeDynamicTag);
   void addReloc(RelType DynType, InputSectionBase *IS, uint64_t OffsetInSec,
                 Symbol *Sym);
   // Add a dynamic relocation that might need an addend. This takes care of
   // writing the addend to the output section if needed.
   void addReloc(RelType DynType, InputSectionBase *InputSec,
                 uint64_t OffsetInSec, Symbol *Sym, int64_t Addend, RelExpr Expr,
                 RelType Type);
-  void addReloc(const DynamicReloc &Reloc);
+  virtual void addReloc(const DynamicReloc &Reloc);
   bool empty() const override { return Relocs.empty(); }
   size_t getSize() const override { return Relocs.size() * this->Entsize; }
   size_t getRelativeRelocCount() const { return NumRelativeRelocs; }
   void finalizeContents() override;
   int32_t DynamicTag, SizeDynamicTag;
 
 protected:
   std::vector<DynamicReloc> Relocs;
public:
   void writeTo(uint8_t *Buf) override {
     memcpy(Buf, RelocData.data(), RelocData.size());
   }
 
 private:
   SmallVector<char, 0> RelocData;
 };
 
+template <class ELFT>
+class RelrPackedRelocationSection final : public RelocationBaseSection {
+  typedef typename ELFT::Relr Elf_Relr;
+
+public:
+  RelrPackedRelocationSection(StringRef Name);
+
+  void addReloc(const DynamicReloc &Reloc) override {
+    Relocs.push_back(Reloc);
+  }
+  bool updateAllocSize() override;
+  size_t getSize() const override {
+    return RelrRelocs.size() * this->Entsize;
+  }
+  void writeTo(uint8_t *Buf) override {
+    memcpy(Buf, RelrRelocs.data(), getSize());
+  }
+
+private:
+  std::vector<Elf_Relr> RelrRelocs;
+};
+
 struct SymbolTableEntry {
   Symbol *Sym;
   size_t StrTabOffset;
 };
 
 class SymbolTableBaseSection : public SyntheticSection {
 public:
   SymbolTableBaseSection(StringTableSection &StrTabSec);
   void finalizeContents() override;
   void postThunkContents() override;
   size_t getSize() const override { return getNumSymbols() * Entsize; }
   void addSymbol(Symbol *Sym);
   unsigned getNumSymbols() const { return Symbols.size() + 1; }
struct InX {
   static GotSection *Got;
   static GotPltSection *GotPlt;
   static IgotPltSection *IgotPlt;
   static MipsGotSection *MipsGot;
   static MipsRldMapSection *MipsRldMap;
   static PltSection *Plt;
   static PltSection *Iplt;
   static RelocationBaseSection *RelaDyn;
+  static RelocationBaseSection *RelrDyn;
   static RelocationBaseSection *RelaPlt;
   static RelocationBaseSection *RelaIplt;
   static StringTableSection *ShStrTab;
   static StringTableSection *StrTab;
   static SymbolTableBaseSection *SymTab;
 };
 
 template <class ELFT> struct In {

ELF/SyntheticSections.cpp

if (!InX::RelaDyn->empty()) {
     // The problem is in the tight relation between dynamic
     // relocations and GOT. So do not emit this tag on MIPS.
     if (Config->EMachine != EM_MIPS) {
       size_t NumRelativeRels = InX::RelaDyn->getRelativeRelocCount();
       if (Config->ZCombreloc && NumRelativeRels)
         addInt(IsRela ? DT_RELACOUNT : DT_RELCOUNT, NumRelativeRels);
     }
   }
+  if (InX::RelrDyn && !InX::RelrDyn->empty()) {
+    addInSec(InX::RelrDyn->DynamicTag, InX::RelrDyn);
+    addSize(InX::RelrDyn->SizeDynamicTag, InX::RelrDyn->getParent());
+    addInt(Config->AndroidRelrPackDynRelocs ? DT_ANDROID_RELRENT : DT_RELRENT,
+           sizeof(Elf_Relr));
+  }
   // .rel[a].plt section usually consists of two parts, containing plt and
   // iplt relocations. It is possible to have only iplt relocations in the
   // output. In that case RelaPlt is empty and have zero offset, the same offset
   // as RelaIplt have. And we still want to emit proper dynamic tags for that
   // case, so here we always use RelaPlt as marker for the begining of
   // .rel[a].plt section.
   if (InX::RelaPlt->getParent()->Live) {
     addInSec(DT_JMPREL, InX::RelaPlt);
void RelocationBaseSection::addReloc(RelType DynType, InputSectionBase *IS,
   addReloc({DynType, IS, OffsetInSec, false, Sym, 0});
 }
 
 void RelocationBaseSection::addReloc(RelType DynType,
                                      InputSectionBase *InputSec,
                                      uint64_t OffsetInSec, Symbol *Sym,
                                      int64_t Addend, RelExpr Expr,
                                      RelType Type) {
-  // Write the addends to the relocated address if required. We skip
-  // it if the written value would be zero.
-  if (Config->WriteAddends && (Expr != R_ADDEND || Addend != 0))
+  // Write the addends to the relocated address if required.
+  bool WriteAddend = Config->WriteAddends;
+  // When using RELR relocations, we need to write the addend since RELR
+  // relocations decode to offsets only.
+  if (Config->RelrPackDynRelocs && DynType == Target->RelativeRel)
+    WriteAddend = true;
+  // Skip it if the written value would be zero.
+  if (Expr == R_ADDEND && Addend == 0)
+    WriteAddend = false;
+  if (WriteAddend)
     InputSec->Relocations.push_back({Expr, Type, OffsetInSec, Addend, Sym});
   addReloc({DynType, InputSec, OffsetInSec, Expr != R_ADDEND, Sym, Addend});
 }
 
 void RelocationBaseSection::addReloc(const DynamicReloc &Reloc) {
+  if (InX::RelrDyn && Reloc.Type == Target->RelativeRel)
+    InX::RelrDyn->addReloc(Reloc);
+  else {
     if (Reloc.Type == Target->RelativeRel)
       ++NumRelativeRelocs;
     Relocs.push_back(Reloc);
   }
+}
 
 void RelocationBaseSection::finalizeContents() {
   // If all relocations are R_*_RELATIVE they don't refer to any
   // dynamic symbol and we don't need a dynamic symbol table. If that
   // is the case, just use 0 as the link.
   Link = InX::DynSymTab ? InX::DynSymTab->getParent()->SectionIndex : 0;
 
   // Set required output section properties.

 
 static bool compRelocations(const DynamicReloc &A, const DynamicReloc &B) {
   bool AIsRel = A.Type == Target->RelativeRel;
   bool BIsRel = B.Type == Target->RelativeRel;
   if (AIsRel != BIsRel)
     return AIsRel;
   return A.getSymIndex() < B.getSymIndex();
 }
 
 template <class ELFT> void RelocationSection<ELFT>::writeTo(uint8_t *Buf) {
   if (Sort)
     std::stable_sort(Relocs.begin(), Relocs.end(), compRelocations);
 
   for (const DynamicReloc &Rel : Relocs) {
     encodeDynamicReloc<ELFT>(reinterpret_cast<Elf_Rela *>(Buf), Rel);
     Buf += Config->IsRela ? sizeof(Elf_Rela) : sizeof(Elf_Rel);
   }
bool AndroidPackedRelocationSection<ELFT>::updateAllocSize() {
   // Returns whether the section size changed. We need to keep recomputing both
   // section layout and the contents of this section until the size converges
   // because changing this section's size can affect section layout, which in
   // turn can affect the sizes of the LEB-encoded integers stored in this
   // section.
   return RelocData.size() != OldSize;
 }
 
+template <class ELFT>
+RelrPackedRelocationSection<ELFT>::RelrPackedRelocationSection(StringRef Name)
+    : RelocationBaseSection(
+          Name, Config->AndroidRelrPackDynRelocs ? SHT_ANDROID_RELR : SHT_RELR,
+          Config->AndroidRelrPackDynRelocs ? DT_ANDROID_RELR : DT_RELR,
+          Config->AndroidRelrPackDynRelocs ? DT_ANDROID_RELRSZ : DT_RELRSZ) {
+  this->Entsize = sizeof(Elf_Relr);
+}
+
+template <class ELFT>
+bool RelrPackedRelocationSection<ELFT>::updateAllocSize() {
+  size_t OldSize = RelrRelocs.size();
+  RelrRelocs.clear();
+
+  // Word type: uint32_t for Elf32, and uint64_t for Elf64.
+  typedef typename ELFT::uint Word;
+
+  // Word size in number of bytes.
+  const size_t WordSize = sizeof(Word);
+
+  // Number of bits to use for the relocation offsets bitmap.
+  // These many relative relocations can be encoded in a single entry.
+  const size_t NBits = 8*WordSize - 1;
+
+  // Get offsets for all relative relocations and sort them.
+  std::vector<Word> Offsets;
+  for (const DynamicReloc &Rel : Relocs) {
+    Offsets.push_back(Rel.getOffset());
+  }
+  std::sort(Offsets.begin(), Offsets.end());
+
+  // Encode relocations in SHT_RELR section.
+  // Details of the encoding are described in this post:
+  //   https://groups.google.com/d/msg/generic-abi/bX460iggiKg/Pi9aSwwABgAJ
+  Word Base = 0;
+  typename std::vector<Word>::iterator Curr = Offsets.begin();
+  while (Curr != Offsets.end()) {
+    Word Current = *Curr;
+    if (Current%2 != 0) {
+      error("odd offset for RELR relocation (" + Twine(Current) + "), " +
+            "pass --pack-dyn-relocs=none to disable RELR relocations");
+      ++Curr;
+      continue;
+    }
+
+    Word Bits = 0;
+    typename std::vector<Word>::iterator Next = Curr;
+    if ((Base > 0) && (Base <= Current)) {
+      while (Next != Offsets.end()) {
+        Word Delta = *Next - Base;
+        // If Next is too far out, it cannot be folded into Curr.
+        if (Delta >= (NBits * WordSize))
+          break;
+        // If Next is not a multiple of WordSize away, it cannot
+        // be folded into Curr.
+        if ((Delta % WordSize) != 0)
+          break;
+        // Next can be folded into Curr, add it to the bitmap.
+        Bits |= 1ULL << (Delta / WordSize);
+        ++Next;
+      }
+    }
+
+    Elf_Relr R;
+    if (Bits == 0) {
+      R.r_data = Current;
+      // This is not a continuation entry, only one offset was
+      // consumed. Set base offset for subsequent bitmap entries.
+      Base = Current + WordSize;
+      ++Curr;
+    } else {
+      R.r_data = (Bits<<1) | 1;
+      // This is a continuation entry encoding multiple offsets
+      // in a bitmap. Advance base offset by NBits words.
+      Base += NBits * WordSize;
+      Curr = Next;
+    }
+    RelrRelocs.push_back(R);
+  }
+
+  return RelrRelocs.size() != OldSize;
+}
+
 SymbolTableBaseSection::SymbolTableBaseSection(StringTableSection &StrTabSec)
     : SyntheticSection(StrTabSec.isDynamic() ? (uint64_t)SHF_ALLOC : 0,
                        StrTabSec.isDynamic() ? SHT_DYNSYM : SHT_SYMTAB,
                        Config->Wordsize,
                        StrTabSec.isDynamic() ? ".dynsym" : ".symtab"),
       StrTabSec(StrTabSec) {}
 
 // Orders symbols according to their positions in the GOT,

 GnuHashTableSection *InX::GnuHashTab;
 HashTableSection *InX::HashTab;
 IgotPltSection *InX::IgotPlt;
 MipsGotSection *InX::MipsGot;
 MipsRldMapSection *InX::MipsRldMap;
 PltSection *InX::Plt;
 PltSection *InX::Iplt;
 RelocationBaseSection *InX::RelaDyn;
+RelocationBaseSection *InX::RelrDyn;
 RelocationBaseSection *InX::RelaPlt;
 RelocationBaseSection *InX::RelaIplt;
 StringTableSection *InX::ShStrTab;
 StringTableSection *InX::StrTab;
 SymbolTableBaseSection *InX::SymTab;
 
 template GdbIndexSection *elf::createGdbIndex<ELF32LE>();
 template GdbIndexSection *elf::createGdbIndex<ELF32BE>();

 template class elf::RelocationSection<ELF64LE>;
 template class elf::RelocationSection<ELF64BE>;
 
 template class elf::AndroidPackedRelocationSection<ELF32LE>;
 template class elf::AndroidPackedRelocationSection<ELF32BE>;
 template class elf::AndroidPackedRelocationSection<ELF64LE>;
 template class elf::AndroidPackedRelocationSection<ELF64BE>;
 
+template class elf::RelrPackedRelocationSection<ELF32LE>;
+template class elf::RelrPackedRelocationSection<ELF32BE>;
+template class elf::RelrPackedRelocationSection<ELF64LE>;
+template class elf::RelrPackedRelocationSection<ELF64BE>;
+
 template class elf::SymbolTableSection<ELF32LE>;
 template class elf::SymbolTableSection<ELF32BE>;
 template class elf::SymbolTableSection<ELF64LE>;
 template class elf::SymbolTableSection<ELF64BE>;
 
 template class elf::VersionTableSection<ELF32LE>;
 template class elf::VersionTableSection<ELF32BE>;
 template class elf::VersionTableSection<ELF64LE>;

ELF/Writer.cpp

if (Config->SysvHash) {
       Add(InX::HashTab);
     }
 
     Add(InX::Dynamic);
     Add(InX::DynStrTab);
     Add(InX::RelaDyn);
   }
 
+  if (Config->RelrPackDynRelocs) {
+    InX::RelrDyn = make<RelrPackedRelocationSection<ELFT>>(".relr.dyn");
+    Add(InX::RelrDyn);
+  }
+
   // Add .got. MIPS' .got is so different from the other archs,
   // it has its own class.
   if (Config->EMachine == EM_MIPS) {
     InX::MipsGot = make<MipsGotSection>();
     Add(InX::MipsGot);
   } else {
     InX::Got = make<GotSection>();
     Add(InX::Got);
template <class ELFT> void Writer<ELFT>::finalizeSections() {
 
   // Some symbols are defined in term of program headers. Now that we
   // have the headers, we can find out which sections they point to.
   setReservedSymbolSections();
 
   // Dynamic section must be the last one in this list and dynamic
   // symbol table section (DynSymTab) must be the first one.
   applySynthetic(
-      {InX::DynSymTab,   InX::Bss,          InX::BssRelRo, InX::GnuHashTab,
-       InX::HashTab,     InX::SymTab,       InX::ShStrTab, InX::StrTab,
-       In<ELFT>::VerDef, InX::DynStrTab,    InX::Got,      InX::MipsGot,
-       InX::IgotPlt,     InX::GotPlt,       InX::RelaDyn,  InX::RelaIplt,
-       InX::RelaPlt,     InX::Plt,          InX::Iplt,     InX::EhFrameHdr,
-       In<ELFT>::VerSym, In<ELFT>::VerNeed, InX::Dynamic},
+      {InX::DynSymTab,   InX::Bss,          InX::BssRelRo,     InX::GnuHashTab,
+       InX::HashTab,     InX::SymTab,       InX::ShStrTab,     InX::StrTab,
+       In<ELFT>::VerDef, InX::DynStrTab,    InX::Got,          InX::MipsGot,
+       InX::IgotPlt,     InX::GotPlt,       InX::RelaDyn,      InX::RelrDyn,
+       InX::RelaIplt,    InX::RelaPlt,      InX::Plt,          InX::Iplt,
+       InX::EhFrameHdr,  In<ELFT>::VerSym,  In<ELFT>::VerNeed, InX::Dynamic},
       [](SyntheticSection *SS) { SS->finalizeContents(); });
 
   if (!Script->HasSectionsCommand && !Config->Relocatable)
     fixSectionAlignments();
 
   // After link order processing .ARM.exidx sections can be deduplicated, which
   // needs to be resolved before any other address dependent operation.
   resolveShfLinkOrder();
 
   // Some architectures need to generate content that depends on the address
   // of InputSections. For example some architectures use small displacements
   // for jump instructions that is the linker's responsibility for creating
   // range extension thunks for. As the generation of the content may also
   // alter InputSection addresses we must converge to a fixed point.
-  if (Target->NeedsThunks || Config->AndroidPackDynRelocs) {
+  if (Target->NeedsThunks || Config->AndroidPackDynRelocs ||
+      Config->RelrPackDynRelocs) {
     ThunkCreator TC;
     AArch64Err843419Patcher A64P;
     bool Changed;
     do {
       Script->assignAddresses();
       Changed = false;
       if (Target->NeedsThunks)
         Changed |= TC.createThunks(OutputSections);
       if (Config->FixCortexA53Errata843419) {
         if (Changed)
           Script->assignAddresses();
         Changed |= A64P.createFixes();
       }
       if (InX::MipsGot)
         InX::MipsGot->updateAllocSize();
       Changed |= InX::RelaDyn->updateAllocSize();
+      if (InX::RelrDyn)
+        Changed |= InX::RelrDyn->updateAllocSize();
     } while (Changed);
   }
 
   // createThunks may have added local symbols to the static symbol table
   applySynthetic({InX::SymTab},
                  [](SyntheticSection *SS) { SS->postThunkContents(); });
 
   // Fill other section headers. The dynamic table is finalized

test/ELF/pack-dyn-relocs.s

 // REQUIRES: arm, aarch64
 
 // RUN: llvm-mc -filetype=obj -triple=armv7a-none-linux-gnueabi %p/Inputs/arm-shared.s -o %t.a32.so.o
 // RUN: ld.lld -shared %t.a32.so.o -o %t.a32.so
 // RUN: llvm-mc -filetype=obj -triple=armv7a-none-linux-gnueabi %s -o %t.a32
 // RUN: ld.lld -pie --pack-dyn-relocs=none %t.a32 %t.a32.so -o %t2.a32
 // RUN: llvm-readobj -relocations %t2.a32 | FileCheck --check-prefix=UNPACKED32 %s
-// RUN: ld.lld -pie --pack-dyn-relocs android %t.a32 %t.a32.so -o %t3.a32
-// RUN: llvm-readobj -s -dynamic-table %t3.a32 | FileCheck --check-prefix=PACKED32-HEADERS %s
-// RUN: llvm-readobj -relocations %t3.a32 | FileCheck --check-prefix=PACKED32 %s
 
 // Unpacked should have the relative relocations in their natural order.
 // UNPACKED32:          0x1000 R_ARM_RELATIVE - 0x0
 // UNPACKED32-NEXT:     0x1004 R_ARM_RELATIVE - 0x0
 // UNPACKED32-NEXT:     0x1008 R_ARM_RELATIVE - 0x0
 // UNPACKED32-NEXT:     0x100C R_ARM_RELATIVE - 0x0
 // UNPACKED32-NEXT:     0x1010 R_ARM_RELATIVE - 0x0
 // UNPACKED32-NEXT:     0x1014 R_ARM_RELATIVE - 0x0

 // UNPACKED32-NEXT:     0x1058 R_ARM_RELATIVE - 0x0
 // UNPACKED32-NEXT:     0x105C R_ARM_RELATIVE - 0x0
 // UNPACKED32-NEXT:     0x1060 R_ARM_RELATIVE - 0x0
 // UNPACKED32-NEXT:     0x1064 R_ARM_RELATIVE - 0x0
 
 // UNPACKED32-NEXT:     0x1020 R_ARM_ABS32 bar2 0x0
 // UNPACKED32-NEXT:     0x1040 R_ARM_ABS32 zed2 0x0
 
-// PACKED32-HEADERS:       Index: 1
-// PACKED32-HEADERS-NEXT:  Name: .dynsym
+// RUN: ld.lld -pie --pack-dyn-relocs=android %t.a32 %t.a32.so -o %t3.a32
+// RUN: llvm-readobj -s -dynamic-table %t3.a32 | FileCheck --check-prefix=ANDROID32-HEADERS %s
+// RUN: llvm-readobj -relocations %t3.a32 | FileCheck --check-prefix=ANDROID32 %s
+
+// ANDROID32-HEADERS:       Index: 1
+// ANDROID32-HEADERS-NEXT:  Name: .dynsym
+
+// ANDROID32-HEADERS:       Name: .rel.dyn
+// ANDROID32-HEADERS-NEXT:  Type: SHT_ANDROID_REL
+// ANDROID32-HEADERS-NEXT:  Flags [ (0x2)
+// ANDROID32-HEADERS-NEXT:    SHF_ALLOC (0x2)
+// ANDROID32-HEADERS-NEXT:  ]
+// ANDROID32-HEADERS-NEXT:  Address: [[ADDR:.*]]
+// ANDROID32-HEADERS-NEXT:  Offset: [[ADDR]]
+// ANDROID32-HEADERS-NEXT:  Size: [[SIZE:.*]]
+// ANDROID32-HEADERS-NEXT:  Link: 1
+// ANDROID32-HEADERS-NEXT:  Info: 0
+// ANDROID32-HEADERS-NEXT:  AddressAlignment: 4
+// ANDROID32-HEADERS-NEXT:  EntrySize: 1
 
-// PACKED32-HEADERS:       Name: .rel.dyn
-// PACKED32-HEADERS-NEXT:  Type: SHT_ANDROID_REL
-// PACKED32-HEADERS-NEXT:  Flags [ (0x2)
-// PACKED32-HEADERS-NEXT:    SHF_ALLOC (0x2)
-// PACKED32-HEADERS-NEXT:  ]
-// PACKED32-HEADERS-NEXT:  Address: [[ADDR:.*]]
-// PACKED32-HEADERS-NEXT:  Offset: [[ADDR]]
-// PACKED32-HEADERS-NEXT:  Size: [[SIZE:.*]]
-// PACKED32-HEADERS-NEXT:  Link: 1
-// PACKED32-HEADERS-NEXT:  Info: 0
-// PACKED32-HEADERS-NEXT:  AddressAlignment: 4
-// PACKED32-HEADERS-NEXT:  EntrySize: 1
-
-// PACKED32-HEADERS: 0x6000000F ANDROID_REL          [[ADDR]]
-// PACKED32-HEADERS: 0x60000010 ANDROID_RELSZ        [[SIZE]]
+// ANDROID32-HEADERS: 0x6000000F ANDROID_REL          [[ADDR]]
+// ANDROID32-HEADERS: 0x60000010 ANDROID_RELSZ        [[SIZE]]
 
 // Packed should have the larger groups of relative relocations first,
 // i.e. the 8 and 9 followed by the 7.
-// PACKED32:          0x1000 R_ARM_RELATIVE - 0x0
-// PACKED32-NEXT:     0x1004 R_ARM_RELATIVE - 0x0
-// PACKED32-NEXT:     0x1008 R_ARM_RELATIVE - 0x0
-// PACKED32-NEXT:     0x100C R_ARM_RELATIVE - 0x0
-// PACKED32-NEXT:     0x1010 R_ARM_RELATIVE - 0x0
-// PACKED32-NEXT:     0x1014 R_ARM_RELATIVE - 0x0
-// PACKED32-NEXT:     0x1018 R_ARM_RELATIVE - 0x0
-// PACKED32-NEXT:     0x101C R_ARM_RELATIVE - 0x0
-
-// PACKED32-NEXT:     0x1044 R_ARM_RELATIVE - 0x0
-// PACKED32-NEXT:     0x1048 R_ARM_RELATIVE - 0x0
-// PACKED32-NEXT:     0x104C R_ARM_RELATIVE - 0x0
-// PACKED32-NEXT:     0x1050 R_ARM_RELATIVE - 0x0
-// PACKED32-NEXT:     0x1054 R_ARM_RELATIVE - 0x0
-// PACKED32-NEXT:     0x1058 R_ARM_RELATIVE - 0x0
-// PACKED32-NEXT:     0x105C R_ARM_RELATIVE - 0x0
-// PACKED32-NEXT:     0x1060 R_ARM_RELATIVE - 0x0
-// PACKED32-NEXT:     0x1064 R_ARM_RELATIVE - 0x0
-
-// PACKED32-NEXT:     0x1024 R_ARM_RELATIVE - 0x0
-// PACKED32-NEXT:     0x1028 R_ARM_RELATIVE - 0x0
-// PACKED32-NEXT:     0x102C R_ARM_RELATIVE - 0x0
-// PACKED32-NEXT:     0x1030 R_ARM_RELATIVE - 0x0
-// PACKED32-NEXT:     0x1034 R_ARM_RELATIVE - 0x0
-// PACKED32-NEXT:     0x1038 R_ARM_RELATIVE - 0x0
-// PACKED32-NEXT:     0x103C R_ARM_RELATIVE - 0x0
-
-// PACKED32-NEXT:     0x1020 R_ARM_ABS32 bar2 0x0
-// PACKED32-NEXT:     0x1040 R_ARM_ABS32 zed2 0x0
+// ANDROID32:          0x1000 R_ARM_RELATIVE - 0x0
+// ANDROID32-NEXT:     0x1004 R_ARM_RELATIVE - 0x0
+// ANDROID32-NEXT:     0x1008 R_ARM_RELATIVE - 0x0
+// ANDROID32-NEXT:     0x100C R_ARM_RELATIVE - 0x0
+// ANDROID32-NEXT:     0x1010 R_ARM_RELATIVE - 0x0
+// ANDROID32-NEXT:     0x1014 R_ARM_RELATIVE - 0x0
+// ANDROID32-NEXT:     0x1018 R_ARM_RELATIVE - 0x0
+// ANDROID32-NEXT:     0x101C R_ARM_RELATIVE - 0x0
+
+// ANDROID32-NEXT:     0x1044 R_ARM_RELATIVE - 0x0
+// ANDROID32-NEXT:     0x1048 R_ARM_RELATIVE - 0x0
+// ANDROID32-NEXT:     0x104C R_ARM_RELATIVE - 0x0
+// ANDROID32-NEXT:     0x1050 R_ARM_RELATIVE - 0x0
+// ANDROID32-NEXT:     0x1054 R_ARM_RELATIVE - 0x0
+// ANDROID32-NEXT:     0x1058 R_ARM_RELATIVE - 0x0
+// ANDROID32-NEXT:     0x105C R_ARM_RELATIVE - 0x0
+// ANDROID32-NEXT:     0x1060 R_ARM_RELATIVE - 0x0
+// ANDROID32-NEXT:     0x1064 R_ARM_RELATIVE - 0x0
+
+// ANDROID32-NEXT:     0x1024 R_ARM_RELATIVE - 0x0
+// ANDROID32-NEXT:     0x1028 R_ARM_RELATIVE - 0x0
+// ANDROID32-NEXT:     0x102C R_ARM_RELATIVE - 0x0
+// ANDROID32-NEXT:     0x1030 R_ARM_RELATIVE - 0x0
+// ANDROID32-NEXT:     0x1034 R_ARM_RELATIVE - 0x0
+// ANDROID32-NEXT:     0x1038 R_ARM_RELATIVE - 0x0
+// ANDROID32-NEXT:     0x103C R_ARM_RELATIVE - 0x0
+
+// ANDROID32-NEXT:     0x1020 R_ARM_ABS32 bar2 0x0
+// ANDROID32-NEXT:     0x1040 R_ARM_ABS32 zed2 0x0
+
+// RUN: ld.lld -pie --pack-dyn-relocs=relr %t.a32 %t.a32.so -o %t4.a32
+// RUN: llvm-readobj -s -dynamic-table %t4.a32 | FileCheck --check-prefix=RELR32-HEADERS %s
+// RUN: llvm-readobj -relocations %t4.a32 | FileCheck --check-prefix=RELR32 %s
+// RUN: llvm-readobj -relocations -decode-relr %t4.a32 | FileCheck --check-prefix=RELRD32 %s
+
+// RELR32-HEADERS:       Index: 1
+// RELR32-HEADERS-NEXT:  Name: .dynsym
+
+// RELR32-HEADERS:       Name: .relr.dyn
+// RELR32-HEADERS-NEXT:  Type: SHT_RELR
+// RELR32-HEADERS-NEXT:  Flags [ (0x2)
+// RELR32-HEADERS-NEXT:    SHF_ALLOC (0x2)
+// RELR32-HEADERS-NEXT:  ]
+// RELR32-HEADERS-NEXT:  Address: [[ADDR:.*]]
+// RELR32-HEADERS-NEXT:  Offset: [[ADDR]]
+// RELR32-HEADERS-NEXT:  Size: 8
+// RELR32-HEADERS-NEXT:  Link: 1
+// RELR32-HEADERS-NEXT:  Info: 0
+// RELR32-HEADERS-NEXT:  AddressAlignment: 4
+// RELR32-HEADERS-NEXT:  EntrySize: 4
+
+// RELR32-HEADERS:       0x00000024 RELR                 [[ADDR]]
+// RELR32-HEADERS:       0x00000023 RELRSZ               0x8
+// RELR32-HEADERS:       0x00000025 RELRENT              0x4
+
+// SHT_RELR section contains address/bitmap entries
+// encoding the offsets for relative relocation.
+// RELR32:               0x1000    R_RELR_RELATIVE - 0x0
+// RELR32-NEXT:          0x3FEFEFF R_RELR_RELATIVE - 0x0
+
+// Decoded SHT_RELR section is same as UNPACKED,
+// but contains only the relative relocations.
+// RELRD32:              0x1000 R_ARM_RELATIVE - 0x0
+// RELRD32-NEXT:         0x1004 R_ARM_RELATIVE - 0x0
+// RELRD32-NEXT:         0x1008 R_ARM_RELATIVE - 0x0
+// RELRD32-NEXT:         0x100C R_ARM_RELATIVE - 0x0
+// RELRD32-NEXT:         0x1010 R_ARM_RELATIVE - 0x0
+// RELRD32-NEXT:         0x1014 R_ARM_RELATIVE - 0x0
+// RELRD32-NEXT:         0x1018 R_ARM_RELATIVE - 0x0
+// RELRD32-NEXT:         0x101C R_ARM_RELATIVE - 0x0
+
+// RELRD32-NEXT:         0x1024 R_ARM_RELATIVE - 0x0
+// RELRD32-NEXT:         0x1028 R_ARM_RELATIVE - 0x0
+// RELRD32-NEXT:         0x102C R_ARM_RELATIVE - 0x0
+// RELRD32-NEXT:         0x1030 R_ARM_RELATIVE - 0x0
+// RELRD32-NEXT:         0x1034 R_ARM_RELATIVE - 0x0
+// RELRD32-NEXT:         0x1038 R_ARM_RELATIVE - 0x0
+// RELRD32-NEXT:         0x103C R_ARM_RELATIVE - 0x0
+
+// RELRD32-NEXT:         0x1044 R_ARM_RELATIVE - 0x0
+// RELRD32-NEXT:         0x1048 R_ARM_RELATIVE - 0x0
+// RELRD32-NEXT:         0x104C R_ARM_RELATIVE - 0x0
+// RELRD32-NEXT:         0x1050 R_ARM_RELATIVE - 0x0
+// RELRD32-NEXT:         0x1054 R_ARM_RELATIVE - 0x0
+// RELRD32-NEXT:         0x1058 R_ARM_RELATIVE - 0x0
+// RELRD32-NEXT:         0x105C R_ARM_RELATIVE - 0x0
+// RELRD32-NEXT:         0x1060 R_ARM_RELATIVE - 0x0
+// RELRD32-NEXT:         0x1064 R_ARM_RELATIVE - 0x0
 
 // RUN: llvm-mc -filetype=obj -triple=aarch64-unknown-linux %p/Inputs/shared2.s -o %t.a64.so.o
 // RUN: ld.lld -shared %t.a64.so.o -o %t.a64.so
 // RUN: llvm-mc -filetype=obj -triple=aarch64-unknown-linux %s -o %t.a64
 // RUN: ld.lld -pie --pack-dyn-relocs=none %t.a64 %t.a64.so -o %t2.a64
 // RUN: llvm-readobj -relocations %t2.a64 | FileCheck --check-prefix=UNPACKED64 %s
-// RUN: ld.lld -pie --pack-dyn-relocs=android %t.a64 %t.a64.so -o %t3.a64
-// RUN: llvm-readobj -s -dynamic-table %t3.a64 | FileCheck --check-prefix=PACKED64-HEADERS %s
-// RUN: llvm-readobj -relocations %t3.a64 | FileCheck --check-prefix=PACKED64 %s
 
 // UNPACKED64:          0x10000 R_AARCH64_RELATIVE - 0x1
 // UNPACKED64-NEXT:     0x10008 R_AARCH64_RELATIVE - 0x2
 // UNPACKED64-NEXT:     0x10010 R_AARCH64_RELATIVE - 0x3
 // UNPACKED64-NEXT:     0x10018 R_AARCH64_RELATIVE - 0x4
 // UNPACKED64-NEXT:     0x10020 R_AARCH64_RELATIVE - 0x5
 // UNPACKED64-NEXT:     0x10028 R_AARCH64_RELATIVE - 0x6
 // UNPACKED64-NEXT:     0x10030 R_AARCH64_RELATIVE - 0x7

 // UNPACKED64-NEXT:     0x100B0 R_AARCH64_RELATIVE - 0x6
 // UNPACKED64-NEXT:     0x100B8 R_AARCH64_RELATIVE - 0x7
 // UNPACKED64-NEXT:     0x100C0 R_AARCH64_RELATIVE - 0x8
 // UNPACKED64-NEXT:     0x100C8 R_AARCH64_RELATIVE - 0x9
 
 // UNPACKED64-NEXT:     0x10040 R_AARCH64_ABS64 bar2 0x1
 // UNPACKED64-NEXT:     0x10080 R_AARCH64_ABS64 zed2 0x0
 
-// PACKED64:          0x10000 R_AARCH64_RELATIVE - 0x1
-// PACKED64-NEXT:     0x10008 R_AARCH64_RELATIVE - 0x2
-// PACKED64-NEXT:     0x10010 R_AARCH64_RELATIVE - 0x3
-// PACKED64-NEXT:     0x10018 R_AARCH64_RELATIVE - 0x4
-// PACKED64-NEXT:     0x10020 R_AARCH64_RELATIVE - 0x5
-// PACKED64-NEXT:     0x10028 R_AARCH64_RELATIVE - 0x6
-// PACKED64-NEXT:     0x10030 R_AARCH64_RELATIVE - 0x7
-// PACKED64-NEXT:     0x10038 R_AARCH64_RELATIVE - 0x8
-
-// PACKED64-NEXT:     0x10088 R_AARCH64_RELATIVE - 0x1
-// PACKED64-NEXT:     0x10090 R_AARCH64_RELATIVE - 0x2
-// PACKED64-NEXT:     0x10098 R_AARCH64_RELATIVE - 0x3
-// PACKED64-NEXT:     0x100A0 R_AARCH64_RELATIVE - 0x4
-// PACKED64-NEXT:     0x100A8 R_AARCH64_RELATIVE - 0x5
-// PACKED64-NEXT:     0x100B0 R_AARCH64_RELATIVE - 0x6
-// PACKED64-NEXT:     0x100B8 R_AARCH64_RELATIVE - 0x7
-// PACKED64-NEXT:     0x100C0 R_AARCH64_RELATIVE - 0x8
-// PACKED64-NEXT:     0x100C8 R_AARCH64_RELATIVE - 0x9
-
-// PACKED64-NEXT:     0x10048 R_AARCH64_RELATIVE - 0x1
-// PACKED64-NEXT:     0x10050 R_AARCH64_RELATIVE - 0x2
-// PACKED64-NEXT:     0x10058 R_AARCH64_RELATIVE - 0x3
-// PACKED64-NEXT:     0x10060 R_AARCH64_RELATIVE - 0x4
-// PACKED64-NEXT:     0x10068 R_AARCH64_RELATIVE - 0x5
-// PACKED64-NEXT:     0x10070 R_AARCH64_RELATIVE - 0x6
-// PACKED64-NEXT:     0x10078 R_AARCH64_RELATIVE - 0x7
-
-// PACKED64-NEXT:     0x10040 R_AARCH64_ABS64 bar2 0x1
-// PACKED64-NEXT:     0x10080 R_AARCH64_ABS64 zed2 0x0
-
-// PACKED64-HEADERS:       Index: 1
-// PACKED64-HEADERS-NEXT:  Name: .dynsym
-
-// PACKED64-HEADERS:       Name: .rela.dyn
-// PACKED64-HEADERS-NEXT:  Type: SHT_ANDROID_RELA
-// PACKED64-HEADERS-NEXT:  Flags [ (0x2)
-// PACKED64-HEADERS-NEXT:    SHF_ALLOC (0x2)
-// PACKED64-HEADERS-NEXT:  ]
-// PACKED64-HEADERS-NEXT:  Address: [[ADDR:.*]]
-// PACKED64-HEADERS-NEXT:  Offset: [[ADDR]]
-// PACKED64-HEADERS-NEXT:  Size: [[SIZE:.*]]
-// PACKED64-HEADERS-NEXT:  Link: 1
-// PACKED64-HEADERS-NEXT:  Info: 0
-// PACKED64-HEADERS-NEXT:  AddressAlignment: 8
-// PACKED64-HEADERS-NEXT:  EntrySize: 1
+// RUN: ld.lld -pie --pack-dyn-relocs=android %t.a64 %t.a64.so -o %t3.a64
+// RUN: llvm-readobj -s -dynamic-table %t3.a64 | FileCheck --check-prefix=ANDROID64-HEADERS %s
+// RUN: llvm-readobj -relocations %t3.a64 | FileCheck --check-prefix=ANDROID64 %s
+
+// ANDROID64-HEADERS:       Index: 1
+// ANDROID64-HEADERS-NEXT:  Name: .dynsym
 
-// PACKED64-HEADERS: 0x0000000060000011 ANDROID_RELA          [[ADDR]]
-// PACKED64-HEADERS: 0x0000000060000012 ANDROID_RELASZ        [[SIZE]]
+// ANDROID64-HEADERS:       Name: .rela.dyn
+// ANDROID64-HEADERS-NEXT:  Type: SHT_ANDROID_RELA
+// ANDROID64-HEADERS-NEXT:  Flags [ (0x2)
+// ANDROID64-HEADERS-NEXT:    SHF_ALLOC (0x2)
+// ANDROID64-HEADERS-NEXT:  ]
+// ANDROID64-HEADERS-NEXT:  Address: [[ADDR:.*]]
+// ANDROID64-HEADERS-NEXT:  Offset: [[ADDR]]
+// ANDROID64-HEADERS-NEXT:  Size: [[SIZE:.*]]
+// ANDROID64-HEADERS-NEXT:  Link: 1
+// ANDROID64-HEADERS-NEXT:  Info: 0
+// ANDROID64-HEADERS-NEXT:  AddressAlignment: 8
+// ANDROID64-HEADERS-NEXT:  EntrySize: 1
+
+// ANDROID64-HEADERS: 0x0000000060000011 ANDROID_RELA          [[ADDR]]
+// ANDROID64-HEADERS: 0x0000000060000012 ANDROID_RELASZ        [[SIZE]]
+
+// ANDROID64:          0x10000 R_AARCH64_RELATIVE - 0x1
+// ANDROID64-NEXT:     0x10008 R_AARCH64_RELATIVE - 0x2
+// ANDROID64-NEXT:     0x10010 R_AARCH64_RELATIVE - 0x3
+// ANDROID64-NEXT:     0x10018 R_AARCH64_RELATIVE - 0x4
+// ANDROID64-NEXT:     0x10020 R_AARCH64_RELATIVE - 0x5
+// ANDROID64-NEXT:     0x10028 R_AARCH64_RELATIVE - 0x6
+// ANDROID64-NEXT:     0x10030 R_AARCH64_RELATIVE - 0x7
+// ANDROID64-NEXT:     0x10038 R_AARCH64_RELATIVE - 0x8
+
+// ANDROID64-NEXT:     0x10088 R_AARCH64_RELATIVE - 0x1
+// ANDROID64-NEXT:     0x10090 R_AARCH64_RELATIVE - 0x2
+// ANDROID64-NEXT:     0x10098 R_AARCH64_RELATIVE - 0x3
+// ANDROID64-NEXT:     0x100A0 R_AARCH64_RELATIVE - 0x4
+// ANDROID64-NEXT:     0x100A8 R_AARCH64_RELATIVE - 0x5
+// ANDROID64-NEXT:     0x100B0 R_AARCH64_RELATIVE - 0x6
+// ANDROID64-NEXT:     0x100B8 R_AARCH64_RELATIVE - 0x7
+// ANDROID64-NEXT:     0x100C0 R_AARCH64_RELATIVE - 0x8
+// ANDROID64-NEXT:     0x100C8 R_AARCH64_RELATIVE - 0x9
+
+// ANDROID64-NEXT:     0x10048 R_AARCH64_RELATIVE - 0x1
+// ANDROID64-NEXT:     0x10050 R_AARCH64_RELATIVE - 0x2
+// ANDROID64-NEXT:     0x10058 R_AARCH64_RELATIVE - 0x3
+// ANDROID64-NEXT:     0x10060 R_AARCH64_RELATIVE - 0x4
+// ANDROID64-NEXT:     0x10068 R_AARCH64_RELATIVE - 0x5
+// ANDROID64-NEXT:     0x10070 R_AARCH64_RELATIVE - 0x6
+// ANDROID64-NEXT:     0x10078 R_AARCH64_RELATIVE - 0x7
+
+// ANDROID64-NEXT:     0x10040 R_AARCH64_ABS64 bar2 0x1
+// ANDROID64-NEXT:     0x10080 R_AARCH64_ABS64 zed2 0x0
+
+// RUN: ld.lld -pie --pack-dyn-relocs=relr %t.a64 %t.a64.so -o %t4.a64
+// RUN: llvm-readobj -s -dynamic-table %t4.a64 | FileCheck --check-prefix=RELR64-HEADERS %s
+// RUN: llvm-readobj -relocations %t4.a64 | FileCheck --check-prefix=RELR64 %s
+// RUN: llvm-readobj -relocations -decode-relr %t4.a64 | FileCheck --check-prefix=RELRD64 %s
+
+// RELR64-HEADERS:       Index: 1
+// RELR64-HEADERS-NEXT:  Name: .dynsym
+
+// RELR64-HEADERS:       Name: .relr.dyn
+// RELR64-HEADERS-NEXT:  Type: SHT_RELR
+// RELR64-HEADERS-NEXT:  Flags [ (0x2)
+// RELR64-HEADERS-NEXT:    SHF_ALLOC (0x2)
+// RELR64-HEADERS-NEXT:  ]
+// RELR64-HEADERS-NEXT:  Address: [[ADDR:.*]]
+// RELR64-HEADERS-NEXT:  Offset: [[ADDR]]
+// RELR64-HEADERS-NEXT:  Size: 16
+// RELR64-HEADERS-NEXT:  Link: 1
+// RELR64-HEADERS-NEXT:  Info: 0
+// RELR64-HEADERS-NEXT:  AddressAlignment: 8
+// RELR64-HEADERS-NEXT:  EntrySize: 8
+
+// RELR64-HEADERS:       0x0000000000000024 RELR                 [[ADDR]]
+// RELR64-HEADERS:       0x0000000000000023 RELRSZ               0x10
+// RELR64-HEADERS:       0x0000000000000025 RELRENT              0x8
+
+// SHT_RELR section contains address/bitmap entries
+// encoding the offsets for relative relocation.
+// RELR64:               0x10000   R_RELR_RELATIVE - 0x0
+// RELR64-NEXT:          0x3FEFEFF R_RELR_RELATIVE - 0x0
+
+// Decoded SHT_RELR section is same as UNPACKED,
+// but contains only the relative relocations.
+// RELRD64:              0x10000 R_AARCH64_RELATIVE - 0x0
+// RELRD64-NEXT:         0x10008 R_AARCH64_RELATIVE - 0x0
+// RELRD64-NEXT:         0x10010 R_AARCH64_RELATIVE - 0x0
+// RELRD64-NEXT:         0x10018 R_AARCH64_RELATIVE - 0x0
+// RELRD64-NEXT:         0x10020 R_AARCH64_RELATIVE - 0x0
+// RELRD64-NEXT:         0x10028 R_AARCH64_RELATIVE - 0x0
+// RELRD64-NEXT:         0x10030 R_AARCH64_RELATIVE - 0x0
+// RELRD64-NEXT:         0x10038 R_AARCH64_RELATIVE - 0x0
+
+// RELRD64-NEXT:         0x10048 R_AARCH64_RELATIVE - 0x0
+// RELRD64-NEXT:         0x10050 R_AARCH64_RELATIVE - 0x0
+// RELRD64-NEXT:         0x10058 R_AARCH64_RELATIVE - 0x0
+// RELRD64-NEXT:         0x10060 R_AARCH64_RELATIVE - 0x0
+// RELRD64-NEXT:         0x10068 R_AARCH64_RELATIVE - 0x0
+// RELRD64-NEXT:         0x10070 R_AARCH64_RELATIVE - 0x0
+// RELRD64-NEXT:         0x10078 R_AARCH64_RELATIVE - 0x0
+
+// RELRD64-NEXT:         0x10088 R_AARCH64_RELATIVE - 0x0
+// RELRD64-NEXT:         0x10090 R_AARCH64_RELATIVE - 0x0
+// RELRD64-NEXT:         0x10098 R_AARCH64_RELATIVE - 0x0
+// RELRD64-NEXT:         0x100A0 R_AARCH64_RELATIVE - 0x0
+// RELRD64-NEXT:         0x100A8 R_AARCH64_RELATIVE - 0x0
+// RELRD64-NEXT:         0x100B0 R_AARCH64_RELATIVE - 0x0
+// RELRD64-NEXT:         0x100B8 R_AARCH64_RELATIVE - 0x0
+// RELRD64-NEXT:         0x100C0 R_AARCH64_RELATIVE - 0x0
+// RELRD64-NEXT:         0x100C8 R_AARCH64_RELATIVE - 0x0
 
 .data
 .dc.a __ehdr_start + 1
 .dc.a __ehdr_start + 2
 .dc.a __ehdr_start + 3
 .dc.a __ehdr_start + 4
 .dc.a __ehdr_start + 5
 .dc.a __ehdr_start + 6