forked from OSchip/llvm-project
Don't worry about dropping SHF_MERGE.
Now that it doesn't impact which sections are merged, this is not a problem. llvm-svn: 294054
This commit is contained in:
parent
939f6b0167
commit
c06f54122e
|
|
@ -76,13 +76,6 @@ InputSectionBase<ELFT>::InputSectionBase(elf::ObjectFile<ELFT> *File,
|
|||
if (V > UINT32_MAX)
|
||||
fatal(toString(File) + ": section sh_addralign is too large");
|
||||
Alignment = V;
|
||||
|
||||
// If it is not a mergeable section, overwrite the flag so that the flag
|
||||
// is consistent with the class. This inconsistency could occur when
|
||||
// string merging is disabled using -O0 flag.
|
||||
if (!Config->Relocatable && !isa<MergeInputSection<ELFT>>(this) &&
|
||||
!isa<SyntheticSection<ELFT>>(this))
|
||||
this->Flags &= ~(SHF_MERGE | SHF_STRINGS);
|
||||
}
|
||||
|
||||
template <class ELFT>
|
||||
|
|
|
|||
|
|
@ -61,6 +61,8 @@ zed:
|
|||
// NOMERGE-NEXT: Type: SHT_PROGBITS
|
||||
// NOMERGE-NEXT: Flags [
|
||||
// NOMERGE-NEXT: SHF_ALLOC
|
||||
// NOMERGE-NEXT: SHF_MERGE
|
||||
// NOMERGE-NEXT: SHF_STRINGS
|
||||
// NOMERGE-NEXT: ]
|
||||
// NOMERGE-NEXT: Address: 0x1C8
|
||||
// NOMERGE-NEXT: Offset: 0x1C8
|
||||
|
|
|
|||
Loading…
Reference in New Issue